openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

cant create child entrys
by robert k Wild 28 Dec '16

28 Dec '16

hi all, i cant create child entrys apart from OU and OR, why is this? i have installed openldap on a centos 7 vm and also phpldapadmin to manage the ldap server i imagine this is an openldap issue and not a php ldap admin issue https://s28.postimg.org/l5zb58h4t/Capture.png -- Regards, Robert K Wild.

2 2

2.4.44 segfault in modify_add_values
by Paul B. Henson 25 Dec '16

25 Dec '16

Woke up this morning to an unwanted Christmas present :(, one of my ldap servers had crashed with a segfault: Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h ldaps:// ldap://'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000485c61 in modify_add_values () [Current thread is 1 (Thread 0x7f50727fd700 (LWP 15556))] (gdb) where #0 0x0000000000485c61 in modify_add_values () #1 0x00007f526dfccd0c in mdb_modify_internal () from /usr/lib64/openldap/openldap/back_mdb.so #2 0x00007f526dfce134 in mdb_modify () from /usr/lib64/openldap/openldap/back_mdb.so #3 0x000000000049c2ea in overlay_op_walk () #4 0x000000000049c441 in ?? () #5 0x000000000048d938 in ?? () #6 0x00000000004915d7 in ?? () #7 0x0000000000495793 in ?? () #8 0x0000000000433037 in ?? () #9 0x00007f5272c83a32 in ?? () from /usr/lib64/libldap_r-2.4.so.2 #10 0x00007f52722ce494 in start_thread () from /lib64/libpthread.so.0 #11 0x00007f52719c6edd in clone () from /lib64/libc.so.6 The last bit in the log was an update, then it ended: Dec 25 03:31:03 fosse slapd[3333]: conn=561646 op=3 MOD dn="uid=aapriest,ou=user,dc=csupomona,dc=edu " Dec 25 03:31:03 fosse slapd[3333]: conn=561646 op=3 MOD attr=csupomonaEduPersonExpiration When I saw the alert on my phone when I woke up I assumed it would have something to do with the memberOf overlay issues I was already looking into but this seems different. I restarted it and it synced right back up from the failover master and seems to be ok now. Does this pop out as anything known and possibly resolved in head? Thanks...

1 0

LDAP User can't login can su to with root account
by Frank Yu 24 Dec '16

24 Dec '16

Hi All, I have setup a LDAP service on host A, and configure ldap client on host B. when I tried to login host B with user which already added in LDAP server, it report error even through I enter right passwd shanzhi.yu(a)10.10.10.101's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password Permission denied, please try again. shanzhi.yu(a)10.10.10.101's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password Permission denied, please try again. shanzhi.yu(a)10.10.10.101's password:" and, I can su to user shanzhi.yu on host B [root@ host B ~]# su shanzhi.yu [shanzhi.yu@ host B root]$ cd [shanzhi.yu@ host B ~]$ What's the problem? any config should I do? Thanks -- Regards Frank Yu

2 4

Bulk change user's attribute
by Bruno Miguel Martins 23 Dec '16

23 Dec '16

Hello guys, I am running slapd 2.3.30 and I need to bulk modify one LDAP attribute (sambaHomePath) for all of my users, like: Current value = \\oldserver\username<file://oldserver/username> New value = \\newserver\username<file://newserver/username> Can this be done? Basically I need a partial change of that attribute - "oldserver" which is variable, changed with "newserver" which is fixed. Thank you! [cid:image002.png@01D25D11.3775A610] BRUNO MIGUEL MARTINS | System Engineer +351 926 845 866 www.iten.pt<http://www.iten.pt>

1 0

help with ACL
by Alberto Aldrigo 23 Dec '16

23 Dec '16

1 0

Re: memberOf overlay issues with 2.4.44 + ITS 8432 patch
by Quanah Gibson-Mount 22 Dec '16

22 Dec '16

----- Original Message ----- > From: "Paul B. Henson" <henson(a)acm.org> > To: openldap-technical(a)openldap.org > Sent: Wednesday, December 21, 2016 6:56:30 PM > Subject: memberOf overlay issues with 2.4.44 + ITS 8432 patch > So far, I've only seem this behavior for group membership removals. Adds > don't seem to cause a problem, nor do create/delete of groups or users > as far as I can tell. > > Any thoughts on what's going on here? It's not causing any failures yes, > as removing members multiple times results in the same end state and the > multiple replication seems to have a fairly low upper bound. But it > would be nice to fix it :). Looks like a bug with the memberOf overlay when it is instantiated in a delta-syncrepl environment, based on this statement from the memberOf man page: The memberof overlay may be used with any backend that provides full read-write functionality, but it is mainly intended for use with local storage backends. The maintenance operations it performs are internal to the server on which the overlay is configured and are never replicated. Replica servers should be configured with their own instances of the memberOf overlay if it is desired to maintain these memberOf attributes on the replicas. Probably worth adding to ITS#8444. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: ppolicy overlay unable to set pwdAccountLockedTime on to-be-locked users due to ACLs
by Howard Chu 22 Dec '16

22 Dec '16

Matthieu Cerda wrote: > Hello folks, > > I just stumbled upon a (maybe not) surprising technical issue with my > OpenLDAP setup: ppolicy seems unable to update pwdAccountLockedTime on > my users. > > Setup: > > * OpenLDAP 2.4.40(+dfsg-1+deb8u2) on Debian jessie > > * Password policy and ACLs: > > ---8<--- > dn: cn=default,ou=policies,dc=company,dc=com > objectClass: top > objectClass: person > objectClass: pwdPolicy > cn: passwordDefault > cn: default > pwdAttribute: userPassword > sn: passwordDefault > pwdAllowUserChange: TRUE > pwdCheckQuality: 0 > pwdExpireWarning: 0 > pwdFailureCountInterval: 0 > pwdGraceAuthNLimit: 0 > pwdInHistory: 3 > pwdLockout: TRUE > pwdLockoutDuration: 300 > pwdMaxAge: 0 > pwdMaxFailure: 3 > pwdMinAge: 0 > pwdMinLength: 8 > pwdMustChange: FALSE > pwdSafeModify: FALSE > ---8<--- > > ---8<--- > access to attrs=userPassword,shadowLastChange > by dn="uid=mcerda,ou=people,dc=company,dc=com" write > by self write > by anonymous auth > by * none > > access to dn.base="" by * read > > access to * > by dn="uid=mcerda,ou=people,dc=company,dc=com" write > by users read > by * none > ---8<--- > > * pwdFailureTime gets updated on each failed login attempt on users > until pwdMaxFailure is reached (3) > > * Testing for account locking is done both by observing we appearance in > user object and using '-e ppolicy' on ldapsearch (ppolicy_use_lockout is > enabled) > > Everytime an user reaches pwdMaxFailure count, the debug log (level > 65535) gives: > > ---8<--- > 585947a5 => mdb_entry_get: found entry: > "cn=default,ou=policies,dc=company,dc=com" > 585947a5 mdb_entry_get: rc=0 > 585947a5 mdb_modify: uid=fbar,ou=people,dc=company,dc=com > 585947a5 slap_queue_csn: queueing 0x65696ef4bce0 > 20161220150053.705334Z#000000#000#000000 > 585947a5 mdb_dn2entry("uid=fbar,ou=people,dc=company,dc=com") > 585947a5 => mdb_dn2id("uid=fbar,ou=people,dc=company,dc=com") > 585947a5 <= mdb_dn2id: got id=0x9 > 585947a5 => mdb_entry_decode: > 585947a5 <= mdb_entry_decode > 585947a5 mdb_modify_internal: 0x00000009: > uid=fbar,ou=people,dc=company,dc=com > 585947a5 => access_allowed: result not in cache (pwdAccountLockedTime) > 585947a5 => access_allowed: delete access to > "uid=fbar,ou=people,dc=company,dc=com" "pwdAccountLockedTime" requested > 585947a5 => dn: [2] > 585947a5 => acl_get: [3] attr pwdAccountLockedTime > 585947a5 => acl_mask: access to entry > "uid=fbar,ou=people,dc=company,dc=com", attr "pwdAccountLockedTime" > requested > 585947a5 => acl_mask: to all values by "", (=0) > 585947a5 <= check a_dn_pat: uid=mcerda,ou=people,dc=company,dc=com > 585947a5 <= check a_dn_pat: users > 585947a5 <= check a_dn_pat: anonymous > 585947a5 <= acl_mask: [3] applying read(=rscxd) (stop) > 585947a5 <= acl_mask: [3] mask: read(=rscxd) > 585947a5 => slap_access_allowed: delete access denied by read(=rscxd) > 585947a5 => access_allowed: no more rules > 585947a5 mdb_modify: modify failed (50) > 585947a5 send_ldap_result: conn=1000 op=0 p=3 > 585947a5 send_ldap_result: err=50 matched="" text="" > 585947a5 slap_graduate_commit_csn: removing 0x6569601047f0 > 20161220150053.705334Z#000000#000#000000 > 585947a5 send_ldap_response: msgid=1 tag=97 err=49 > ---8<--- > > I can't see a reason why the update gets denied. Setting the global ACL to: > > ---8<--- > access to * > by dn="uid=mcerda,ou=people,dc=company,dc=com" write > by * write > ---8<--- > > fixes the issue (but I obviously not want an open bar slapd). > > The documentation (http://www.openldap.org/doc/admin24/overlays.html) > advises nothing about ACLs. That is not the documentation, that is only a guide. The manpages are the authoritative documentation. > > Is this and issue or a misconfiguration ? Read the slapo-ppolicy(5) manpage. > > Thanks in advance, -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

