openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

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

olcTLSProtocolMin not taking effect
by juan＠quantifind.com 06 Jun '22

06 Jun '22

Hi all - As part of routine security remediation my company asked me to remove the support for older TLS versions from my LDAP server. To this effect I restarted the service after running the following: sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -a -f olcTLSProtocolMin.ldif Here is the content of olcTLSProtocolMin.ldif dn: cn=config changetype: modify add: olcTLSProtocolMin olcTLSProtocolMin: 3.3 When I look at the /etc/ldap/slapd.d/cn=config.ldif file I can see the olcTLSProtocolMin: 3.3 entry. however, when I scan the LDAP server using Nessus, the scanner reports older versions of TLS still available. Also if I scan the supported TLS version using nmap it also reports TLS1.0-TLS1.2 If it helps here is the cn=config.ldif file is here dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: stats sync olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem olcTLSCertificateFile: /etc/ssl/certs/my_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/my_slapd_key.pem olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: SomeUUID creatorsName: cn=config createTimestamp: 20160311213839Z olcTLSProtocolMin: 3.3 entryCSN: 20220601202658.429433Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber Any help will be greatly appreciated. JRosario

2 4

Re: Antw: [EXT] Re: slow memberOf queries in 2.5 with dynlist overlay
by Paul B. Henson 03 Jun '22

03 Jun '22

On 5/30/2022 11:53 PM, Ulrich Windl wrote: > I wonder: Would forcing a core dump help in that situation, or would a > gprof-compile be helpful? Unfortunately I can't reproduce it; it just happens randomly on my production boxes, less frequently since I increased the amount of memory on them. I'm not sure I could run a debug or profiling build in production for an extended amount of time waiting for it to happen. And with my luck it would be a heisenbug anyway 8-/. > Maybe one could track down the page fault to some code (function) using tools > from the valgrind family (Cachegrind, callgrind, etc.) > http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.va…

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical