openldap-technical July 2020

openldap-technical@openldap.org

29 participants
35 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

slapd daemon stop issue
by Technology Server 31 Jul '20

31 Jul '20

Dears We were trying to stop slapd daemon but after some time it is coming up on its own. We have provision and replication daemon. We tried it by killing pid also but unfortunately its coming up on its own. We have active - active set up for openldap. what could be the reason that pointing daemon to come up after shut manually. Please suggest on this ? note - We don't have any script which could bring it up when it goes down Thank you in advance for suggestions.

2 1

RE24 testing call #1 (OpenLDAP 2.4.50, LMDB 0.9.26)
by Quanah Gibson-Mount 30 Jul '20

30 Jul '20

This is the first testing call for OpenLDAP 2.4.51. Depending on the results, this may be the only testing call. Generally, get the code for RE24: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.51 Engineering Added slapo-ppolicy implement Netscape password policy controls (ITS#9279) Fixed libldap retry loop in ldap_int_tls_connect (ITS#8650) Fixed libldap to use getaddrinfo in ldap_pvt_get_fqdn (ITS#9287) Fixed slapd syncrepl to not delete non-replicated attrs (ITS#9227) Fixed slapd syncrepl to correctly delete entries on resync (ITS#9282) Fixed slapd-perl dynamic config with threaded slapd (ITS#7573) Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285) Fixed slapo-chain to check referral (ITS#9262) Contrib Fix default prefix value for pw-argon2, pw-pbkdf2 modules (ITS#9248) Documentation ldap_parse_result(3) - Document ldap_parse_intermediate (ITS#9271) LMDB 0.9.26 Engineering ITS#9278 fix robust mutex cleanup for FreeBSD -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 20

LDAP error, server says:,(8) Strong(er) authentication required
by Lothar Schilling 28 Jul '20

28 Jul '20

Hi everybody, I am completely new to this group - and to OpenLDAP as well. Trying to get rid of our Windows SBS domain controller I am building a new Samba 4 server dedicated only to domain controlling, Debian 10.4, Samba 4.9.5. I'm doing this from scratch, following the textbooks. I've also setup LAM as graphical interface for administration. But once I try logging into the server's profile via that LAM interface as Administrator, I get this: "LDAP error, server says: (8) Strong(er) authentication required". (1) "ldbsearch -H ldap://ldap.[my].[domain] "cn=Administrator" -k yes": is working with the same password I would use in LAM (2) Server profile settings in LAM - TLS is deactivated - Login: Fixed list, cn=Administrator,cn=users,dc=[my],dc=[domain] (3) ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=[my],dc=[domain] URI ldap://ldap.[my].[domain] ldap://ldap-master.[my].[domain]:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) #TLS_CACERT /etc/ssl/certs/ca-certificates.crt What am I doing wrong? Help appreciated, thank you! Lothar Schilling

2 2

Re: RE24 testing call #1 (OpenLDAP 2.4.51, LMDB 0.9.26)
by Nick Folino 24 Jul '20

24 Jul '20

No issues on Fedora 32 - 5.7.8-200.fc32.x86_64 3 different computers with the following processors: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx Intel(R) Xeon(R) CPU E5630 @ 2.53GHz Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz On Thu, Jul 23, 2020 at 6:14 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Subject correction -- 2.4.51. ;) > > --Quanah > > --On Thursday, July 23, 2020 4:02 PM -0700 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > > > This is the first testing call for OpenLDAP 2.4.51. Depending on the > > results, this may be the only testing call. > > > > Generally, get the code for RE24: > > > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_ > > 4/openldap-OPENLDAP_REL_ENG_2_4.tar.gz> > > > > Extract, configure, and build. > > > > Execute the test suite (via make test) after it is built. Optionally, cd > > tests && make its to run through the regression suite. > > > > Thanks! > > > > OpenLDAP 2.4.51 Engineering > > Added slapo-ppolicy implement Netscape password policy controls > > (ITS#9279) > > Fixed libldap retry loop in ldap_int_tls_connect (ITS#8650) > > Fixed libldap to use getaddrinfo in ldap_pvt_get_fqdn (ITS#9287) > > Fixed slapd syncrepl to not delete non-replicated attrs (ITS#9227) > > Fixed slapd syncrepl to correctly delete entries on resync (ITS#9282) > > Fixed slapd-perl dynamic config with threaded slapd (ITS#7573) > > Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285) > > Fixed slapo-chain to check referral (ITS#9262) > > Contrib > > Fix default prefix value for pw-argon2, pw-pbkdf2 modules > > (ITS#9248) > > Documentation > > ldap_parse_result(3) - Document ldap_parse_intermediate > (ITS#9271) > > > > LMDB 0.9.26 Engineering > > ITS#9278 fix robust mutex cleanup for FreeBSD > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <http://www.symas.com> > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Questions regarding certain ACL constructs
by Michal Soltys 24 Jul '20

24 Jul '20

Hi, Just wanted to ask/clarify about few things related to ACLs: 1) @extensibleObject In one of the faq entries, namely: https://www.openldap.org/faq/data/cache/1140.html there is a construct that looks superfluous: access to dn.onelevel="cn=bar,ou=Stuff,dc=example,dc=com" attrs=entry,@extensibleObject Doesn't @extensibleObject include everything - entry, children and regular attributes - by default ? That's what I'd imply from the official documentation that states that not explicitly specifying attrs= is equivalent to attrs=@extensibleObject If so, then the above is equivalent to just: access to dn.onelevel="cn=bar,ou=Stuff,dc=example,dc=com" 2) entry pseudo-attribute vs writing to regular attributes This is one thing that somewhat surprises me - as the read/search access explicitly requires relevant access to entry pseudo-attribute (as per OPERATION REQUIREMENTS from slapd.access manpage). The write access on the other hand doesn't mention any requirements besides add/delete/write to the attribute itself. This actually holds true right ? 3) attr based access In one of the examples (8.4.5. Granting access to a subset of attributes), question regarding: # immediate children: only self can add/delete entries under this entry access to attrs=children by self write # entry itself: self may write, all may read access to attrs=entry by self write by * read They still do require other ACLs, as "selfs" in both cases are different, right ? E.g. if self matches parent, it won't match children being created and vice-versa (and as per the manual page - 'add' is required both for parent's 'children' as well as new entry's 'entry'). ITOW if we bind as the entity wanting to create new entry underneath, the above is not enough - and we need something more elaborate like in e.g. address book example. 4) access rights required for deeper searches suppose we have structure like: ou=A, dc=example, dc=com ou=B, ou=A, dc=example, dc=com uid=msl, ou=B, ou=A, dc=example, dc=com If we do search for uid using 'ou=A, dc=example, dc=com' as a search base (with subtree scope), what (if any) access rights do we need on 'ou=B, ou=A, dc=example, dc=com' ? 5) sets Is this feature assumed safe to use ? As - it's still formally undocumented (man pages), but there are examples on the website and syntax explanation in the faq.

