openldap-technical July 2013

openldap-technical@openldap.org

68 participants
86 discussions

Q: referral issue
by espeake＠oreillyauto.com 18 Jul '13

18 Jul '13

Okay my referral chaining was working and then stopped working. I get an error 10 when I submit a change to my clustered consumers that are setup to refer writes to my master LDAP server. In looking at the configuration help in the online documentation it shows how to setup the slapd.conf file on the master. The issue here is that everything is setup through cn=config. my consumers do have a slapd.conf file along with cn=config files. I have inherited these servers so I'm sure what the person here before me was trying to do. I have an idea but I didn't like that idea. Here is the chaining command from my slapd.conf file. overlay chain chain-uri "ldap://tntest-ldap-master-1.example.com" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="uid=admin,dc=oreillyauto,dc=com" credentials="password" mode="self" chain-tls start chain-return-error TRUE The the syncrepl area syncrepl rid 002 provider=ldap://tntest-ldap-master-1.example.com type=refreshOnly interval=00:00:05:00 searchbase-"dc=oreillyauto,dc=com" binddn="uuid=syncrepl,ou=system,dc=oreillyauto,dc=com" credentials=password updatedn "uid=ldapadmin,ou=system,dc=example,dc=com" updateref ldap://tntest-ldap-master-1.example.com I need to be pointed in the right direction please. Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

2 1

unable to query rootdn on slave via external auth
by Adrian Bridgett 18 Jul '13

18 Jul '13

This has been driving me up the wall and I wondered if someone could point out the bit I'm missing - the desk is getting badly damaged by my head bashing it :-) On our master server I can query the rootdb no problem, but I can't do this on the slaves - this applies whether I use external or ldaps authentication. I've turned on access and search filter debugging and I can't see any rejections. I'm trying to query contextCSN to ensure that the slave is in sync. "slapcat" works, but seems an ugly hack. I can query all the children - just not the root. The config is the same (ish) on both - here's the slave: dn: olcDatabase={1}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=com olcRootPW:: ....... olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 structuralObjectClass: olcHdbConfig entryUUID: 07f3fede-c201-1031-8b17-f3837148ab05 creatorsName: cn=config createTimestamp: 20121113171221Z olcSyncrepl: {0}rid=000 provider=ldap://ldap.example.com type=refreshandPers ist interval=00:00:00:60 retry="60 10 300 +" timelimit=10 searchbase="dc=example ,dc=com" binddn="cn=admin,dc=example,dc=com" bindmethod=simple credent ials=..... starttls=critical tls_reqcert=demand attrs="*,+" olcUpdateRef: ldap://ldap.example.com olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: objectClass eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: uid,uidNumber,gidNumber,memberOf,sudoUser,memberUid pres,eq olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=example,dc=com" manage by group.exact="cn=admins, ou=Group,dc=example,dc=com" manage by dn.exact=gidNumber=0+uidNumber=0,cn=p eercred,cn=external,cn=auth manage by * none olcAccess: {1}to attrs=SambaLMPassword,SambaNTPassword by self write by dn="cn =freenas-auth,ou=services,dc=example,dc=com" read by dn="cn=admin,dc=example ,dc=com" manage by group.exact="cn=admins,ou=Group,dc=example,dc=com" ma nage by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth mana ge by * none olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=com" manage b y group.exact="cn=admins,ou=Group,dc=example,dc=com" manage by dn.exact=gid Number=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * read olcAccess: {4}to dn.base="dc=example,dc=com" by * read On the slave: ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base -Q# extended LDIF # search result search: 2 result: 0 Success # numResponses: 1 On the master: ldapsearch -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com -s base dn: dc=example,dc=com objectClass: top objectClass: dcObject objectClass: organization o: example.com dc: example # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

2 6

olcPasswordHash
by Nerijus Kislauskas 18 Jul '13

18 Jul '13

Hi community, We want implement password politics in our DIT, and are testing ppolicy and found issues using olcPasswordHash, Password Modify Extension and so. Here are my testings: 1) My cn=config with olcPasswordHash and olcSuffix values $ ldapsearch -D "cn=admin,dc=ktu,dc=lt" -W -x -b "cn=config" olcPasswordHash olcSuffix dn: cn=config olcPasswordHash: {SSHA} ... # {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config olcPasswordHash: {SSHA} olcPasswordHash: {SHA} olcPasswordHash: {SMD5} olcPasswordHash: {MD5} olcPasswordHash: {CRYPT} ... # {2}hdb, config dn: olcDatabase={2}hdb,cn=config olcSuffix: dc=ktu,dc=lt $ 2) My testing user exists without userPassword attribute $ ldapsearch -D "cn=admin,dc=ktu,dc=lt" -W -x -b "eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt" userPassword Enter LDAP Password: dn: eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt $ 3) Making a password for a test user. As documentation says "ldappasswd uses the LDAPv3 Password Modify (RFC 3062) extended operation." $ ldappasswd -h localhost -D "cn=admin,dc=ktu,dc=lt" -x -W -S "eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt" New password: Re-enter new password: Enter LDAP Password: $ 4) userPassword is somehow gets multivalued $ ldapsearch -D "cn=admin,dc=ktu,dc=lt" -W -x -b "eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt" userPassword Enter LDAP Password: # testuser9(a)ktu.lt, People, Users, ktu.lt dn: eduPersonPrincipalName=testuser9(a)ktu.lt,ou=People,ou=Users,dc=ktu,dc=lt userPassword:: e1NTSEF9RlE3VjRYa003RVJ6eGFTNjR4ZkFRSzRGZEk4cFk0UDQ= --> {SSHA}FQ7V4XkM7ERzxaS64xfAQK4FdI8pY4P4 userPassword:: e1NTSEF9K1JtbWl3M0RxTTV3aEl0U3g5TjVrZWRETlpES3NROUg= --> {SSHA}+Rmmiw3DqM5whItSx9N5kedDNZDKsQ9H userPassword:: e1NIQX1maVFONTAreDdRajZDTk9BWS9hbXFSUmlxQlU9 --> {SHA}fiQN50+x7Qj6CNOAY/amqRRiqBU= userPassword:: e1NNRDV9VUdaa3ZDSWI5Qld4a1VNcUhyZEl3ZElTbnJ3PQ== --> {SMD5}UGZkvCIb9BWxkUMqHrdIwdISnrw= userPassword:: e01ENX1SN3pseDA5WW4waG4yOVYrbktuNENBPT0= --> {MD5}R7zlx09Yn0hn29V+nKn4CA== userPassword:: e0NSWVBUfTFNZVAud1ZxenEvdWM= --> {CRYPT}1MeP.wVqzq/uc $ I guess "frontend" database has so called global olcPasswordHash directive in effect over all databases. I also guess, that 1 SSHA form comes from cn=config, and other 5 forms comes from "frontend". Does anyone know if this is true? 5) if above is true, overwriting globals in local database config seems like a solution to me, but ... $ ldapmodify -D "cn=admin,dc=ktu,dc=lt" -W -x <<EOF > dn: olcDatabase={2}hdb,cn=config > changetype: modify > add: olcPasswordHash > olcPasswordHash: {SSHA} > EOF Enter LDAP Password: modifying entry "olcDatabase={2}hdb,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed $ Is it possible to get rid of not secure forms of password schemes? I always believed, that password-hash (olcPasswordHash) should help to do that. Maybe I don't know something? I also think, that it could be related to ITS#7625 <http://www.openldap.org/its/index.cgi/Incoming?id=7625;expression=ppolicy;p…>, why ppolicy shows "Additional info: Password policy only allows one password value" error message. Please, help to clear things out. System: Debian 7.0 (wheezy) OpenLDAP: 2.4.31 (from package) Thank you. -- Pagarbiai, Nerijus Kislauskas KTU ITD, Litnet valdymo centras Studentu g. 48a - 101, Kaunas tel.: (8~37) 30 06 45 mob. tel.: 8-614-93889 e-mail.: nerijus.kislauskas(a)ktu.lt

1 1

Re: Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson 17 Jul '13

17 Jul '13

> So you didn't answer anything about the old version of OpenLDAP versus the > current one. I would note that according to the db_stat output, you've > experienced zero deadlocks. That seems somewhat in conflict with your > earlier report. Did you run db_recover (resetting the stats)? Sorry; I missed that one. We were running 2.4.33 before the upgrade. I have not run db_recover in between the original report and now. It is worth noting that the deadlock errors have ceased in the log file, but I can't speak to whether or not we're more stable than we were before; as I mentioned earlier, it seemed kinda random when it would crash. I was thinking that doing a slapcat and then cleaning out the database files and then slapadd'ing everything back might be helpful. Do you agree? -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

2 1

Re: Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson 17 Jul '13

17 Jul '13

> When you say you upgraded, what all did you do? Did you only upgrade the > openldap binaries? From what openldap release to what release? Did your > upgrade also change the version of BDB? What version of BDB were you on? > What one are you on now? What does your DB_CONFIG file look like? What > does your db_stat -c usage show for locks/lockers/lock objects etc? We're running FreeBSD. I did a minor OS update from 8.2 to 8.4, and then rebuilt all my ports using "portmaster". We're using db46-4.6.21.4 both before and after the upgrade. DB_CONFIG is as follows: set_cachesize 0 67108864 1 set_flags DB_LOG_AUTOREMOVE The output of "db_stat-4.6 -c" is: 116 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 16 Number of current locks 24 Maximum number of locks at any one time 105 Number of current lockers 111 Maximum number of lockers at any one time 16 Number of current lock objects 22 Maximum number of lock objects at any one time 4144507 Total number of locks requested 4144491 Total number of locks released 0 Total number of locks upgraded 36 Total number of locks downgraded 38 Lock requests not available due to conflicts, for which we waited 0 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 712KB The size of the lock region 13666 The number of region locks that required waiting (0%) -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

2 1

Upgrade to 2.4.35 Causes Instability, Errors
by Tim Gustafson 17 Jul '13

17 Jul '13

I recently upgraded OpenLDAP to 2.4.35 and I'm now experiencing some instability issues, and also seeing a bazillion of the following error in my log file: bdb_dn2id_delete 0x108c68: delete failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 I'm using the BDB backend at the moment. One Google search hit I found suggested I switch to MDB instead. Would this help? -- Tim Gustafson tjg(a)ucsc.edu 831-459-5354 Baskin Engineering, Room 313A

3 3

delete members in big groups with back_mdb
by Marco Schirrmeister 17 Jul '13

17 Jul '13

Hi, I have a problem with mdb and modify operations on very large groups. Specifically deleting members from those groups. Removing 10 members from a group with 25000 members takes 23 seconds. Which also means, all other clients that want to do something hang. Deleting a user from multiple big groups takes minutes before it finishes. Adding members to a large group is quick though. When this delete is running, the cpu goes also up to 100%. It looks like it has to do with the index that I have on uniqueMember. If I remove the index on uniqueMember, the delete of members in big groups is fast. System details are CentOS 6 64bit OpenLDAP 2.4.35 slapd.conf below Is this something normal/exptected or is it maybe a bug? Steps to reproduce - Install OpenLDAP 2.4.35 - Import a base ldif - Add a group with 25000 users - Remove 10 members from the group via ldapmodify Example group dn: cn=x3zolgnanlmpzj1nfk21,ou=groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames ou: groups cn: x3zolgnanlmpzj1nfk21 description: aw88bob79vvqffv1fhii uniqueMember: uid=faefxus4e83ywhh7bbgw(a)ough6unnwjdx0zzqiy0i.e3j,ou=people,dc=example,dc=com ... Below is the slapd.conf from a test system where I reproduced it. I used a very minimal config on the test system. ---- slapd.conf ---- include /usr/share/openldap2.4/schema/core.schema include /usr/share/openldap2.4/schema/cosine.schema include /usr/share/openldap2.4/schema/corba.schema include /usr/share/openldap2.4/schema/inetorgperson.schema include /usr/share/openldap2.4/schema/openldap.schema pidfile /var/run/ldap2.4/slapd.pid argsfile /var/run/ldap2.4/slapd.args modulepath /usr/lib64/oldap24/openldap2.4 moduleload back_monitor.la loglevel stats sync serverID 21 ldap://ldap.example.com database mdb suffix "dc=example,dc=com" rootdn "cn=manager,dc=example,dc=com" rootpw secret directory /var/lib/ldap2.4/example.com dbnosync maxsize 107374182400 conn_max_pending_auth 2000 index objectClass eq index uniqueMember eq index entryCSN,entryUUID eq monitoring on database config rootdn "cn=admin,cn=config" rootpw secret database monitor rootdn cn=monitor rootpw secret ---- slapd.conf ---- Thanks Marco

4 6

Q: TLS support
by Ulrich Windl 17 Jul '13

17 Jul '13

Hi! I have some questions on TLS support in OpenLDAP: 1) How can I find out which cipher suite had been configured (when using the distribution-supplied version)? From ldd I guess my slapd is using libopenssl0_9_8. 2) Is the restriction ("This directive is not supported when using GnuTLS.") on TLSCACertificatePath and GunTLS still effective? I'd like to use it, but I'm unsure what the cipher suite is. 3) Do the CA certificates for TLSCACertificateFile have to have a specific ordering? Regards, Ulrich

3 3

OpenLDAP syncrepl using SASL - GSSAPI
by Quentin PETEL 17 Jul '13

17 Jul '13

Hi! I'm trying to implement a Kerberos server using an OpenLdap backend on a server called *ldap1.vm* and replicate those on an other called *ldap2.vm*. My first server is working fine. Each kerberos principal is stored in his own ldap entry (with the krbPrincipalName attribut). For exemple : user1(a)EXEMPLE.COM --> uid=user1,ou=people,dc=exemple,dc=com ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM --> cn=ldap2.vm,ou=ldap,dc=exemple,dc=com I wish to replicate either the cn=config DIT and the dc=exemple,dc=com DIT to my second server. So in my *cn=config* DIT on *ldap1.vm* I have the following configuration : ========================================================== dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcAuthzRegexp: {0}uid=admin,cn=exemple.com,cn=gssapi,cn=auth cn=admin,dc=exemple,dc=com olcAuthzRegexp: {1}uid=ldap\/(.*).exemple.com,cn=exemple.com,cn=gssapi,cn=auth cn=$1,ou=ldap,dc=exemple,dc=com olcAuthzRegexp: {2}uid=host\/(.*).exemple.com,cn=exemple.com,cn=gssapi,cn=auth cn=$1,ou=hosts,dc=exemple,dc=com olcAuthzRegexp: {3}uid=(.*),cn=exemple.com,cn=gssapi,cn=auth uid=$1,ou=people,dc=exemple,dc=com olcSaslRealm: EXEMPLE.COM olcServerID: 1 ldap://ldap1.vm.exemple.com/ olcServerID: 2 ldap://ldap2.vm.exemple.com/ olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}syncprov dn: olcBackend={0}hdb,cn=config objectClass: olcBackendConfig olcBackend: {0}hdb dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcSizeLimit: 500 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcRootDN: *cn=admin,cn=config* dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=exemple,dc=com olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=exemple,dc=com" write by dn.one="ou=ldap,dc=exemple,dc=com" read by anonymous auth by * none olcAccess: {1}to dn.subtree="dc=exemple,dc=com" by dn="cn=adm-srv,ou=krb5,dc=exemple,dc=com" write by dn="cn=kdc-srv,ou=krb5,dc=exemple,dc=com" read by dn="cn=admin,dc=exemple,dc=com" write by dn.one="ou=ldap,dc=exemple,dc=com" read olcAccess: {2}to attrs=loginShell by self write by users read by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to * by users read by * none olcAccess: {5}to dn="cn=config" by dn.one="ou=ldap,dc=exemple,dc=com" write olcLastMod: TRUE olcRootDN: cn=admin,dc=exemple,dc=com olcRootPW: {SSHA}7JR5Gh0ZUbw9U4cVytBrChBjXuPAdLKh olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: cn eq olcDbIndex: ou eq olcDbIndex: dc eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: memberUid eq olcDbIndex: uniqueMember eq olcDbIndex: krbPrincipalName eq,pres,sub olcDbIndex: krbPwdPolicyReference eq dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 ========================================================== And on the ldap2.vm i wanna replicate the cn=config DIT first: ========================================================== dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcRootDN: cn=admin,cn=config olcSyncrepl: {0}rid=001 provider="ldap://ldap1.vm.exemple.com/" type=refreshAndPersist retry="10 30 30 +" searchbase="cn=config" bindmethod=sasl saslmech=gssapi ========================================================== There is no olcMirrorMode attributes because I wanna add other provider directives later. Every 10 secondes, i see those logs: ========================================================== conn=1001 fd=13 ACCEPT from IP=192.168.x.x:57695 (IP=0.0.0.0:389) conn=1001 op=0 BIND dn="" method=163 conn=1001 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: conn=1001 op=1 BIND dn="" method=163 conn=1001 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: conn=1001 op=2 BIND dn="" method=163 conn=1001 op=2 BIND authcid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM" authzid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM" conn=1001 op=2 BIND dn="cn=ldap2.vm,ou=ldap,dc=exemple,dc=com" mech=GSSAPI sasl_ssf=56 ssf=56 conn=1001 op=2 RESULT tag=97 err=0 text= conn=1001 op=3 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" conn=1001 op=3 SRCH attr=* + findbase failed! 32 conn=1001 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text= conn=1001 op=4 UNBIND conn=1001 fd=13 closed ========================================================== We see that the olcAuthzRegexp do is job, indeed, the authcid="ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM" from the ticket (I use Kstart to obtain it) become dn="cn=ldap2.vm,ou=ldap,dc=exemple,dc=com". But it fail to find the cn=config DIT. Here is the entry on my ldap database: ========================================================== dn: cn=ldap2.vm,ou=ldap,dc=exemple,dc=com objectClass: ipHost objectClass: device objectClass: top objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux cn: ldap2.vm ipHostNumber: 192.168.x.x structuralObjectClass: device entryUUID: afe9a32a-81a3-1032-85b7-7976b72b0c24 creatorsName: cn=admin,dc=exemple,dc=com createTimestamp: 20130715140754Z krbPrincipalName: ldap/ldap2.vm.exemple.com(a)EXEMPLE.COM krbLoginFailedCount: 0 krbPrincipalKey:: [...] krbPasswordExpiration: 19700101000000Z krbLastPwdChange: 20130715140838Z krbExtraData:: AAJmAuRRYWRtaW5ASU5URVJORS5PQlNFUlZBVE9JUkVERVNNQVJRVUVTLkZSAA= = krbExtraData:: AAgBAA== authzTo: {0}dn.regex:*cn=admin,cn=config* entryCSN: 20130716154135.008692Z#000000#001#000000 modifiersName: cn=admin,dc=exemple,dc=com modifyTimestamp: 20130716154135Z ========================================================== The authzTo directive allow, i think, this entry to act as cn=admin,cn=config and to see the cn=config DIT, am I wrong? How can I do what I want? This configuration works well when I try to synchronise the dc=exemple,dc=com DIT. Regards, Quentin

1 1

Problems with ACLs
by Leonardo Bacha Abrantes 16 Jul '13

16 Jul '13

Hi guys, I configured ACL (below) and am trying to log on the console with a ldap's user I receive the error "ldap_search_s No such object' on /var/log/secure. If I comment acls the user is able to logon. Here my configuration: ==>> olcDatabase={2}bdb.ldif olcRootDN: cn=Manager,dc=foo,dc=local olcRootPW: {MD5}xxxxxxxxxxxxxxxxx olcAccess: to attrs=userPassword by self write olcAccess: to attrs=cn,sn,displayName,mail,description by users read olcaccess: to * by self read I used slapacl to check the permissions and appeared ok. What I'm doing worng ? Can you help me please ?

2 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2013