openldap-technical

openldap-technical@openldap.org

12 participants
9794 discussions

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

PID File
by Singley, Norman 20 Dec '16

20 Dec '16

Hi Folks - I am getting the No PID file for openLDAP error when starting/stopping slapd. run]# /etc/init.d/slapd stop 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 [root@itds120 run]# /etc/init.d/slapd forcestop slapd: [INFO] Using /etc/default/slapd for configuration slapd: [INFO] Killing OpenLDAP with force... slapd: [INFO] Found no OpenLDAP process running with ldap://oldap.umt.edu:389 ldaps://oldap.umt.edu:636 slapd: [INFO] Killing OpenLDAP replication with force... slapd: [INFO] Found no slurpd process running [root@itds120 run]# ps -ea | grep slapd 6723 ? 00:00:00 slapd [root@itds120 run]# /etc/init.d/slapd start slapd: [INFO] Using /etc/default/slapd for configuration slapd: [INFO] Launching OpenLDAP configuration test... slapd: [OK] OpenLDAP configuration test successful slapd: [INFO] No db_recover done slapd: [INFO] Launching OpenLDAP... slapd: [OK] File descriptor limit set to 1024 slapd: [ALERT] No PID file for OpenLDAP [root@itds120 run]# ps -ea | grep slapd 6723 ? 00:00:00 slapd It seems to show that openLDAP is running on this box, but I can't connect to it. The slapd.conf file is attached. I see a lot of results about this error out there on the web, but most of the fixes like manually creating the pid file don't seem to work. If anyone has any tips I can try, it would be greatly appreciated. This is a standalone (test oldap, running 2.4.36) on redhat 6. Thanks in advance. Norman Singley Directory Services 406 243 6799 Norman.singley(a)mso.umt.edu

2 3

Re: Antw: RE: Constraint violation when swapping two unique attributes
by Howard Chu 20 Dec '16

20 Dec '16

Bannister, Mark wrote: > Howard Chu wrote: >>> Ulrich Windl wrote: >>>>>>> Ulrich Windl schrieb am 20.12.2016 um 08:09 in Nachricht <5858D90F.7AD : 161 : 60728>: >>>>>>>> "Bannister, Mark" <Mark.Bannister(a)morganstanley.com> schrieb am >>>>>>>> 19.12.2016 um >>>>> 16:43 in Nachricht >>>>> >>>>> [...] >>>>>> Agreed. LDAP doesn't have a swap operation. There's a shame. >>>>> [...] >>>>> >>>>> More generally LDAP has no transactions for updates. I wonder if a >> >> Wrong, LDAP Transactions are specified in RFC 5805. Please stop posting misinformation to this list. > > Interesting. I see RFC 5805 is classified as "experimental". How widely is it implemented? Does OpenLDAP support it? Does an LDAP client support it? If they did this would solve my constraint violation problem, I presume. Support is merged in the OpenLDAP 2.5 release branch. Unclear that this would help you, which is why I didn't mention it before. It depends on when the constraint overlay takes effect. The overlay will still see two independent operations, even though a transaction is in place. You're still better off doing the rename - that will work on all existing LDAP implementations. And to the list in general - you're better off ignoring all of Ulrich Windl's posts. He clearly has no idea what he's talking about, and over the past couple years has shown no evidence of improving his knowledge. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Antw: RE: Constraint violation when swapping two unique attributes
by Howard Chu 20 Dec '16

20 Dec '16

Bannister, Mark wrote: > Ulrich Windl wrote: >>>>> Ulrich Windl schrieb am 20.12.2016 um 08:09 in Nachricht <5858D90F.7AD : 161 : 60728>: >>>>>> "Bannister, Mark" <Mark.Bannister(a)morganstanley.com> schrieb am >>>>>> 19.12.2016 um >>> 16:43 in Nachricht >>> >>> [...] >>>> Agreed. LDAP doesn't have a swap operation. There's a shame. >>> [...] >>> >>> More generally LDAP has no transactions for updates. I wonder if a Wrong, LDAP Transactions are specified in RFC 5805. Please stop posting misinformation to this list. -- -- 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

RE: Antw: RE: Constraint violation when swapping two unique attributes
by Bannister, Mark 20 Dec '16

20 Dec '16

Ulrich Windl wrote: > >>> Ulrich Windl schrieb am 20.12.2016 um 08:09 in Nachricht <5858D90F.7AD : 161 : 60728>: > >>>> "Bannister, Mark" <Mark.Bannister(a)morganstanley.com> schrieb am > >>>> 19.12.2016 um > > 16:43 in Nachricht > > > > [...] > > > Agreed. LDAP doesn't have a swap operation. There's a shame. > > [...] > > > > More generally LDAP has no transactions for updates. I wonder if a > > transaction mechanism could be implemented using LDAP extensions. > > Occassionally for some mass-update I'd prefer the whole update to fail > > if a few operations failed. Currently you'll have to fix each failing > > operation separately... > > And of course it would be cool if LDIF could be extended to be able to bracket changes with transactions, > so automation could be made easier, maybe even breaking mass updates into managable chunks... I'm sure that would be a difficult change to make. I tried putting in something close to this in the PROSE Programming Language, which is a language extension on top of an LDAP data model. I provided a way of guaranteeing atomicity when there are multiple add, modify or delete operations to perform on a single object, so that if any single in the list failed then none of the changes are left applied, and I also invented the concept of an "object edit buffer" where you could group together adds, mods and deletes in a single transaction which you commit in a single step. However, this is internal to the language and does not extend to LDAP nor LDIF, was very difficult to implement in a consistent manner, does not encompass changes to multiple objects and has no solution at all that will work with virtual attributes. In summary, what you ask is very hard to do well. Mark. -------------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.

