openldap-technical June 2022

openldap-technical@openldap.org

34 participants
29 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2022