1 1

Q about add accesslog entry
by Ulrich Windl 23 Jul '20

23 Jul '20

Hi! I found this accesslog entry, caused by a server-sync it seems (some strings replaced consistently for privacy): --- dn: reqStart=20200722085045.000019Z,cn=audit objectClass: auditModify structuralObjectClass: auditModify reqStart: 20200722085045.000019Z reqEnd: 20200722085045.000060Z reqType: modify reqSession: 6 reqAuthzID: cn=Admin,dc=example,dc=org reqDN: uid=username,ou=people,dc=example,dc=org reqResult: 0 reqMod: entryCSN:= 20200722082119.640611Z#000000#003#000000 reqMod: modifiersName:= cn=Admin,dc=example,dc=org reqMod: modifyTimestamp:= 20200722082119Z reqOld: entryCSN: 20200722082119.640611Z#000000#003#000000 reqOld: modifiersName: cn=Admin,dc=example,dc=org reqOld: modifyTimestamp: 20200722082119Z reqEntryUUID: 2d063f78-7ced-1032-948d-cf46530da60d entryUUID: 2cefa3e8-6044-103a-8b01-193e5edbb211 creatorsName: cn=audit createTimestamp: 20200722082119Z entryCSN: 20200722082119.640611Z#000000#003#000000 modifiersName: cn=audit modifyTimestamp: 20200722082119Z --- So if I see it correctly, only the entryUUID changed? Actually I wouldn't expect the entryUUID to change. Obviously the entry could not have been recreated after being deleted, because otherwise some other field would have changed, right? Or could this be a late consequence of improper slapadd (entryUUIDs not taken from slapcat) long time ago? Regards, Ulrich

2 2

Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl 22 Jul '20

22 Jul '20

Hi! After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted: slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted. The next line logged was: slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389) (the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice) The server is one of three MM servers that all have the same configuration and the same version. The schema knows in olcAttributeTypes (olcSchemaConfig): ( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd? Regards, Ulrich

4 10

Q: Stable output of slapcat?
by Ulrich Windl 22 Jul '20

22 Jul '20

Hi! I wonder: Is the output of slapcat expected to be stable (assuming the database did not change)? I know that LDAP attributes are considered to be sets that have no implicit ordering, but diff-wise it would be rather nice to have a stable output ordering. Here is an example of non-stable output ordering (sdiff output, only first 18 columns for confidentiality): # sdiff b0 b1 dn: olcDatabase={1 dn: olcDatabase={1 objectClass: olcDa objectClass: olcDa objectClass: olcHd objectClass: olcHd olcDatabase: {1}hd olcDatabase: {1}hd olcDbDirectory: /v olcDbDirectory: /v olcSuffix: dc=sap, olcSuffix: dc=sap, olcAccess: {0}to * < olcAccess: {1}to d < olcAccess: {2}to a < olcAccess: {3}to a < olcAccess: {4}to a < olcAccess: {5}to * < olcLimits: {0}dn.e olcLimits: {0}dn.e olcRootDN: cn=Admi olcRootDN: cn=Admi olcRootPW: {SSHA}y olcRootPW: {SSHA}y olcSecurity: ssf=1 olcSecurity: ssf=1 olcSyncrepl: {0}ri olcSyncrepl: {0}ri olcSyncrepl: {1}ri olcSyncrepl: {1}ri olcSyncrepl: {2}ri olcSyncrepl: {2}ri olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcMirrorMode: TRU olcMirrorMode: TRU olcDbCacheSize: 10 olcDbCacheSize: 10 olcDbCheckpoint: 1 olcDbCheckpoint: 1 olcDbConfig: {0}se olcDbConfig: {0}se olcDbConfig: {1}se olcDbConfig: {1}se olcDbConfig: {2}se olcDbConfig: {2}se olcDbConfig: {3}se olcDbConfig: {3}se olcDbConfig: {4}se olcDbConfig: {4}se olcDbConfig: {5}se olcDbConfig: {5}se olcDbIDLcacheSize: olcDbIDLcacheSize: olcDbIndex: object olcDbIndex: object olcDbIndex: uidNum olcDbIndex: uidNum olcDbIndex: gidNum olcDbIndex: gidNum olcDbIndex: member olcDbIndex: member olcDbIndex: member olcDbIndex: member olcDbIndex: cn eq, olcDbIndex: cn eq, olcDbIndex: uid eq olcDbIndex: uid eq olcDbIndex: sn eq, olcDbIndex: sn eq, olcDbIndex: givenN olcDbIndex: givenN olcDbIndex: entryU olcDbIndex: entryU olcDbIndex: entryC olcDbIndex: entryC olcDbIndex: ipServ olcDbIndex: ipServ olcDbIndex: ipServ olcDbIndex: ipServ olcDbIndex: roleOc olcDbIndex: roleOc olcDbIndex: mail e olcDbIndex: mail e olcDbIndex: displa olcDbIndex: displa olcDbIndex: modify olcDbIndex: modify structuralObjectCl structuralObjectCl entryUUID: db3ffe4 entryUUID: db3ffe4 creatorsName: cn=c creatorsName: cn=c createTimestamp: 2 createTimestamp: 2 entryCSN: 20170706 | olcAccess: {0}to * > olcAccess: {1}to d > olcAccess: {2}to a > olcAccess: {3}to a > olcAccess: {4}to a > olcAccess: {5}to * > entryCSN: 20200114 modifiersName: cn= modifiersName: cn= modifyTimestamp: 2 modifyTimestamp: 2 So is the order of output given by some hash functions in slapcat, or is it the order in which the database returns the attributes? What would I have to do to sort the attribute types in the same order as they are listed in the schema (one possible stable output)? Regards, Ulrich

3 5

anonymize data
by Olivier - 21 Jul '20

21 Jul '20

Hi all, I have a question anonymizing data. My openldap have some confidential data inside and I would like this : if a person has a flag confidentiality set to 1 (or is in a special ou), openldap will replace or answer a different data. For example : if we request "sn" on this record , it will reply "Smith" dn: cn=Smith,ou=public,c=com confidentiality: 0 sn: Smith if we request "sn" on this record , it will reply "XXX" dn: cn=Bond,ou=public,c=com confidentiality: 1 sn: Bond I'm not sur Openldap can offer this kind of functionnality. Thanks for your help !

5 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2020