openldap-technical December 2024

openldap-technical@openldap.org

24 participants
21 discussions

Unable to get the contextCSN
by Frédéric Goudal 08 Jan '25

08 Jan '25

Hello, I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $ It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000 where the csn is correct. What is strange is that if I try to get the contextCSN, from the directoryI have no value returned : /usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN # # search result search: 2 result: 0 Success # numResponses: 1 The olcSyncrepl value is : {0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbServiceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates I have several other secondary ldap from the same source, with the same confiiguration, except the filter is (objectClass=*) and there is no attrs value. I suspect the error is on the attrs or filter but what do I miss ? thanks in advance f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

3 6

LDAP Tools don't use LDAP.conf
by maudez.eric＠neuf.fr 07 Jan '25

07 Jan '25

I notice that the ldap.conf file is not used with commands ldapsearch, ldapwhoami (ldap tools). An environment variable (LDAPCONF) was set and pointing to the file (/etc/openldap/ldap.conf) but it doesn't work. On the other hand, using the information provided in an ldaprc file works. How to ensure the LDAP.conf file is taken into account because I need it for a mutual authentication connection with the use of LDAPS for SASL EXTERNAL. I'm using an openldap 2.6.6 version on CentOS.

7 20

monitoring MMR sync
by Dave 07 Jan '25

07 Jan '25

Hello Everyone, Hope you are enjoying the day. Was curious what people are doing to monitor their MMR clusters being out of sync. At least the implementation we found and have been trying is using telegraf and the [ldap_org](https://github.com/falon/CSI-telegraf-plugins/blob/master/plugins… plugin to gather all objects on each ldap master and compare their count. How is the community doing it? Any better way to go about this? Any input is appreciated! Best, Dave

6 7

Re: consumer replication net recovering
by Suresh Veliveli 03 Jan '25

03 Jan '25

This is another instance where replication stops. Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060050.594465Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=xxxx,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=xxxxx,ou=People,dc=georgetown,dc=edu (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_message_to_entry: rid=143 DN: uid=xxxxx,ou=People,dc=georgetown,dc=edu, UUID: db41232e-527d-103f-995c-4344349468b5 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060104.603554Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=yyyyy,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=yyyy,ou=People,dc=georgetown,dc=edu (0) No "syncrep_" messages were logged after the above. Regards, Suresh On Mon, Dec 23, 2024 at 2:42 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 5:46 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have these but no syncrepl_sync. > > > > > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_message_to_entry: > > rid=129 DN: uid=xxxx,ou=xxxx,dc=georgetown,dc=edu, UUID: > > 37387976-3ae0-103f-94fc-3b4be3361dc7 > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_entry: rid=129 > > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > > csn=20241212135921.652395Z#000000#000#000000 tid 0x7f671b7fe640 > > Yes sorry, that was a typo on my end. > > "syncrepl_" sync messages. Specifically you want to see the ones that > have > "be_" in them, but not "be_search". I.e., be_add, be_modify, etc. They > show the result of the operation, something like: > > syncrepl_entry: rid=100 be_modify <DN> (<result code>) > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

3 8

Re: Replication issues with openldap 2.5
by Ulises Gonzalez Horta 03 Jan '25

03 Jan '25

Thanks for replying, from what I see in your answer, I have already distracted a and b, I can say c is also ruled out but I would like to double check it, maybe acls are not processing in the expected order. What is the best way to troubleshoot acls?? Any recommended log level? Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com> On Fri, Dec 27, 2024 at 2:09 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 27, 2024 10:34 AM -0500 Ulises Gonzalez Horta > <ugonzalezhorta(a)breezeline.com> wrote: > > > > > > > Good morning > > > > I am trying to setup a replication in ldap 2.5, using syncrepl, I have a > > provider server and a consumer, both of the servers are running 2.5.11 > > from Ubuntu 22.04, I followed the admin guide chapter 18.3.1 to do the > > configuration. I have some information on the provider that is > > successfully being replicated to the consumer without any errors > > > > > > Consumer configuration > > ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcSyncRepl > > olcUpdateref > > dn: olcDatabase={1}mdb,cn=config > > olcSyncrepl: {0}rid=100 provider=ldap://provider:389 type=refr > > eshOnly interval=00:00:05:00 retry="300 +" > > searchbase="dc=metrocast,dc=net" f > > ilter="(|(entryDN:=dc=metrocast,dc=net)(entryDN:dnOneLevelMatch:=dc=met > > > Why do you have such a complicated filter? > > > > > On the consumer this same query returns error 49 > > > > ldapsearch -Z -LLL -H ldap://providert:389 -D > > "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b > > "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) > > Either: > > a) The user entry doesn't exist > b) The user entry is missing the userPassword attribute > c) The ACLs don't allow anonymous "auth" access on the userPassword > attribute > > --Quanah > > >

5 11

Hello, I have an issue with the configuration of pam_setquota.so. I added the following quota schema:
by Rodrigo Prieto 03 Jan '25

03 Jan '25

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 8fd665e7 dn: cn=quota,cn=schema,cn=config objectClass: olcSchemaConfig cn: quota olcAttributeTypes: {0}( 1.3.6.1.4.1.19937.1.1.1 NAME 'quota' DESC 'Quotas (FileSystem:BlocksSoft,BlocksHard,InodesSoft,InodesHard)' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{255} ) olcObjectClasses: {0}( 1.3.6.1.4.1.19937.1.2.1 NAME 'systemQuotas' DESC 'System Quotas' SUP posixAccount AUXILIARY MUST uid MAY quota ) I create a user, and the attributes are created correctly: objectclass: systemQuotas objectclass: posixAccount objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person quota: /home,500,510,0,0 Configuration of /etc/pam.d/common-session: # here are the per-package modules (the "Primary" block) session [default=1] pam_permit.so # here's the fallback if no module succeeds session requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around session required pam_permit.so # and here are more per-package modules (the "Additional" block) session required pam_unix.so session [success=ok default=ignore] pam_ldap.so minimum_uid=1000 session optional pam_systemd.so session optional pam_mkhomedir.so skel=/etc/skel umask=077 session required pam_setquota.so # end of pam-auth-update config When logging in with an LDAP user, the following appears in Debian logs: pam_setquota(login:session): no limits defined in configuration for user zprieto on /dev/vda5. I don’t know what is missing that prevents the user’s attributes from being read. Thank you very much.

2 1

Replication issues with openldap 2.5
by Ulises Gonzalez Horta 27 Dec '24

27 Dec '24

Good morning I am trying to setup a replication in ldap 2.5, using syncrepl, I have a provider server and a consumer, both of the servers are running 2.5.11 from Ubuntu 22.04, I followed the admin guide chapter 18.3.1 to do the configuration. I have some information on the provider that is successfully being replicated to the consumer without any errors Consumer configuration ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcSyncRepl olcUpdateref dn: olcDatabase={1}mdb,cn=config olcSyncrepl: {0}rid=100 provider=ldap://provider:389 type=refr eshOnly interval=00:00:05:00 retry="300 +" searchbase="dc=metrocast,dc=net" f ilter="(|(entryDN:=dc=metrocast,dc=net)(entryDN:dnOneLevelMatch:=dc=metrocast ,dc=net)(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=net)(entrydn:dnSubtreeMatc h:=ou=Boxes,dc=metrocast,dc=net))(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=n et)(entrydn:dnSubtreeMatch:=ou=RadiusGroups,dc=metrocast,dc=net))(&(entryDN:d nSubtreeMatch:=dc=metrocast,dc=net)(entrydn:dnSubtreeMatch:=ou=group,dc=metro cast,dc=net))(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=net)(entryDN:distingu ishedNameMatch:=ou=People,dc=metrocast,dc=net))(&(entryDN:dnSubtreeMatch:=dc= metrocast,dc=net)(entryDN:dnSubtreeMatch:=ou=employees,dc=metrocast,dc=net))) " timelimit=unlimited sizelimit=unlimited bindmethod=simple binddn="cn=user,ou=boxes,dc=metrocast,dc=net" credentials="xxxx" start tls=critical tls_cacertdir="/etc/ldap/certs" olcUpdateRef: ldap://ldap-write.metrocast.net:389 I can confirm the DIT is present on the consumer and the values matches the provider item by item, including the encrypted passwords, The issue I am having is that a query that runs on the provider without any issue is failing to run on the consumer with error 49 invalid credentials, but I do know for sure that the provided credentials are good, I even did a tcpdump and confirmed they are fine On the provider a query similar to this one runs fine and returns a result ldapsearch -Z -LLL -H ldap://providert:389 -D "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) On the consumer this same query returns error 49 ldapsearch -Z -LLL -H ldap://providert:389 -D "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) I confirmed with ldapsearch -Y EXTERNAL -H ldapi:/// ..... that the information for user1 is exactly the same in the provider and the consumer for all the attributes including the passwords. Tcpdump confirmed that I am sending the right password, doing -W or -w $password gives the same result. For any user I use to run the query I get exactly the same error 49, I did verify that ACLs are not blocking the query. Is there anything else I should check?? any log level that could help me identify where the error is?? Currently my loglevel is olcLogLevel: 128 256 1024 This is a dev environment so I can do changes at will. Thanks and happy new year Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com>

2 1

Re: consumer replication net recovering
by Suresh Veliveli 23 Dec '24

23 Dec '24

Pretty sure It didn't hit the defined maxsize. -rw-------. 1 ldap_svc ldap_svc 108993459200 Dec 20 17:36 data.mdb du -c -h data.mdb 5.2G data.mdb 5.2G total I don't see any "syncrepl_sync" references in the replica logs. The loglevel is "stats sync". Am I missing something? Thanks, Suresh On Fri, Dec 20, 2024 at 5:15 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 2:07 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have sync logging enabled. This is the last record in the log file, > > and after that, nothing. It isn't attempting to get changes. > > One thing I'd confirm is that you haven't hit the defined maxsize of your > MDB database. > > Also, I don't see the result in what you posted for the operation. You > seem to have excluded all the "syncrepl_sync" log lines which are critical. > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 2

Re: consumer replication net recovering
by Suresh Veliveli 20 Dec '24

20 Dec '24

I do have sync logging enabled. This is the last record in the log file, and after that, nothing. It isn't attempting to get changes. Log on the replica: Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_queue_csn: queueing 0x7f67101bc860 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_graduate_commit_csn: removing 0x7f67101bc860 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_queue_csn: queueing 0x7f67102311b0 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_graduate_commit_csn: removing 0x7f67102311b0 2*0241212135921.652395Z#000000#000#000000* *Log on the master:* Dec 12 08:59:30 aaa-prod-master-1 slapd[4072]: conn=936345 op=1 syncprov_sendresp: cookie=rid=129,csn=20241212135921.637305Z#000000#000#000000 *Dec 12 08:59:30 aaa-prod-master-1 slapd[4072]: conn=936345 op=1 syncprov_sendresp: cookie=rid=129,csn=20241212135921.652395Z#000000#000#000000* There is nothing in the log on the master or the replica after this entry. Regards, Suresh On Fri, Dec 20, 2024 at 1:40 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 11:22 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > > > Hi, > > > > > > We have a single master with multiple replicas. Our backend is mdb, and > > we are on the latest version, 2.6.9. The replication type > > is refreshAndPersist. Here is the relevant configuration. > > > > > > syncrepl rid=141 > > provider=ldaps://ldap-master.georgetown.edu:636/ > > type=refreshAndPersist > > > > .. > > .. > > keepalive=300:5:5 retry="5 5 300 +" > > > > > > > > This is now happening at regular intervals. When a consumer replication > > gets stuck, only a service restart seems to restart replication. > > > Need more information on what you mean by "getting stuck". Is it actually > attemping to get changes? Do you have sync logging enabled? If so, you > could see if that particular consumer is having an issue during > replication > and returning a non-zero result code as to why it's unable to proceed. Or > is it not establishing a replication connection at all? etc. > > --Quanah > > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

consumer replication net recovering
by Suresh Veliveli 20 Dec '24

20 Dec '24

Hi, We have a single master with multiple replicas. Our backend is mdb, and we are on the latest version, 2.6.9. The replication type is refreshAndPersist. Here is the relevant configuration. syncrepl rid=141 provider=ldaps://ldap-master.georgetown.edu:636/ type=refreshAndPersist .. .. keepalive=300:5:5 retry="5 5 300 +" This is now happening at regular intervals. When a consumer replication gets stuck, only a service restart seems to restart replication. ex: ldap-replica-1:1636 # requesting: contextCSN contextCSN: 20241212135921.652395Z#000000#000#000000 ldap-replica-1:2636 # requesting: contextCSN contextCSN: 20241220010002.746041Z#000000#000#000000 You can see the replica on port 1636 CSN is stuck at 20241212135921. Any thoughts? Thanks, -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2024