memberOf overlay issues with 2.4.44 + ITS 8432 patch
by Paul B. Henson 21 Dec '16

21 Dec '16

I recently updated to openldap 2.4.44 with the patch for ITS 8432. I'd been holding off in hopes of a new release with that patch included and for some update on ITS 8444, but decided to go ahead and push it through during the holiday break. I installed it on my dev environment and was unable to replicate the issues reported in ITS 8444 so went ahead and rolled into production. However, now that I'm in production, I'm seeing different issues with the memberOf overlay. It seems for some reason group membership deletions are getting replicated multiple times? In the logs, I will see something like the following: Dec 21 04:16:59 themis slapd[2607]: conn=364875 op=227806 MOD dn="uid=members,ou=group,dc=cpp,dc=edu" Dec 21 04:16:59 themis slapd[2607]: conn=364875 op=227806 MOD attr=member My identity management system connected and removed some members from this group. Next, there will be a number of lines like this: Dec 21 04:17:15 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:16 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:17 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=c Where the memberOf overlay is complaining that it can't remove the corresponding memberOf attribute from the user. Reviewing the accesslog, we see: dn: reqStart=20161221121659.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121659.000002Z reqEnd: 20161221121706.000000Z reqType: modify reqSession: 364875 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu The initial tranaction from my client, authenticated as cn=idmgmt. This one is successful and the overlay deletes the memberOf attribute. However, there are then *six* more instances of the same transaction: dn: reqStart=20161221121714.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121714.000001Z reqEnd: 20161221121715.000000Z reqType: modify reqSession: 3 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121716.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121716.000001Z reqEnd: 20161221121716.000002Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121716.000004Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121716.000004Z reqEnd: 20161221121717.000002Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121717.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121717.000001Z reqEnd: 20161221121718.000000Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121718.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121718.000001Z reqEnd: 20161221121718.000002Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121718.000003Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121718.000003Z reqEnd: 20161221121718.000004Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu These are are performed by cn=ldaproot, and correspond to the six error messages from the overlay about failing to remove the attribute (which was already removed). Similarly, on a replica: Dec 21 04:17:16 coeus slapd[2841]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 There is one error, because there are two copies of the transaction: dn: reqStart=20161221121706.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121706.000001Z reqEnd: 20161221121716.000000Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121714.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121714.000002Z reqEnd: 20161221121716.000001Z reqType: modify reqSession: 3 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu So far, I've only seem this behavior for group membership removals. Adds don't seem to cause a problem, nor do create/delete of groups or users as far as I can tell. Any thoughts on what's going on here? It's not causing any failures yes, as removing members multiple times results in the same end state and the multiple replication seems to have a fairly low upper bound. But it would be nice to fix it :). Thanks...

1 0

ppolicy overlay unable to set pwdAccountLockedTime on to-be-locked users due to ACLs
by Matthieu Cerda 21 Dec '16

21 Dec '16

Hello folks, I just stumbled upon a (maybe not) surprising technical issue with my OpenLDAP setup: ppolicy seems unable to update pwdAccountLockedTime on my users. Setup: * OpenLDAP 2.4.40(+dfsg-1+deb8u2) on Debian jessie * Password policy and ACLs: ---8<--- dn: cn=default,ou=policies,dc=company,dc=com objectClass: top objectClass: person objectClass: pwdPolicy cn: passwordDefault cn: default pwdAttribute: userPassword sn: passwordDefault pwdAllowUserChange: TRUE pwdCheckQuality: 0 pwdExpireWarning: 0 pwdFailureCountInterval: 0 pwdGraceAuthNLimit: 0 pwdInHistory: 3 pwdLockout: TRUE pwdLockoutDuration: 300 pwdMaxAge: 0 pwdMaxFailure: 3 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: FALSE pwdSafeModify: FALSE ---8<--- ---8<--- access to attrs=userPassword,shadowLastChange by dn="uid=mcerda,ou=people,dc=company,dc=com" write by self write by anonymous auth by * none access to dn.base="" by * read access to * by dn="uid=mcerda,ou=people,dc=company,dc=com" write by users read by * none ---8<--- * pwdFailureTime gets updated on each failed login attempt on users until pwdMaxFailure is reached (3) * Testing for account locking is done both by observing we appearance in user object and using '-e ppolicy' on ldapsearch (ppolicy_use_lockout is enabled) Everytime an user reaches pwdMaxFailure count, the debug log (level 65535) gives: ---8<--- 585947a5 => mdb_entry_get: found entry: "cn=default,ou=policies,dc=company,dc=com" 585947a5 mdb_entry_get: rc=0 585947a5 mdb_modify: uid=fbar,ou=people,dc=company,dc=com 585947a5 slap_queue_csn: queueing 0x65696ef4bce0 20161220150053.705334Z#000000#000#000000 585947a5 mdb_dn2entry("uid=fbar,ou=people,dc=company,dc=com") 585947a5 => mdb_dn2id("uid=fbar,ou=people,dc=company,dc=com") 585947a5 <= mdb_dn2id: got id=0x9 585947a5 => mdb_entry_decode: 585947a5 <= mdb_entry_decode 585947a5 mdb_modify_internal: 0x00000009: uid=fbar,ou=people,dc=company,dc=com 585947a5 => access_allowed: result not in cache (pwdAccountLockedTime) 585947a5 => access_allowed: delete access to "uid=fbar,ou=people,dc=company,dc=com" "pwdAccountLockedTime" requested 585947a5 => dn: [2] 585947a5 => acl_get: [3] attr pwdAccountLockedTime 585947a5 => acl_mask: access to entry "uid=fbar,ou=people,dc=company,dc=com", attr "pwdAccountLockedTime" requested 585947a5 => acl_mask: to all values by "", (=0) 585947a5 <= check a_dn_pat: uid=mcerda,ou=people,dc=company,dc=com 585947a5 <= check a_dn_pat: users 585947a5 <= check a_dn_pat: anonymous 585947a5 <= acl_mask: [3] applying read(=rscxd) (stop) 585947a5 <= acl_mask: [3] mask: read(=rscxd) 585947a5 => slap_access_allowed: delete access denied by read(=rscxd) 585947a5 => access_allowed: no more rules 585947a5 mdb_modify: modify failed (50) 585947a5 send_ldap_result: conn=1000 op=0 p=3 585947a5 send_ldap_result: err=50 matched="" text="" 585947a5 slap_graduate_commit_csn: removing 0x6569601047f0 20161220150053.705334Z#000000#000#000000 585947a5 send_ldap_response: msgid=1 tag=97 err=49 ---8<--- I can't see a reason why the update gets denied. Setting the global ACL to: ---8<--- access to * by dn="uid=mcerda,ou=people,dc=company,dc=com" write by * write ---8<--- fixes the issue (but I obviously not want an open bar slapd). The documentation (http://www.openldap.org/doc/admin24/overlays.html) advises nothing about ACLs. Is this and issue or a misconfiguration ? Thanks in advance, -- Matthieu Cerda

2 1

Re: PID File
by Quanah Gibson-Mount 21 Dec '16

21 Dec '16

Actually to start with, try using the correct db_recover binary while in the data directory. If that fails, then remove the alock file and see if slapd will start. Sadly not uncommon for alock to report problems incorrectly. But agree, best thing to do after those steps is move to back-mdb on a current release. --Quanah > On Dec 20, 2016, at 1:41 PM, Clément OUDOT <clem.oudot(a)gmail.com> wrote: > > 2016-12-20 22:35 GMT+01:00 Singley, Norman <Norman.Singley(a)mso.umt.edu>: >> Thanks. Here are the results. I can start googling this result, but I am kind of a newbie at openldap, so if you know something obvious, let me know. Thank you very much. >> >> >> # service slapd debug >> slapd: [INFO] Using /etc/default/slapd for configuration >> slapd: [INFO] Halting OpenLDAP... >> slapd: [INFO] Can't read PID file, to stop OpenLDAP try: /etc/init.d/slapd forcestop >> slapd: [INFO] No db_recover done >> slapd: [INFO] Launching OpenLDAP... >> slapd: [OK] File descriptor limit set to 1024 >> 5859a359 @(#) $OpenLDAP: slapd 2.4.36 (Apr 8 2014 12:06:19) $ >> username@itds120.umt.edu:/u01/app/openldap-2.4.36/servers/slapd >> 5859a359 hdb_db_open: database "dc=umt,dc=edu": alock package is unstable. >> 5859a359 backend_startup_one (type=hdb, suffix="dc=umt,dc=edu"): bi_db_open failed! (-1) >> 5859a359 slapd stopped > > > The database seems corrupted. > > You can try to slapcat to get a backup of the data (or try service > slapd backup). Then remove all files and reimport data with slapadd > (or try service slapd restore). > > > You should then try to upgrade to 2.4.44 and use LMDB backend. > > > Clément. >

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical