June 2022 - openldap-technical

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

dynlist vs memberof performance issues
by Mark Cairney 11 Jan '23

11 Jan '23

Hi, I've been out the LDAP loop for a bit but the recent discussion of the memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box, removed the memberof elements from the database and replaced the memberof overlay with dynlist the queries appear to work as expected but are both a) slow and b) heavily CPU-intensive on the LDAP server. 2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738 (IP=129.215.17.9:636) 2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms 2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014 etime=0.000214 nentries=1 text= 2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 BIND dn="" method=163 2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030 etime=0.009084 text=SASL(0): successful result: 2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 BIND dn="" method=163 2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031 etime=0.000181 text=SASL(0): successful result: 2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="" method=163 2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK" authzid="mcairney(a)EASE.ED.AC.UK" 2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk" mech=GSSAPI bind_ssf=256 ssf=256 2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024 etime=0.000409 text= 2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=mcairney)" 2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH attr=* + 2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=5 UNBIND 2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031 etime=13.233679 nentries=1 text= 2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 closed I'm guessing that as the values are computed that this will be heavier on the CPU but it seems a bit excessive? Has anyone else noticed any similar performance issues? This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I guess this could be a factor but there's no io waiting on the server and no swapping? The database is on a par in size with our Production service ( about 400K user objects with 1 group object per user and then about 80K actual groups of users) The config for the primary DB (ACLs and rootPW redacted) is: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/openldap/var/openldap-data/authorise olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 2 olcReadOnly: FALSE olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSizeLimit: unlimited olcSyncUseSubentry: FALSE olcTimeLimit: unlimited olcMonitoring: TRUE olcDbEnvFlags: writemap olcDbEnvFlags: nometasync olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: eduniType eq olcDbIndex: gecos pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: mail pres,eq,sub olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniOrgCode eq olcDbIndex: memberOf pres,eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: eduniServiceCode pres,eq olcDbIndex: krbName pres,eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: eduniIdmsId pres,eq olcDbIndex: member pres,eq olcDbIndex: memberUid pres,eq olcDbIndex: eduniRefNo pres,eq olcDbIndex: eduniTitle pres,eq olcDbIndex: title pres,eq,sub olcDbIndex: eduniCardNumber pres,eq olcDbIndex: eduniYearOfStudy eq olcDbIndex: description pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: aliasedObjectName eq olcDbIndex: yubiKeyId pres,eq olcDbIndex: isMemberOf pres,eq olcDbIndex: hasMember pres,eq olcDbIndex: proxyAddresses pres,eq,sub olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 structuralObjectClass: olcMdbConfig dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 02+00:00 00+04:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynListConfig olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames structuralObjectClass: olcDynListConfig -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

12 27

Empty error when configuring OpenLDAP
by Cezary Drożak 23 Aug '22

23 Aug '22

Hello, I am trying to set up OpenLDAP on Arch Linux on my server, following instruction on Arch Wiki[1]. I prepared the config.ldif file, replacing every $BASEDN and $PASSWD in the example configuration: # The root config entry dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /run/openldap/slapd.args olcPidFile: /run/openldap/slapd.pid # Schemas dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema # TODO: Include further schemas as necessary include: file:///etc/openldap/schema/core.ldif # The config database dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootDN: cn=Manager,dc=example,dc=com # The database for our entries dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcSuffix: dc=example,dc=com olcRootDN: cn=Manager,dc=example,dc=com olcRootPW: {SSHA}xZqSQN4wG4+C5I57dB/Qm02vJ+kQcwd7 olcDbDirectory: /var/lib/openldap/openldap-data # TODO: Create further indexes olcDbIndex: objectClass eq Then I executed the following command: sudo -u ldap slapadd -n 0 -F /etc/openldap/slapd.d/ -l ./config.ldif This gave me the following error: invalid config directory /etc/openldap/slapd.d/, error 2 slapadd: bad configuration directory! I checked that the directory did not exist, so I created it and changed owner to `ldap`. The wiki page did not mention that the directory should be created earlier, so maybe it should have been created by a post installation script. If that's the case, I will report it to package maintainers. After I created the directory, I ran the command again, this time having a different error message: slapadd: could not add entry dn="cn=config" (line=1): Closing DB... I have no idea what is wrong now and I cannot find anything useful on the internet. Does anyone have an idea what I may be doing wrong here? [1]: https://wiki.archlinux.org/title/OpenLDAP

3 4

How to relay read and write requests to different ldap servers
by nagamani.chinnapaiyan＠viasat.com 13 Jul '22

13 Jul '22

Hi, I am new to ldap. We have 4 ldap servers, 2 of them are in mirror-mode providers, 2 of them are just consumers/replicas. I am working on loadbalancer for these 4 ldap servers using ldap/meta backend. I want to the ldap proxy/loadbalancer to, redirect write requests to one of the 2 mirror-mode providers. redirect read requests to any of the 2 replicas/consumers. I know ldap backend has uri list which can be used to redirect to mirror-mode providers. But I want to redirect only the write requests. Regards, Nagamani Chinnapaiyan

5 8

Re: dynlist overlay, memberURL not working on spcified attribiutes
by Bog Dan 07 Jul '22

07 Jul '22

Thanks for your reply, I try to explain. Populating memberOf attribiute to users entry working well using this: *olcDynListAttrSet: {1}inetOrgPerson labeledURI memberOf* User entry look as follow: *dn: uid=test1,ou=people,dc=test,dc=comsambaAcctFlags: [U ]sambaPwdLastSet: 9999999999sambaNTPassword: passo: testsambaSID: S-1-5-21-3945181060-1826002392-430723570pwdPolicySubentry: cn=noexpire,ou=ppolicy,dc=test,dc=comcreateTimestamp: 20220529070624.324Zdescription: User accountuserPassword:: passsambaPwdCanChange: 1528009736sambaPwdMustChange: 0mail: test1(a)test.com <test1(a)test.com>loginShell: /bin/bashgivenName: Test1sambaLogonTime: 0sn: Testcn: Test1 TestobjectClass: posixAccountobjectClass: topobjectClass: inetOrgPersonobjectClass: personobjectClass: organizationalPersonobjectClass: sambaSamAccountobjectClass: shadowAccounthomeDirectory: /home/test1pwdChangedTime: 20220529070856.504ZgidNumber: 1002uidNumber: 1002uid: test1structuralObjectClass: inetOrgPersonentryUUID: 348cd83e-7c6a-103c-8612-1918ce7a0bc4creatorsName: cn=admin,dc=test,dc=comlabeledURI: ldap:///ou=groups,dc=test,dc=com??sub?(|(&(objectclass=groupOfUniqueNames)(uniqueMember=uid=test1,ou=people,dc=test,dc=com))(&(objectClass=posixGroup)(memberUid=test1)))entryCSN: 20220609180738.487916Z#000000#001#000000modifiersName: cn=admin,dc=test,dc=commodifyTimestamp: 20220609180738ZmemberOf: cn=devops,ou=groups,dc=test,dc=comentryDN: uid=test1,ou=people,dc=test,dc=comsubschemaSubentry: cn=SubschemahasSubordinates: FALSE* Static group entry: *cn=devops,ou=groups,dc=test,dc=comcn: devopsobjectClass: groupOfUniqueNamesobjectClass: topdescription: devops groupuniqueMember: uid=test1,ou=people,dc=test,dc=comuniqueMember: uid=test2,ou=people,dc=test,dc=com* Next what I want to do is agregate multiple groups to one virtual using this: *olcDynListAttrSet: {0}groupOfURLs memberURL member* Then I create appropiate group: *cn=testluri,ou=groups,dc=test,dc=comcn: testluriobjectClass: topobjectClass: groupOfURLsdescription: test groupmemberURL: ldap:///ou=people,dc=test,dc=com??sub?(memberOf=cn=devops,ou=groups,dc=test,dc=com)* but this don't add memeber entry to this group. When I changing memberURL as follow: *memberURL: ldap:///ou=people,dc=test,dc=com??sub?(|(uid=test1)(uid=test2))* member attribute was added to testluri group: *cn=testluri,ou=groups,dc=test,dc=comcn: testluriobjectClass: topobjectClass: groupOfURLsdescription: test groupmemberURL: ldap:///ou=people,dc=test,dc=com??sub?(memberOf=cn=devops,ou=groups,dc=test,dc=com)* *member: uid=test1,ou=people,dc=test,dc=com* *member: uid=test2,ou=people,dc=test,dc=com* but this is not the goal. As I mentioned I want to agregate multiple group to one using memberOf attribute in memberURL: *memberURL: ldap:///ou=people,dc=test,dc=com??sub?(memberOf=cn=devops,ou=groups,dc=test,dc=com)* but this not working. What I'm doing wrong? Reagrds BS śr., 29 cze 2022 o 19:17 Quanah Gibson-Mount <quanah(a)fast-mail.org> napisał(a): > > > --On Tuesday, June 28, 2022 12:18 PM +0200 Bog Dan <bsiara.cgi(a)gmail.com> > wrote: > > > > > Hi All, > > I have problem with dynlist overlay, this is my configuration: > > > > > > > > olcOverlay={1}dynlist,olcDatabase={1}mdb,cn=config > > objectClass: olcOverlayConfig > > objectClass: olcDynListConfig > > olcOverlay: {1}dynlist > > olcDynListAttrSet: {0}groupOfURLs memberURL member > > olcDynListAttrSet: {1}inetOrgPerson labeledURI memberOf > > > > > > > > First I create static group: > > > > > > cn=devops,ou=groups,dc=test,dc=com > > cn: devops > > objectClass: groupOfUniqueNames > > objectClass: top > > description: devops group > > uniqueMember: uid=test1,ou=people,dc=test,dc=com > > uniqueMember: uid=test2,ou=people,dc=test,dc=com > > > > > > > > When I create new dynamic group: > > > > cn=testluri,ou=groups,dc=test,dc=com > > cn: testluri > > objectClass: top > > objectClass: groupOfURLs > > description: test group > > memberURL: > > ldap:///ou=people,dc=test,dc=com??sub?(memberOf=cn=devops,ou=groups,dc=te > > st,dc=com) > > > > > > > > I don't get any member of group. Users test1 and test2 already have > > memberOf attribute: > > > > memberOf: cn=devops,ou=groups,dc=test,dc=com > > > > > > > > When I change memberURL to use not dynamic attributes (memberOf): > > > > > > memberURL: > ldap:///ou=people,dc=test,dc=com??sub?(|(uid=test1)(uid=test2)) > > > > > > > > users added to testluri group and dynlist works well. > > What I should do to configure dynlist with memberOf? > > I've read your email multiple times, and quite frankly I don't understand > what your end goal is. > > If your end goal is to have static groups, where memberOf is dynamically > populated on the user entries (which is the usual use case for replacing > the 2.4 memberOf), then your configs are clearly incorrect. > > Can you better explain what your end goal is? > > Thanks, > Quanah > > > >

2 1

dynlist overlay, memberURL not working on spcified attribiutes
by Bog Dan 29 Jun '22

29 Jun '22

Hi All, I have problem with dynlist overlay, this is my configuration: olcOverlay={1}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynListConfig olcOverlay: {1}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member olcDynListAttrSet: {1}inetOrgPerson labeledURI memberOf First I create static group: cn=devops,ou=groups,dc=test,dc=com cn: devops objectClass: groupOfUniqueNames objectClass: top description: devops group uniqueMember: uid=test1,ou=people,dc=test,dc=com uniqueMember: uid=test2,ou=people,dc=test,dc=com When I create new dynamic group: cn=testluri,ou=groups,dc=test,dc=com cn: testluri objectClass: top objectClass: groupOfURLs description: test group memberURL: ldap:///ou=people,dc=test,dc=com??sub?(memberOf=cn=devops,ou=groups,dc=test,dc=com) I don't get any member of group. Users test1 and test2 already have memberOf attribute: memberOf: cn=devops,ou=groups,dc=test,dc=com When I change memberURL to use not dynamic attributes (memberOf): memberURL: ldap:///ou=people,dc=test,dc=com??sub?(|(uid=test1)(uid=test2)) users added to testluri group and dynlist works well. What I should do to configure dynlist with memberOf? Openldap 2.5.12 Regards BS

2 1

Filter string with escaped forward slash
by Jeffrey Walton 29 Jun '22

29 Jun '22

Hi Everyone, Microsoft AD requires a forward slash ('/') be escaped with "\\2f". Confer, [1, 2]. However, escaping the forward slash is not required per the RFCs (if I am parsing the RFCs correctly). I would like to know if OpenLDAP recognizes an escaped forward slash and handles it properly. I suspect OpenLDAP does since slapd is just a front-end to different directories. The reason I would like to know is for a generic encoder. If MS Active Directory, Novell eDirectory and OpenLDAP handle the escaped forward slash as expected, then it makes it easier to write the encoder. Thanks in advance, Jeff [1] https://social.technet.microsoft.com/wiki/contents/articles/5312.active-dir… [2] https://docs.microsoft.com/en-us/windows/win32/adsi/ldap-dialect

3 2

role manage can bypass pwdCheckQuality with MOD but not with ADD op
by tempo＠net-c.com 28 Jun '22

28 Jun '22

Hi, I'm doing some testing on userPassword management actually with openldap 2.5.9 I noticed that I could MOD a userPassword without checking quality if my admin role was "manage" However, if I try to ADD a user with its attribute userPassword set, then quality is checked although the role "manage" ppolicy in both cases are the default one (policy subentry not set) Is it normal behavior ? Regards,

3 5

setting slapd logging to STDOUT only
by Alceu Rodrigues de Freitas Junior 26 Jun '22

26 Jun '22

Greetings, My name is Alceu and I'm new to this list. I'm experimenting with OpenLDAP at a Google Cloud, running it as a Pod inside a GKE cluster. I've being struggling to setup slapd to send it's logs to STDOUT only, but it seems in most cases the logs are sent to STDERR. The problem is, for GCP Log Explorer, everything that is sent to STDERR is considered an error, even when it's not. :-) Here is a reference: https://stackoverflow.com/questions/71158475/gcp-log-explorer-shows-wrong-s…. I'm using this open source project <https://github.com/osixia/docker-openldap> to deploy OpenLDAP as a Docker container, but there is no configuration option for that. I would like to make it clear that this project is not using the latest OpenLDAP stable version. AFAIK, slapd will use syslog facility for logging and will write to the terminal if the "-d" option is in use, which in fact it is: $ docker exec -ti openldap /bin/bash root@56529dea5931:/# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.7 0.2 76528 47232 ? Ss 20:54 0:00 /usr/bin/python -u /container/tool/run --loglevel debug openldap 21 0.1 0.0 294932 14844 ? Sl 20:54 0:00 /usr/sbin/slapd -h ldap://56529dea5931 ldaps://56529dea5931 ldapi:/// -u openldap -g openldap -d 256 root 25 1.0 0.0 19868 3600 pts/0 Ss 20:54 0:00 /bin/bash root 32 0.0 0.0 38312 3364 pts/0 R+ 20:54 0:00 ps aux Is there any way to configure slapd to use STDOUT for everything, besides using shell redirection (2>&1)? Thanks in advance, Alceu

1 0

Setting to suppress "connection_read(XXX): no connection!"
by Uwe Sauter 24 Jun '22

24 Jun '22

Dear list, is there a way to configure slapd to not emit messages regarding "connection_read(XXX): no connection!"? Currently the configuration contails "loglevel none" but these messages are sent to syslog local4.debug regardless. In case the version is relevant, this is 2.4.59 on RHEL 8.4. slapd is started with URL list "ldap:/// ldaps:/// ldapi:///" Thanks, Uwe

1 0

rwm bindDN context and ppolicy issues
by Kartik Subbarao 23 Jun '22

23 Jun '22

I'm able to specify rwm bindDN rules without password-policy enabled just fine, like this one: rwm-rewriteContext bindDN rwm-rewriteRule "^([^=]+)=([^@]+)@olddomain.com(.+),dc=olddomain,dc=com$" "$1=$2(a)newdomain.com$3,dc=newdomain,dc=com" ":@" However, when I enable password policy (which also works fine on its own), slapd segfaults. From doing a backtrace and stepping through the code, it looks like the crux of the issue is that the mdb_info struct ends up with garbage data: struct mdb_info *mdb = (struct mdb_info *) op->o_bd->be_private; mi_dbenv_home and mi_monitor have random stuff in them. I'm mulling over how much additional time to spend on this. rwm is a very elegant solution to a current issue that could save me a bunch of time to set up additional LDAP servers with the renamed data. If this is an isolated bug for which a quick fix might be possible, I might investigate further. But if it's a thorny issue or just the tip of the iceberg of things where rwm might break unexpectedly, then it may be better for me to consider other options. OpenLDAP developers, what do your instincts say on this? Regards, -Kartik

2 3

Re: LDAP over TLS not doing hostname verification in version 2.4.59
by radiatejava 23 Jun '22

23 Jun '22

Anyone of these issues could be responsible? Just checking OpenLDAP 2.4.46 Release (2018/03/22) Fixed libldap connection delete callbacks when TLS fails to start (ITS#8717) Fixed libldap to not reuse tls_session if TLS hostname check fails (ITS#7373) Thanks On Wed, Jun 22, 2022 at 7:51 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > --On Tuesday, June 21, 2022 11:29 PM -0700 radiatejava > <radiatejava(a)gmail.com> wrote: > > > I raised the issue https://bugs.openldap.org/show_bug.cgi?id=9869 but > > it has been set to verified/invalid state now. However, I do not know > > which version addresses the issue. Can anyone tell me which version > > would still verify the hostname when doing LDAP over TLS. > > The OpenLDAP 2.4 series is historic, no bug reports for it will be > considered. > > No changes have been made to OpenLDAP 2.4 series to disable hostname > verification by the OpenLDAP project. If you are using libraries provided > by downstream distributions, they may have made unauthorized changes to how > libldap functions in regards to TLS. Additionally, if you were using an > OpenSSL linked libldap and are now using a GnuTLS linked libldap, then some > behaviors are different as documented in the man pages. > > Generally I'd advise starting with a supported version of OpenLDAP. > > Regards, > Quanah > > > >

2 1

LDAP over TLS not doing hostname verification in version 2.4.59
by radiatejava 22 Jun '22

22 Jun '22

My software was using openldap client 2.4.44 to talk to the LDAP server. We have shifted to 2.4.59 now to address some issues. Ever since we shifted, the new version is allowing LDAP over TLS without hostname verification. In the older ver 2.4.44, I always got this error if hostname did not match the CN value: return code -1 - Can't contact LDAP server) diagnostic message TLS: hostname does not match CN in peer certificate But after the lib update, no such error even if I am using LDAP server IP to do LDAP bind while LDAP server certificate has CN set as some FQDN (say test.ldap.com). Our client side code has not changed while we updated the ldap lib. For our client, we are only doing these settings: ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTDIR, lCertsDir) ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, lCert) Has there been any change in this regard? How do I enforce hostname verification now? I raised the issue https://bugs.openldap.org/show_bug.cgi?id=9869 but it has been set to verified/invalid state now. However, I do not know which version addresses the issue. Can anyone tell me which version would still verify the hostname when doing LDAP over TLS. Thanks.

2 1

OpenLDAP in Ubuntu Jammy (LTS)
by Sergio Durigan Junior 22 Jun '22

22 Jun '22

Hi there, I would like to inform the OpenLDAP community that, after a few months sorting out the details, the OpenLDAP package of the Ubuntu Jammy (LTS) release will now receive updates every time there's a new patch version released for the 2.5.x upstream series. In fact, if you are using Ubuntu Jammy you can start benefiting from this new policy right away: OpenLDAP 2.5.12 has just been accepted into the jammy-updates repository and should be available soon. I'd like to thank the community for changing your release process recently and electing 2.5.x as your LTS release; this really helped me making the case to obtain a Micro Release Exception from the Ubuntu SRU team :-). If I may, I would also like to make a small request here. It would be very helpful if the OpenLDAP website could also offer the "Release Documents" section (from https://openldap.org/software/) for OpenLDAP 2.5.x as well. Actually, it would also be great if the "Announcement" page could stay available "forever", and be made per-release (instead of having just one "announce.html" page that gets overwritten every time there's a new release). I don't know much about web stuff in general, but I can help with this if needed. Thank you very much, and I hope this email brings news to the Ubuntu OpenLDAP users out there. Cheers, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

2 2

Upgrade config from 2.4.49 to 2.5.11 is failing.
by farooq.fortinet＠gmail.com 21 Jun '22

21 Jun '22

Current Openldap 2.4.49 is working fine with syncprov configuration. Planing to upgrade to recent versions. Took backup of system using slapcat. Upgraded the dev server to 2.5.11. Now when trying to import config using slapadd. It is failing with following error. overlay_config(): overlay "syncprov" already in list slapadd: could not add entry dn="olcOverlay={1}syncprov,olcDatabase={0}config,cn=config" (line=1900): slapadd shutdown: initiated slapadd destroy: freeing system resources. syncinfo_free: rid=100 Any help or tip? Thanks Farooq

2 1

LMDB: Estimate number of elements between two keys
by Ken Wenzel 17 Jun '22

17 Jun '22

Dear OpenLDAP-Community, is it possible to compute a rough estimate of the number of elements between two given keys for an LMDB database? Currently, I scan the first 1000 keys and extrapolate the count based on the average distance of the keys. Maybe it is also possible to use some information about the common b-tree pages that are shared by both keys? We need this functionality for query optimization within RDF4J. Thank you for your support and best regards, Ken Wenzel

2 2

need help to make OpenLDAP work as "this other directory, plus"
by jarett＠bioteam.net 17 Jun '22

17 Jun '22

Hi all. So, I'm trying to basically put a band-aid over an intentionally broken LDAP implementation. We use Okta as our single source of truth for directory services, and its implementation of LDAP intentionally leaves out uidNumber and gidNumber (and you can't change this) in order to force you to use their insanely expensive "Advanced Server Access" product. This $9500/yr expense for a minimum of 50 machines is a non-starter for the lab project we are trying to get working with LDAP. We're only talking about ~10 machines here and we very much want them to be ultimately authenticating against Okta for their passwords -- because this automatically MFAs them by default, and prevents credential proliferation for the services we run in the lab. So basically what I want to do is set up an LDAP server which passes just about everything through to Okta, but keeps consistent uidNumber and gidNumber values for each user in Okta who logs in. I think this is possible either with the "meta" backend or the "ldap" backend or both, but I'm not clear on how to configure these. I've followed this guide to get OpenLDAP working on a Rocky 8 server: https://kifarunix.com/install-and-setup-openldap-on-rocky-linux-8/ But that guide does not contain instructions for something like this, and even the OpenLDAP documentation is scarce when it comes to configuring backends. e.g.: https://www.openldap.org/doc/admin26/backends.html#LDAP even just for LDAP there is no indication of how I would introduce the bind DN for the backend LDAP or how it would know what to add, and the "meta" backend has no implementation details at all: https://www.openldap.org/doc/admin26/backends.html#Metadirectory Help? Thanks!

3 2

logsuccess FALSE vs. replica contextCSN
by Geert Hendrickx 17 Jun '22

17 Jun '22

Hi Some time ago we switched our MMR config to "logsuccess FALSE" to let us record and investigate some (client-side) issues with unique constraint. This records updates refused by unique constraint in the accesslog, so we can look into them. We have logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" in each syncrepl statement, so those failed updates don't propagate through the replication. We noticed though that other failed updates, not due to unique constraint, such as adding an already existing object, or deleting a non-existing one, do cause a contextCSN update *on all replica's* but *not* in the provider, leading to contextCSN divergence - at least when no further updates happen on that provider. This usually remains hidden as other updates to the same provider keep increasing its contextCSN, but becomes apparant when no further updates happen on that provider (in this case because we were switching providers). Eg. when adding an object that already exists, the provider refused the update (error 68, already exists) and logs the following to the accesslog: > dn: reqStart=20220616095229.000003Z,cn=accesslog > objectClass: auditAdd > reqStart: 20220616095229.000003Z > reqEnd: 20220616095229.000004Z > reqType: add > reqSession: 1498 > reqAuthzID: <...> > reqDN: <some already existing object> > reqResult: 68 > reqMod: <...> > reqMod: entryCSN:+ 20220616095229.618035Z#000000#001#000000 and its main db is not updated. But the replica's log the following: > dn: reqStart=20220616095229.000006Z,cn=accesslog > objectClass: auditModify > reqStart: 20220616095229.000006Z > reqEnd: 20220616095229.000007Z > reqType: modify > reqSession: 1 > reqAuthzID: <...> > reqDN: <root DN> > reqResult: 0 > reqMod: contextCSN:= 20220616095229.618035Z#000000#001#000000 And thus update the contextCSN of their root DN (despite no other changes to the main db) - their contextCSN is now different than the provider's. This obviously only happens with "logsuccess FALSE", but even in that case this should not be expected behaviour; refused updates should not change anything except getting logged to the accesslog? This is with OpenLDAP 2.5.12 (migrating from 2.4.x) Geert

2 8

[OPENLDAP 2.4] problem with cacert.pem certificates and its operation with openldap
by fredd fredddo 16 Jun '22

16 Jun '22

Hello, I have a problem understanding how cacert.pem works on openldap 2.4 under centos. I have an extremely heterogeneous machine park (with openldap customers and other owners) So I have 2 Certificates (CA and intermediate CA) self-signed with the MD5withRSA algorithm and the same 2 certificates self-signed with the SHA1withRSA algorithm. The 4 certificates are therefore in the cacert.pem of the server and the clients. (keystore) It works perfectly for old servers but for new ones I have to force the use of TLS 1.1 because of the algorithms. I have two problems: If I just paste the 2 certificates in MD5 in the client keystore, it works, but if I leave the 2 certificates in SHA1, it does not work (bad certificate). I don't understand how openldap reads the file when there are multiple choices . He starts with the first couple, if that doesn't work he goes to the next one? So the idea would be to generate 2 new certificates identical to the others but with a SHA254 signature for example to work in TLS 1.2/1.3 and keep ldap compatibility with old servers. The cacert.pem file of the OpenLDAP server would therefore have 6 certificates and the clients following their OS would have the appropriate pair of certificates. Could this work? or for clients I leave the cacert the same and it will choose what it needs to establish the TLS connection? I am a little lost ... best regards Fred,

2 1

OpenLDAP pcacheBind is not refresh
by Tri Tu 15 Jun '22

15 Jun '22

hello everyone, I'm having issue with the pcachBind that it's not getting update from the upstream proxy ldap. The use case is that after users have updated userPassword on the upstream LDAP, the new password is updated and it's authenticated correctly with the updated password when directly query the upstream LDAP. But with the proxyldap pcache setting that I have with 3 attributes set of pcache configuration as below: overlay pcache pcache hdb 100000 3 1000 60 pcacheAttrset 0 + pcacheTemplate (uid=) 0 120 0 0 30 pcacheTemplate (&(uid=)(objectClass=)) 0 60 0 0 30 pcacheTemplate (&(objectClass=)(uidNumber=)) 0 60 0 0 30 pcacheTemplate (&(uid=)(memberOf=)) 0 60 0 0 30 pcacheBind (uid=) 0 30 sub "o=mycompany.com" pcacheAttrset 1 memberOf pcacheTemplate (objectClass=*) 1 360 0 0 30 pcacheTemplate (uid=) 1 360 0 0 30 pcacheBind (uid=) 1 30 sub "o=mycompany.com" pcacheAttrset 2 memberOf member pcacheTemplate (uid=) 2 360 0 0 30 pcacheBind (uid=) 2 30 sub "o=mycompany.com" pcacheOffline TRUE pcacheValidate TRUE The cacheable template for uid= is set with TTL 120 and TTR at 30. The first time query to the proxy pcache server, it's cached uid= data Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: slap_listener_activate(8): Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 busy Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: >>> slap_listener(ldap:///) Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: listen=8, new connection on 13 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: added 13r (active) listener=(nil) Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: conn=1000 fd=13 ACCEPT from IP=10.239.134.126:60966 (IP=0.0.0.0:389) Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: activity on 2 descriptors Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: 13r Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: read active on 13 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: connection_get(13) Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: connection_get(13): got connid=1000 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: connection_read(13): checking for input on id=1000 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: op tag 0x60, time 1655184692 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: conn=1000 op=0 do_bind Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: >>> dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com> Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: <<< dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com>, <uid=userX,ou=employees,o=mycompany.com> Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: conn=1000 op=0 BIND dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: do_bind: version=3 dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: => bdb_entry_get: ndn: "uid=userX,ou=employees,o=mycompany.com" Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: => bdb_entry_get: oc: "(null)", at: "(null)" Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: => hdb_dn2id("o=mycompany.com") Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: <= hdb_dn2id: got id=0x1 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: => hdb_dn2id("ou=employees,o=mycompany.com") Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: <= hdb_dn2id: got id=0x2 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: => hdb_dn2id("uid=userX,ou=employees,o=mycompany.com") Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: <= hdb_dn2id: got id=0x3 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: entry_decode: "" Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: <= entry_decode() Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: => bdb_entry_get: found entry: "uid=userX,ou=employees,o=mycompany.com" Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: bdb_entry_get: rc=0 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: str2filter "(uid=userX)" Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: begin get_filter Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: EQUALITY Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: end get_filter 0 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: Lock QC index = 0x5638d82e9910 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: Not answerable: Unlock QC index=0x5638d82e9910 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: QUERY NOT ANSWERABLE Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: QUERY CACHEABLE Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: =>ldap_back_getconn: conn=1000 op=0: lc=0x7f8710109d80 inserted refcnt=1 rc=0 Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:31:32 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: => ldap_back_munge_filter "(uid=userX)" Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: <= ldap_back_munge_filter "(uid=userX)" (0) Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: >>> dnPrettyNormal: <uid=userX,OU=employees,O=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: <<< dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com>, <uid=userX,ou=employees,o=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: >>> dnPretty: <CN=cie_ldap_test,OU=Groups,O=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: <<< dnPretty: <cn=cie_ldap_test,ou=Groups,o=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: >>> dnPretty: <CN=hps_opsinf_admin,OU=Groups,O=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: <<< dnPretty: <cn=hps_opsinf_admin,ou=Groups,o=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: >>> dnNormalize: <cn=cie_ldap_test,ou=Groups,o=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: <<< dnNormalize: <cn=cie_ldap_test,ou=Groups,o=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: >>> dnNormalize: <cn=hps_opsinf_admin,ou=Groups,o=mycompany.com> Jun 14 05:31:33 prd-ldap1-euc1 slapd[7178]: <<< dnNormalize: <cn=hps_opsinf_admin,ou=Groups,o=mycompany.com> But any sub-sequence queries after that it's always using the entry that found in the cached (CACHED BIND) instead of re-query with new connection to the upstream LDAP as it's expired (longer that TTL/TTR). Same situation when users change password from the upstream LDAP, the proxy ldap doesn't take the update password. Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: slap_listener_activate(8): Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 busy Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: >>> slap_listener(ldap:///) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: listen=8, new connection on 13 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: added 13r (active) listener=(nil) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: conn=1001 fd=13 ACCEPT from IP=10.239.134.126:60993 (IP=0.0.0.0:389) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: 13r Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: read active on 13 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: connection_get(13) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: connection_get(13): got connid=1001 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: connection_read(13): checking for input on id=1001 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: op tag 0x60, time 1655184873 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: conn=1001 op=0 do_bind Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: >>> dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com> Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <<< dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com>, <uid=userX,ou=employees,o=mycompany.com> Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: conn=1001 op=0 BIND dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: do_bind: version=3 dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => bdb_entry_get: ndn: "uid=userX,ou=employees,o=mycompany.com" Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => bdb_entry_get: oc: "(null)", at: "(null)" Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => bdb_entry_get: found entry: "uid=userX,ou=employees,o=mycompany.com" Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: bdb_entry_get: rc=0 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: str2filter "(uid=userX)" Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: begin get_filter Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: EQUALITY Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: end get_filter 0 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: Lock QC index = 0x5638d82e9910 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: QUERY ANSWERABLE (answered 1 times) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => hdb_search Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => access_allowed: search access to "uid=userX,ou=employees,o=mycompany.com" "entry" requested Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <= root access granted Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => access_allowed: search access granted by manage(=mwrscxd) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: base_candidates: base: "uid=userX,ou=employees,o=mycompany.com" (0x00000003) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => test_filter Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: EQUALITY Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => access_allowed: search access to "uid=userX,ou=employees,o=mycompany.com" "uid" requested Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <= root access granted Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => access_allowed: search access granted by manage(=mwrscxd) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <= test_filter 6 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: send_ldap_result: conn=1001 op=0 p=3 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: send_ldap_result: err=0 matched="" text="" Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: pcache_op_bind: CACHED BIND for uid=userX,ou=employees,o=mycompany.com Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: ==> hdb_bind: dn: uid=userX,ou=employees,o=mycompany.com Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => access_allowed: result not in cache (userPassword) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => access_allowed: auth access to "uid=userX,ou=employees,o=mycompany.com" "userPassword" requested Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => dn: [1] Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => dn: [2] cn=subschema Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => acl_get: [3] attr userPassword Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => acl_mask: access to entry "uid=userX,ou=employees,o=mycompany.com", attr "userPassword" requested Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => acl_mask: to value by "", (=0) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <= check a_dn_pat: self Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <= check a_dn_pat: anonymous Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <= acl_mask: [2] applying auth(=xd) (stop) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: <= acl_mask: [2] mask: auth(=xd) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => slap_access_allowed: auth access granted by auth(=xd) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: => access_allowed: auth access granted by auth(=xd) Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: conn=1001 op=0 BIND dn="uid=userX,ou=employees,o=mycompany.com" mech=SIMPLE ssf=0 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: do_bind: v3 bind: "uid=userX,ou=employees,o=mycompany.com" to "uid=userX,ou=employees,o=mycompany.com" Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: send_ldap_result: conn=1001 op=0 p=3 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: send_ldap_result: err=0 matched="" text="" Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: send_ldap_response: msgid=1 tag=97 err=0 Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: conn=1001 op=0 RESULT tag=97 err=0 text= Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:33 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: 13r Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: read active on 13 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_get(13) Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_get(13): got connid=1001 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_read(13): checking for input on id=1001 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: op tag 0x77, time 1655184874 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: conn=1001 op=1 do_extended Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: conn=1001 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: do_extended: oid=1.3.6.1.4.1.4203.1.11.3 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: conn=1001 op=1 WHOAMI Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: send_ldap_extended: err=0 oid= len=43 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: send_ldap_response: msgid=2 tag=120 err=0 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: conn=1001 op=1 RESULT oid= err=0 text= Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: 13r Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: read active on 13 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_get(13) Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_get(13): got connid=1001 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_read(13): checking for input on id=1001 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: op tag 0x42, time 1655184874 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: ber_get_next on fd 13 failed errno=0 (Success) Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_read(13): input error=-2 id=1001, closing. Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_closing: readying conn=1001 sd=13 for close Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_close: deferring conn=1001 sd=13 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: conn=1001 op=2 do_unbind Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: conn=1001 op=2 UNBIND Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_resched: attempting closing conn=1001 sd=13 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: connection_close: conn=1001 sd=13 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: =>ldap_back_conn_destroy: fetching conn 1001 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: removing 13 Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: conn=1001 fd=13 closed Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on 1 descriptor Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: activity on: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jun 14 05:34:34 prd-ldap1-euc1 slapd[7178]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Wondering that if there is anything missing with configuration or if this is a bug that I can file for bug ticket. Thanks, -Tommy

3 5

Search for all user set as manager in my organizational units
by tempo＠net-c.com 15 Jun '22

15 Jun '22

Hi, I have an ldap directory tree with a lot of organizational units. For each of these OUs I set one or multiple "myManager" attributes having as value the DN of the users I want to. I have set dynlist in order to have an attribute myManagerOf on every user object. Now, with one search, I would like to have all the manager "(myManagerOf=*)". But substring filter does not work. Only equality as far as I understand. Of course, as I read in some different topics, it is not feasible using dynlist. I thought that the overlay autogroup would help on that point but at this stage, I'm not able to make it working. Here is my autogroup config so far: dn: olcOverlay={4}autogroup,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutoGroupConfig olcOverlay: {4}autogroup olcAutoGroupAttrSet: myOrganizationalUnit memberUrl myManager olcAutoGroupMemberOfAd: myManagerOf I tried to play with this autogroup config and dynlist one, but since I added autogroup, no way to change the myManager attribute, I always face an error. Which I don't have without autogroup: ldap_modify: Constraint violation (19) additional info: attempt to modify dynamic group member attribute If autogroup considers that only "memberUrl" can touch myManager attribute then it sounds logical. However, how could I achieve my goal then ?

1 0

context of slapd service
by Carsten Jäckel 15 Jun '22

15 Jun '22

Hello experts, can you please give me some hints about best practice to run the slapd service? Is it advantageous to run the slapd with it's own service user/group (e. g. ldap:ldap) or is it recommended to run slapd as root (as it seems to be default)? Can you tell me something about advantages/disadvantages of each configuration? Thank you for your support, Carsten

4 3

Bind failures via open ldap proxy for few users -
by shekhar.shrinivasan＠gmail.com 11 Jun '22

11 Jun '22

Hi, We have setup a open ldap proxy with AD backend and we are seeing the following bind error for some users. The only difference in successful bind users versus the failed ones is the addition of square brackets "[]" in the user profile. As seen below for the failed users "X" is inside square brackets. Can you please provide some pointers on this issues. Thanks for your help as always. For example - cn=Terry\2C Troy [X],ou=X Accounts,ou=Users,ou=Users & Groups,dc=or,dc=myorg,dc=org --> BIND FAILED cn=CN=Meza\, Rosalinda X,ou=X Accounts,ou=Users,ou=Users & Groups,dc=or,dc=myorg,dc=org --> BIND SUCCESS slapd[15544]: conn=3206402 op=6 BIND dn="cn=Terry\2C Troy [X],ou=X Accounts,ou=Users,ou=Users & Groups,dc=or,dc=myorg,dc=org" method=128 slapd[15544]: conn=3206402 op=6 meta_back_search[3] match="OU=X Accounts,OU=Users,OU=Users & Groups,dc=or,dc=myorg,dc=org" err=32 (No such object) text="0000208D: NameErr: DSID-03100241, problem 2001 (NO_OBJECT), data 0, best match of:#012#011'OU=X Accounts,OU=Users,OU=Users & Groups,DC=or,dc=myorg,DC=org'#012". slapd[15544]: conn=3206402 op=6 meta_back_bind: no target for dn "cn=Terry\2C Troy [X],ou=X Accounts,ou=Users,ou=Users & Groups,dc=or,dc=myorg,dc=org" (32). slapd[15544]: conn=3206402 op=6 RESULT tag=97 err=49 text=

1 0

Failing to modify olcSizeLimit
by RAIMBAULT Alain - Contractor 10 Jun '22

10 Jun '22

Hi, I am trying to modify my DB parameters to fix following issue, root@laselainfldap01p:~# ldaplist passwd ldaplist: libsldap.so.1 internal error LDAP configuration problem: LDAP ERROR (4): Error occurred while receiving results. Size limit exceeded. and libldap returned: (4) using ldaps://laselainfldap01p:636 root@laselainfldap01p:~# To achieve this, I attempted the following but I got priviledge issue accessing the DB .... # cat sizelimit.ldif dn: cn=config changetype: modify replace: olcSizeLimit olcSizeLimit: -1 root@laselainfldap01p:/etc/openldap/slapd.d/cn=config# ldapmodify -v -H ldapi:/// -Y EXTERNAL -f sizelimit.ldif ldap_initialize( ldapi:///??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 replace olcSizeLimit: -1 modifying entry "cn=config" ldap_modify: Insufficient access (50) root@laselainfldap01p:/etc/openldap/slapd.d/cn=config# root@laselainfldap01p:/etc/openldap/slapd.d/cn=config# ldapmodify -v -h 10.136.16.197 -D "cn=Manager,dc=tosa,dc=thales" -w tco_tosa_thales -f sizelimit.ldif ldap_initialize( ldap://10.136.16.197 ) replace olcSizeLimit: -1 modifying entry "cn=config" ldap_modify: Insufficient access (50) root@laselainfldap01p:/etc/openldap/slapd.d/cn=config#<mailto:root@laselainfldap01p:/etc/openldap/slapd.d/cn=config#> Some priviledge access seems missing but I do not understand how to setup this. Could you, please, provide some directions on this. Kind regards, Alain

4 13

dynlist +memberOf loses casing in memberOf attribute
by Felix Schäfer 07 Jun '22

07 Jun '22

Good evening, We are currently in the process of upgrading our OpenLDAP installation and we have hit a behaviour we can’t explain by perusing the documentation. When using slapo-dynlist to set memberOf attributes the dn of the group the object is a member of gets lowercased. So for example the object that is a member of a group has: === memberOf: ou=kiosk,ou=ags,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de === Although the group has a dn of: === dn: ou=Kiosk,ou=AGs,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de === Is this expected behaviour? Is there a setting we overlooked? Is this is a bug in the version shipped with Ubuntu (2.5.6+dfsg-1~exp1ubuntu1.1)? Thank you, Felix

5 21

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2022