1 0

Re: OpenLDAP ACL causing error code 49
by Quanah Gibson-Mount 19 Dec '16

19 Dec '16

--On Monday, December 19, 2016 10:33 AM -0500 Matty <matty91(a)gmail.com> wrote: > Does anyone happen to know why "acl_mask: to value by" shows "" > instead of the dn of the user passed to the "-D" option? The > suggestions above work but I am still curious why the anonymous bind > is occurring. There is no way for the LDAP server to know that the connection claiming to be DN "X" is actually that DN until /after/ authentication occurs. Thus, until the point at which authentication is successful, the connection is treated as anonymous. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Constraint violation when swapping two unique attributes
by Howard Chu 19 Dec '16

19 Dec '16

Bannister, Mark wrote: > Hi, > > > > I’m using the unique overlay on OpenLDAP 2.4.30 on Solaris 11.3 like this: > > > > overlay unique > > unique_uri > ldap:///ou=Ethers,dc=mydomain,dc=com?macAddress?sub?objectClass=ieee802Device > > > > to force the macAddress to be unique. > > > > This works well, except if I attempt to swap the macAddress between two > entries in a single LDAP modify operation, like this: > > > > dn: cn=host1-eth0,ou=Ethers,dc=mydomain,dc=com > > changetype: modify > > replace: macAddress > > macAddress: <current host1-eth1 value> > > > > dn: cn=host1-eth1,ou=Ethers,dc=mydomain,dc=com > > changetype: modify > > replace: macAddress > > macAddress: <current host1-eth0 value> That's two separate modify operations, not a single operation. > > > > I get: > > > > ldap_modify: Constraint violation (19) > > additional info: some attributes not unique > > > > Is there a way to swap two values without tripping this error? Seems unlikely. Why don't you rename the entries instead? > > > > Thanks, > > Mark. > > > > ------------------------------------------------------------------------------ > > NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions > or views contained herein are not intended to be, and do not constitute, > advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform > and Consumer Protection Act. If you have received this communication in error, > please destroy all electronic and paper copies and notify the sender > immediately. Mistransmission is not intended to waive confidentiality or > privilege. Morgan Stanley reserves the right, to the extent permitted under > applicable law, to monitor electronic communications. This message is subject > to terms available at the following link: > http://www.morganstanley.com/disclaimers If you cannot access these links, > please notify us by reply message and we will send the contents to you. By > communicating with Morgan Stanley you consent to the foregoing and to the > voice recording of conversations with personnel of Morgan Stanley. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 3

Re: OpenLDAP ACL causing error code 49
by Matty 19 Dec '16

19 Dec '16

On Mon, Nov 21, 2016 at 12:45 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, November 21, 2016 6:41 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > >> Matty wrote: >>> >>> I am testing some OpenLDAP ACLs and stumbled on a weird issue. My >>> configuration has the following ACL defined: >>> >>> access to * >>> by users read >>> by peername.ip=1.2.3.4 read >>> by * none >> >> ^^^^ >> You probably want "auth" in this last <who> clause. >> >> Ciao, Michael. >> > > or: > by anonymous auth > by * none > > may be closer. That works as well but I'm still not real clear why running: $ ldapsearch -b 'dc=foo,dc=com' -x -h ldap1 -W -D 'uid=bingo,ou=users,dc=foo,dc=com' '(objectClass=*)' Results in an anonymous bind: Nov 16 09:50:02 tulip slapd[17803]: => acl_get: [2] attr userPassword Nov 16 09:50:02 tulip slapd[17803]: => acl_mask: access to entry "uid=bingo,ou=users,dc=foo,dc=com", attr "userPassword" requested Nov 16 09:50:02 tulip slapd[17803]: => acl_mask: to value by "", (=0) Does anyone happen to know why "acl_mask: to value by" shows "" instead of the dn of the user passed to the "-D" option? The suggestions above work but I am still curious why the anonymous bind is occurring. Thanks for the awesome feedback, - Ryan

1 0

Constraint violation when swapping two unique attributes
by Bannister, Mark 19 Dec '16

19 Dec '16

Hi, I'm using the unique overlay on OpenLDAP 2.4.30 on Solaris 11.3 like this: overlay unique unique_uri ldap:///ou=Ethers,dc=mydomain,dc=com?macAddress?sub?objectClass=ieee802Device to force the macAddress to be unique. This works well, except if I attempt to swap the macAddress between two entries in a single LDAP modify operation, like this: dn: cn=host1-eth0,ou=Ethers,dc=mydomain,dc=com changetype: modify replace: macAddress macAddress: <current host1-eth1 value> dn: cn=host1-eth1,ou=Ethers,dc=mydomain,dc=com changetype: modify replace: macAddress macAddress: <current host1-eth0 value> I get: ldap_modify: Constraint violation (19) additional info: some attributes not unique Is there a way to swap two values without tripping this error? Thanks, Mark. ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical