- openldap-technical - openldap.org

etensibleObject vs. creating a new schema
by Uwe Sauter 26 Mar '24

26 Mar '24

Hi all, I was wondering if there is any best practice when to use extensibleObject in contrast to creating new objectClasses within a local schema. E.g. I have the need to filter the visibility of posixGroups depending on some attribute when sssd is accessing the directory. What I could do is to use an extra objectClass: extensibleObject to allow all defined attributes (e.g. host) to be used within my object. I could also create a new objectClass ( 2.25.$UUID.1.2.1 NAME 'myGroup' DESC 'Group with host attribute' SUP posixGroup AUXILIARY MAY host ) As far as I can tell using extensibleObject has the disadvantage to more or less disable the checks for correct attribute usage. Are there more positive or negative aspects to extensibleObject? I'd like to hear your thought on this. Thanks, Uwe

1 0

Logo usage
by Gloria Semme 21 Mar '24

21 Mar '24

Dear OpenLDAP Technical Team, I am reaching out to seek your guidance and permission regarding the use of the OpenLDAP logo. My team is in the process of creating a Grafana integration designed to facilitate the monitoring of OpenLDAP applications for our users. To enhance user experience and direct attention effectively, we plan to incorporate the OpenLDAP logo within the Grafana Cloud interface. Upon reviewing the available licensing information, we noted the absence of specific guidelines related to the use of the OpenLDAP logo. Given this, we wish to ensure our use aligns with your expectations and policies. Our design considerations include adjusting the logo to fit a square format to suit the dashboard's aesthetic. We are committed to respecting your branding guidelines and are open to any alternative suggestions or requirements you may have. We appreciate your support in this endeavor and look forward to your guidance. Thank you for your guidance. Best regards, -- [image: photo] *Gloria Semme* Sr. Engineering Manager Cloud Infrastructure Observability gloria.semme(a)grafana.com www.grafana.com

2 1

olcDbURI
by Bradley T Gill 15 Mar '24

15 Mar '24

Good Morning Group. I am struggling to find any documentation on this. Is there a limit to the amount of olcDbURI that can be defined for SASL? While I'm here, I might as well ask if there is a way to make it more resilient? Our servers get quarantined during pathing of AD and eventually SASL is broken until I restart OpenLDAP. Thanks! Bradley Gill

1 0

Lock conflicts?
by rzhou44＠tutamail.com 12 Mar '24

12 Mar '24

At work we have a program that actively reads/writes into LMDB file. This program uses MDB_NOLOCK (why, I'm not sure yet). Can I safely read/write to this LMDB file using my own programs or mdb_ command line tools? I worry that those (which by default use lock files) could conflict with the manual locking of the existing program and cause data corruptions. Thanks -Zhou

2 3

Configure replication without a plaintext password.
by mbalakri＠opentext.com 09 Mar '24

09 Mar '24

How to configure olcSyncrepl without a plaintext password? I tried using credentials="{SSHA256}jRlrKRCcrhYo7SqbPDc5WkoSxaHc8y/e0DPWaAnveUkQpQ7wEOWhsw==" format. Does olcSyncrepl accepts password in {SSHA256} format?

5 8

LMDB fix sized key and data question
by anton＠pcloud.com 07 Mar '24

07 Mar '24

Hello, I'm designing an application that will use LMDB. All (or almost all) of my databases will have a fixed size integer key (64bit) and fixed size data. Data is larger than a single integer but generally in 16-32 bytes range (range is for different databases, each database has a fixed data format). I'll not have duplicate key records. I'll mostly insert and retrieve single records. The question is would I benefit and should I use MDB_DUPSORT|MDB_DUPFIXED? Also the documentation says that MDB_DUPFIXED may only be used with MDB_DUPSORT. However I see code that specifically checks for MDB_DUPFIXED without MDB_DUPSORT and only then sets a flag for DUPFIXED records. However I did not get too deep in the code. https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L7743 My point is that with fixed sized keys and values the btree may chose not to store record sizes, may not use pointers for the binary search but to search values instead and so on. Is that the optimization that is being done for MDB_DUPFIXED or is it something that only concerns duplicate values? Best, Anton

2 1

Counter concurrency access
by Pascal Jakobi 06 Mar '24

06 Mar '24

Hi there I am creating a program that needs to increment a counter. Typically a serial number has to be incremented every time I create a certificate. The problem is to handle concurrent access. Fundamentally I need to 1/ read the counter 2/ increment it. Therefore no one must be provided access to the counter during these two operations. Therefore I need to set a lock before the read operation and release it after the update. Is there a way to do this with OL ? I am conscious of the ldapmodify features thanks to Clement, however, this will not lock the read. Thks in adv. P

2 2

slapo-translucent bug?
by Marco Esposito M. 05 Mar '24

05 Mar '24

Dear openldap-technical, I have encountered an issue with slapo-translucent and I am trying to determine whether it is a problem with my configuration or a bug. By mistake, I opened a ticket on OpenLDAP ITS, and rightfully, I have been redirected here. https://bugs.openldap.org/show_bug.cgi?id=10184 The problem is as follows: the results from a translucent OpenLDAP server do not return any entry when a single attribute is present in the query filter. This attribute has been previously modified and is present in the local database of the translucent OpenLDAP server. To better explain the issue, I have set up an environment with containers. The repository is as follows: https://github.com/voidloop/openldap-bug To bring up the environment, two commands are needed: % make submodules % make docker-run Three containers will be running: upstream: a simple LDAP server with a couple of users, listening on port 51389/tcp. buggy: the translucent server from upstream with the problematic behavior, listening on port 52389/tcp. compiled: the translucent server from upstream recompiled with the modified code where I suspect there might be an issue, listening on port 53389/tcp. The containers are simple Fedora instances with OpenLDAP. Once the following ldapmodify command is executed: % ldapmodify -x -D cn=buggy,dc=example,dc=com -w password -H ldap://:52389 <<EOF dn: uid=ciccio,ou=people,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 EOF The following occurs: 1) Querying servers without filters: ------------------------------------------------------------------------------- Server "upstream" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:51389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "buggy" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:52389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 99 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "compiled" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:53389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 99 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 So far, everything is okay, no anomalous behavior. The issue arises when a filter is introduced. 2) Querying servers with a filter ------------------------------------------------------------------------------- Server "upstream" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:51389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com uidNumber: 1000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "buggy" (!!) ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:52389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # search result search: 2 result: 0 Success # numResponses: 1 ------------------------------------------------------------------------------- Translucent server "compiled" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:53389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com uidNumber: 99 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Why does this behavior occur? I expect the "buggy" server to return the uidNumber attribute. The version of OpenLDAP in the container is the one installed with the Fedora package manager. Server configurations are available in the Git repository, but for convenience, I am listing them here: upstream: https://github.com/voidloop/openldap-bug/blob/main/upstream/slapd.ldif https://github.com/voidloop/openldap-bug/blob/main/upstream/entries.ldif buggy: https://github.com/voidloop/openldap-bug/blob/main/buggy/slapd.ldif compiled: https://github.com/voidloop/openldap-bug/blob/main/compiled/slapd.ldif The source code modification is as follows: % diff openldap/servers/slapd/overlays/translucent.c translucent.c -u --- openldap/servers/slapd/overlays/translucent.c 2024-02-29 11:30:52.620837844 +0100 +++ translucent.c 2024-02-29 11:14:11.274843929 +0100 @@ -928,16 +928,7 @@ /* send it now */ rs->sr_entry = re; rs->sr_flags |= REP_ENTRY_MUSTBEFREED; - if ( test_f ) { - rc = test_filter( op, rs->sr_entry, tc->orig ); - if ( rc == LDAP_COMPARE_TRUE ) { - rc = SLAP_CB_CONTINUE; - } else { - rc = 0; - } - } else { - rc = SLAP_CB_CONTINUE; - } + rc = SLAP_CB_CONTINUE; } } else if ( le ) { /* Only a local entry: remote was deleted I have also found posts from individuals who have identified the same issue, but either received no response or the response was unsatisfactory: https://openldap.org/lists/openldap-technical/201304/msg00069.html https://www.openldap.org/lists/openldap-bugs/200905/msg00159.html https://www.openldap.org/lists/openldap-technical/201106/msg00036.html Thank you for your attention, and I apologize for the lengthy message. Marco

2 2

OpenLDAP SQL
by kimkihoon 05 Mar '24

05 Mar '24

I'm trying to use mysql external db server for openLDAP db. I just read this README file from openldap github(https://github.com/openldap/openldap/blob/master/servers/slapd/back-… But it seems only localhost server can be used. Can anyone tell me how? Thx for the help

3 2

Fwd: New Ldap 2.6.6 in Kubernetes
by Jignesh Patel 01 Mar '24

01 Mar '24

We have set up a new docker OpenLDAP Version 2.6.6 on Kubernetes. We could migrate all the data except the following two attributes *authTimestamp* and *lastLoginTime* not working in personalized schema. How to configure them?

2 1

Disable uniqueness for mail Attribute
by CALDEIRA JAVIEL Sandro 01 Mar '24

01 Mar '24

Hi, I have a legacy ldap instance (openlda-2.4) which has in the same redundant user info containing mail attribute among others (objectclass: inetOrgPerson) in 2 different ous (objectclass: organizationalUnit). I know it is a bad design for ldap users structure but I am not allowed to change it in a short time. When I tried to migrate this ldap database to openldap 2.6 I realize this is not possible anymore. I identified it is just related to mail attribute because if I omit mail attribute or use a different value for mail, then all data is imported properly. Error from phpldapadmin: Attribute value would not be unique This update has been or will be cancelled, it would result in an attribute value not being unique. You might like to search the LDAP server for the offending entry. (Search) warn LDIF text import Could not add object cn=*****,ou=Users,ou=TRG01,dc=***,dc=*****,dc=** LDAP said: Success Error number: 0x00 (LDAP_SUCCESS) Description: The operation completed successfully.

3 9

memberOf with groupOfNames
by Stefan Kania 01 Mar '24

01 Mar '24

Hi to all, up to now I only used: olcDlAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames to dynamically add the Attribute memberOf to all members of a groupOfURLs. Is it possible to do the same with members for groupOfNames and groupOfUniqueNames? I yes, can someone please post the syntax? Stefan

2 3

All LDAP content is not replicating to Node2 with replication message 'not new enough, ignored'
by mbalakri＠opentext.com 16 Feb '24

16 Feb '24

Hello, We need some help to resolve the intermittent sync replication issue. We have configured mirror mode replication with two nodes. Node1 syncrepl {0}rid=1 provider=ldaps://AWPCISQL22.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="60 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-key.pvk" Node2 syncrepl {0}rid=2 provider=ldaps://AWPCTHA1.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="60 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-key.pvk" olcMultiProvider is ON. We have tested replication and observed that inserting an entry into Node1 syncs to Node2, and adding an entry to Node2 syncs to Node1. Similarly, delete and update operations are working as expected. However, during continuous updates to Node1 (while both Node1 and Node2 are running, and operations like importing an .ldif file from JXplorer to Node1), some entries are not syncing to Node1. The replication logs show the following message: "rid=002 entry 'cn=GetCollection,cn=Method Set ISVPackage,cn=Cordys ESBServer,cn=cordys,cn=defaultInst,o=otxlab.net' csn=20231124172411.004202Z#000000#001#000000 not new enough, ignored" We created ticket 10136 to address this issue but did not identify the root cause initially. Upon analysis, we found that all entries producing the "not new enough, ignored" message are not syncing to Node2. We were previously using OpenLDAP 2.4 version, and this scenario worked correctly. However, we started noticing the issue after upgrading to OpenLDAP 2.5.13 version. Upon reviewing the syncrepl defect fixes, we identified this fix: https://git.openldap.org/openldap/openldap/-/commit/8d428f3163e56f90cb84cdd…, which appears to be causing the problem. We reverted this fix locally, rebuilt OpenLDAP, and tested it. The issue is not reproducible with the reverted fix. In summary, the basic scenario of adding entries to Node1 is not syncing to Node2 sometimes. Do you have any suggestions to avoid this issue?

1 1

The unique overlay: enforcing uniqueness in the union of trees
by Norman Gray 15 Feb '24

15 Feb '24

Greetings. How should I use the 'unique' overlay to enforce uniqueness of an attribute across two trees? I'd have thought that the following would work, to enforce uniqueness across ou=dept1 and ou=dept2, but it doesn't seem to. dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept1,o=example?uidnumber?sub ldap:///ou=dept2,o=example?uidnumber?sub (and cf, slapd/overlays/unique.c:unique_new_domain). When I configure a server with this, and load two entities with the same uidNumber, the server doesn't object. I'm clearly misunderstanding something. The slapo-unique(5) manpage suggests that having two URIs juxtaposed like this is syntactically OK, but it doesn't make clear the semantics of this. I'd guessed that the above configuration would create a 'domain' which is the union of the two subtrees, but that doesn't seem to be the case. Another thing that such a line could potentially specify is that a tuple of attributes is unique. For example that 'olcUniqueUri: ldap:///?sn?sub ldap:///?cn?sub' specifies that (sn,cn) is unique. There's nothing in the slapo-unique manpage that would back up this interpretation, though. Or is the above configuration in fact equivalent to olcUniqueURI: ldap:///ou=dept1,o=example?uidnumber?sub olcUniqueURI: ldap:///ou=dept2,o=example?uidnumber?sub which would enforce uniqueness of uidnumber on trees ou=dept1 and ou=dept2 separately. I take it that this isn't so, because the manpage talks of multiple 'domains', each of which can have multiple URIs. In the example below, if I instead add user uid=u2,ou=dept1,o=example, then a duplicated uidNumber is indeed rejected in the ldapadd step (so the overlay is active). I see an older thread [1] on this topic, but that refers only to a single URI in the olcUniqueURI attribute. That was resolved by adding an index on the relevant attribute, but that index is included in the configuration below. (The goal here is to enforce uniqueness of uidNumber attributes in (dept1 union dept2) and (dept1 union dept3), but permit duplication in dept2 and dept3.) Thanks for any illumination, Norman [1] https://www.openldap.org/lists/openldap-technical/201808/msg00016.html Witness: % cat uniqueness-test-config.ldif dn: cn=config objectclass: olcGlobal cn: config olcPidFile: /tmp/uniquenesstest/slapd.pid dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleload: back_mdb.la olcModuleload: unique dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/nis.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcSuffix: o=example olcRootDN: cn=admin,o=example olcRootPW: dummypass olcDbIndex: default eq olcDbIndex: objectclass olcDbIndex: uidNumber eq olcDbDirectory: /tmp/uniquenesstest/data dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept1,o=example?uidNumber?sub ldap:///ou=dept2,o=example?uidNumber?sub % cat uniqueness-test-data.ldif dn: o=example objectClass: organization o: example dn: ou=dept1,o=example objectclass: organizationalunit ou: dept1 dn: uid=u1,ou=dept1,o=example objectclass: person objectclass: posixAccount sn: Two cn: User One uid: u1 uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/u1 dn: ou=dept2,o=example objectclass: organizationalunit ou: dept2 dn: uid=u2,ou=dept2,o=example objectclass: person objectclass: posixAccount sn: Two cn: User Two uid: u2 uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/u2 % slapadd -v -F /tmp/uniquenesstest/slapd.d -n0 -l uniqueness-test-config.ldif added: "cn=config" (00000001) added: "cn=module{0},cn=config" (00000001) added: "cn=schema,cn=config" (00000001) added: "cn={0}core,cn=schema,cn=config" (00000001) added: "cn={1}cosine,cn=schema,cn=config" (00000001) added: "cn={2}nis,cn=schema,cn=config" (00000001) added: "olcDatabase={1}mdb,cn=config" (00000001) added: "olcOverlay={0}unique,olcDatabase={1}mdb,cn=config" (00000001) Closing DB... % slapd -F /tmp/uniquenesstest/slapd.d % ldapadd -x -H ldap:/// -D cn=admin,o=example -w dummypass -f uniqueness-test-data.ldif adding new entry "o=example" adding new entry "ou=dept1,o=example" adding new entry "uid=u1,ou=dept1,o=example" adding new entry "ou=dept2,o=example" adding new entry "uid=u2,ou=dept2,o=example" % ldapsearch -LLL -H ldap:/// -b o=example '(objectclass=person)' uidnumber dn: uid=u1,ou=dept1,o=example uidNumber: 1000 dn: uid=u2,ou=dept2,o=example uidNumber: 1000 % slapd -VVV @(#) $OpenLDAP: slapd 2.6.7 (Jan 1 1980 00:00:00) $ openldap Included static overlays: accesslog syncprov unique Included static backends: config ldif monitor mdb relay -- Norman Gray : https://nxg.me.uk

3 5

postscript(subject:I lost all data(perhaps))
by 長田泰志 13 Feb '24

13 Feb '24

Sorry! There was something missing in the question you asked earlier, so I'll add it. c.The method of restoring the slave (2.6.3) system uses ldapadd to restore the backup data obtained by ldapsearch, so the entryUUID has been changed. thank you! -- ***************************************************** 　アイクラフト株式会社顧客サービス部長田　泰志〒650-0034 神戸市中央区京町83 三宮センチュリービル13F TEL:078-391-2900 FAX:078-391-2901 *****************************************************

2 1

I lost all data(perhaps)
by Yasushi Nagata 13 Feb '24

13 Feb '24

Hi 2/6 I lost all user's data of slave system The following events I had 3 system I would do System migration from centos7 to rhel9 and from openldap 2.4.44 to 2.6.3 The following pair of a. and b. c. system data is restored from b.system a.main system 2.4.44 b.slave system 2.4.44 c.slave system 2.6.3 d.main system 2.6.3 First I exchange b. and c. In the plan,I exchange a. and d. After updating data for b. and c. after this but,I'm having problems with other systems. Second I exchnge c, and b. for recovery b.system output the following log Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cd691a-c2e3-1038-83eb-bdd677e9197b, dn o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34ce0d16-c2e3-1038-83ec-bdd677e9197b, dn cn=Manager,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34ce8e3a-c2e3-1038-83ed-bdd677e9197b, dn ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cef0aa-c2e3-1038-83ee-bdd677e9197b, dn ou=Organizations,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cf0c52-c2e3-1038-83ef-bdd677e9197b, dn ou=SystemAccounts,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cf2fca-c2e3-1038-83f0-bdd677e9197b, dn cn=Replication,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 present UUID 34cf4cf8-c2e3-1038-83f1-bdd677e9197b, dn cn=ReplMaster,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe3138e-db18-1038-8977-3f4cb5ea988e, dn xxuid=000001,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe36d98-db18-1038-8978-3f4cb5ea988e, dn xxuid=000003,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe3aaa6-db18-1038-8979-3f4cb5ea988e, dn xxuid=000005,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe3e35e-db18-1038-897a-3f4cb5ea988e, dn xxuid=000008,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe41e32-db18-1038-897b-3f4cb5ea988e, dn xxuid=000009,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe468c4-db18-1038-897c-3f4cb5ea988e, dn xxuid=000011,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe4bb3a-db18-1038-897d-3f4cb5ea988e, dn xxuid=000012,ou=Users,o=XXXXX,c=jp omitted(Probably all users) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000011,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000009,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000008,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000005,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000003,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000001,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete cn=Replication,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete ou=SystemAccounts,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete ou=Organizations,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete ou=Users,o=XXXXX,c=jp (66) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete cn=Manager,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete o=XXXXX,c=jp (66) omitted(Probably all users) Feb 6 18:58:54 als2 slapd[17571]: do_syncrep2: rid=002 cookie=rid=002,sid=001,csn=20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: syncrepl_message_to_entry: rid=002 DN: xxuid=210769,ou=Users,o=XXXXX,c=jp, UUID: 58017300-5914-103e-95a8-5fc7e6f750ea Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 be_search (0) Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 xxuid=210769,ou=Users,o=XXXXX,c=jp Feb 6 18:58:54 als2 slapd[17571]: slap_queue_csn: queueing 0x7ffb3c69f9b0 20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: slap_graduate_commit_csn: removing 0x7ffb3c69f9b0 20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 be_modify xxuid=210769,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:58:54 als2 slapd[17571]: slap_queue_csn: queueing 0x7ffb3c55ca70 20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: slap_graduate_commit_csn: removing 0x7ffb3c55ca70 20240206095854.540617Z#000000#001#000000 Feb 6 18:59:05 als2 slapd[17571]: conn=1022 fd=29 ACCEPT from IP=XXX.XXX.XXX.XXX:35812 (IP=0.0.0.0:389) Feb 6 18:59:05 als2 slapd[17571]: conn=1022 op=0 BIND dn="cn=replication,o=XXXXX,c=jp" method=128 Feb 6 18:59:05 als2 slapd[17571]: conn=1022 op=0 RESULT tag=97 err=49 text= Feb 6 18:59:05 als2 slapd[17571]: conn=1022 op=1 UNBIND Feb 6 18:59:05 als2 slapd[17571]: conn=1022 fd=29 closed omitted(Probably all users) "Replication" user is set for syncrepl. What happened? Did I get hit by an oddball Syncrepl behavior? or Did I miss exchange. If this is bug,openldap 2.6.3 will be solved? Since both the main and slave systems were restored at the checkpoint, only the slave system remains in the log. Thanks for your time, Takashi

1 0

ldapi issue
by chilimili1＠outlook.de 12 Feb '24

12 Feb '24

Problem: When attempting to use the ldapi:// URI to interact with the OpenLDAP server using commands like ldapmodify or ldapsearch, an error is encountered: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1). Process is running # ps -aux |grep ldap ldap 9 0.0 0.4 42232968 79472 ? Sl Jan23 0:10 /usr/libexec/slapd -u ldap -h ldap:/// ldapi:/// ldaps:/// -F /etc/openldap/slapd.d -d 256 Troubleshooting Steps Taken: Verified the ldapi URI configuration. Inspected the OpenLDAP configuration using slapd.conf or cn=config. Examined ACLs and access control rules. Additional Information: OpenLDAP is running as a Docker container on RHEL 9 Basis OS Docker Compose configuration includes port mappings for LDAP (3269:389) and LDAPS (3268:636). The whole configuration was migrated from a working RHEL7 Server with Openladp 2.4.5. the new version in place is 2.5.13 Any additional insights or recommendations for resolving the ldapi connection issue would be greatly appreciated. Additional to this, I would like to activate pagination, but I have not been able to find any configuration for it. Is this something that needs to be done on the server or client side?

6 14

olcLimits and groupOfURLs dynlist
by Norman Gray 12 Feb '24

12 Feb '24

Greetings. I have another puzzle with my OpenLDAP configuration, where I'm not sure if what I'm seeing is unexpected. Short version: should I expect a group in an olcLimits spec to work when the group is dynamic? I have a dynamic group set up, using the dynlist overlay, which expands to a set of DNs which should be allowed slightly privileged access to a directory. That group seems to be working OK: % ldapsearch -x -H ldap://localhost:8389 -b o=example -LLL '(cn=ldap-operators)' dn: cn=ldap-operators,ou=groups,o=example cn: ldap-operators objectClass: groupOfURLs description: Members of all of the LDAP admin and tech groups memberURL: ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs)) member: uid=norman,ou=staff,o=example [...] One goal here is to remove query limits for this group. I can test that by adding an artificially low limit: olcLimits: group/groupOfURLs/member="cn=ldap-operators,ou=groups,o=example" size=2 If I then make a query which has a few results, I do not get this limit imposed, and instead see in the logs 65c3ce83.0f52bea8 0x16e9d3000 => mdb_entry_get: found entry: "cn=ldap-operators,ou=groups,o=example" 65c3ce83.0f533f90 0x16e9d3000 <= mdb_entry_get: failed to find attribute member (If, instead of this, I define an ldap-operators group of class groupOfNames, with the above 'member' included explicitly, and make the corresponding change to the olcLimits line, I get what I expect -- ie, a restricted-size response to the query -- which reassures me I'm not doing something stupid elsewhere.) The slapo-dynlist(5) page says: > Any time an entry with a specific objectClass is being returned, the > LDAP URI-valued occurrences of a specific attribute are expanded into > the corresponding entries, and the values of the attributes listed in > the URI are added to the original entry. I note the ‘any time’. My configuration appears to be working for the ldapsearch lookup; I don't see any text in that manpage that suggests this won't work for the (somehow internal?) lookup being done when processing the olcLimits expression. The page slapd-config(5) says, under olcLimits: > The term group, with the optional objectClass oc and attributeType at > fields, followed by pattern, sets the limits for any DN listed in the > values of the at attribute (default member) of the oc group > objectClass (default groupOfNames) whose DN exactly matches pattern. That text doesn't seem to me to exclude this entry lookup from the ‘any time’ in the slapo-dynlist text above. This is OpenLDAP 2.6.7. I am of course open to a frame-challenge about the best way of achieving the underlying goal. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

2 9

Openldap 2.4 -> Openldap 2.6.3 replication hurdles
by Viktor Keremedchiev 08 Feb '24

08 Feb '24

Hello, I'm somewhat not experienced with LDAP on the server side of things I’m importing openldap 2.4. into 2.6.3. (rockylinux 9). My goal is to 2 have 2 N-way (or multi-master*) ldap nodes. I’ve changed hdb to mdb, created accesslog folder, fixed permissions, SSL etc The import doesn’t throw any errors. My understanding is that I need to have cn=config replication, as well as my small dc=domain,dc=com, replication as well The cn=config replication I call via this on both nodes followed by restarts dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=002 provider=ldaps://prod-ldap2.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N… searchbase="cn=config" schemachecking=on type=refreshAndPersist retry="10 10 60 +" tls_reqcert=allow keepalive=240:10:30 olcSyncRepl: rid=001 provider=ldaps://prod-ldap1.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…… searchbase="cn=config" schemachecking=on type=refreshAndPersist retry="10 10 60 +" tls_reqcert=allow keepalive=240:10:30 - add: olcMirrorMode olcMirrorMode: TRUE Now once I do that I’ve experimented with changing the olcLogLevel and it seems to work. The rid’s on each node are different server2 has rid=002, server 1 has rid=001 as well as different olcServerID The part I run into issues is when I enable replication to the dc=domain,dc=com via dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {2}syncprov olcSpCheckpoint: 20 10 olcSpSessionlog: 10000000 dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=021 provider=ldaps://prod-ldap1.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…. searchbase="dc=domain,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="5 10 60 +" tls_reqcert=allow keepalive=240:10:30 olcSyncRepl: rid=022 provider=ldaps://prod-ldap2.domain.com:636 bindmethod=simple binddn="cn=admin,dc=domain,dc=com" credentials=N…. searchbase="dc=domain,dc=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="5 10 60 +" tls_reqcert=allow keepalive=240:10:30 - add: olcMirrorMode olcMirrorMode: TRUE I have 2 sets rids 001/002 and 021/022 and I have olcMirrorMode set to true on both cn=config and domain replication I’m pasting the relevant code around accesslog and syncprov that I think I’m getting wrong dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {3}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {4}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=adaptavist,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart structuralObjectClass: olcMdbConfig dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig Replication works from node1 to node2, and in reverse. But it stops after 20 minutes or so After replication stops I see the on accesslog on one node has 4 records, on the other it has 3 and it never catches up even if I restart although at first it all works regardless of which node I update (change a random password) What am I doing wrong? Perhaps more than one thing Thank you

3 5

Re: LastBind feature
by Abdelkader Chelouah 08 Feb '24

08 Feb '24

The attribute *olcLastBindPrecisio**n* is not available for OpenLDAP 2.5, *pwdLastSuccess* is updated whenever a BIND operation is successful. Regards On 2/8/24 14:57, Jean-Luc Bourguignon wrote: > Hello, > > Thx for your answer. > > I did not pay attention it was for 2.6x but why it’s working in 2.5.16 as I’ve the new attribut and it’s updated as I wanted, only the precision is not set !! There should be a default value or it’s at each login by default?? > > I was using the old overlay in 2.5.7 but I decided to move from it to source one during upgrade to 2.5.16 as attributes aren’t the same and on my production systems it was not enabled yet then it will be ready to move to 2.6x without having to do actions on old attribut to new one. > > Brgds, > J-L. > > > >> On 8 Feb 2024, at 14:44, Abdelkader Chelouah<a.chelouah(a)gmail.com> wrote: >> >> On 2/8/24 14:39,bourguijl@gmail.com wrote: >>> Dears, >>> >>> I'm running openldap 2.5.16 in which I'm using lastbind feature included in source. >>> To enable it, I read that 2 attributs should be inserted in DB config file side, in which I added : >>> >>> olcLastBind: TRUE >>> olcLastBindPrecision: 3600 >>> >>> But it seems that olcLastBindPrecision isn't supported because when I did a slapcat of the configuration of the ldap instance in which both are added, I get following error message : >>> >>> UNKNOWN attributeDescription "OLCLASTBINDPRECISION" inserted. >>> >>> I removed it from my configuration and restarted the slapd then I discovered that attribut "pwdLastSuccess" is well updated but I don't know with which precision (default ??). >>> >>> So, my question is why this parameter isn't supported ? Is there something else to enable ? >>> >>> Thx in advance, >>> Jean-Luc. >> Hello, >> >> >> It is only supported starting from OpenLDAP 2.6. If you want to used this attribute with OpenLDAP 2.5, you have to switch to lastbind overlay. >> >> >> Regards >>

1 0

LastBind feature
by bourguijl＠gmail.com 08 Feb '24

08 Feb '24

Dears, I'm running openldap 2.5.16 in which I'm using lastbind feature included in source. To enable it, I read that 2 attributs should be inserted in DB config file side, in which I added : olcLastBind: TRUE olcLastBindPrecision: 3600 But it seems that olcLastBindPrecision isn't supported because when I did a slapcat of the configuration of the ldap instance in which both are added, I get following error message : UNKNOWN attributeDescription "OLCLASTBINDPRECISION" inserted. I removed it from my configuration and restarted the slapd then I discovered that attribut "pwdLastSuccess" is well updated but I don't know with which precision (default ??). So, my question is why this parameter isn't supported ? Is there something else to enable ? Thx in advance, Jean-Luc.

2 1

openldap.log file location on Windows environment
by mbalakri＠opentext.com 08 Feb '24

08 Feb '24

Could anyone assist in locating the openldap.log file within a Windows environment? In OpenLDAP version 2.4.58, the log file resided in the same directory as slapd.exe. However, following the upgrade to OpenLDAP 2.5.13, we no longer receive log messages in the openldap.log file. Has the log file's location changed in the recent version? Is there an option available to configure the log file location?

1 1

Upgrade from 2.4.x to 2.6.x
by Sajesh Singh 07 Feb '24

07 Feb '24

Good day OpenLDAP folks. I am looking to upgrade our current OpenLDAP to the latest 2.6 release from my current install of 2.4.44. I am wondering if: 1) Is it possible to have one master running 2.4.44 and another running the latest 2.6 replicating to each other? 2) Is replication possible between hosts that have a mixture of: a) slapd.conf & cn=config b) hdb and mdb Thank you, Saj

2 2

Accesslog requirement for sync replication
by Marc Franquesa 05 Feb '24

05 Feb '24

Hi I have been using replication since long time without any issues (and still without issues), but on recent versions I got this warning on the logs: syncprov_setup_accesslog: couldn't get definition for attribute reqType, is accesslog configured? The answer is no, I never configured accesslog (this why I'm a bit confused, as I never used/needed on my replication setup). After reviewing the documentation I understand that for syncrepl I should load and configure accesslog overlay. Although I have some questions/concerns I haven't been able to found/understand from the documentation and would like someone clarifies: * Is there any way to implement replication without accesslog? (currently I have it but I would like to not get that warning) * If I setup accesslog, do I need to setup a different accesslog DIT for each target DIT I replicate? Or can a single accesslog be shared with 2 different target DITs? I mean: I'm currently replicating both cn=config (dynamic configuration) and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a different accesslog DIT for each one or can they share the same DIT as accesslog ? * Does this log DIT needs to be backup up or is simply a log which I could get rid of in case of recovery? Any comments, hints or simply answers are welcome Thanks

2 3

LMDB cursor position
by M Gurschi 03 Feb '24

03 Feb '24

Hello team, Can you please let me know, when using *mdb_cursor_get* with *MDB_SET* operation, in case the key is not present in the db, where is the cursor left pointing? My scenario is that i want to retrieve two adjacent keys. 1. first *mdb_cursor_get* with *MDB_SET* 2. after that, *mdb_cursor_get* with *MDB_NEXT* I'm wondering what can i expect the cursor to point at in case the key is not found in step 1. Kind Regards, Maxim Gurschi

2 7

otp vs totp
by Quanah Gibson-Mount 02 Feb '24

02 Feb '24

--On Thursday, February 1, 2024 10:55 AM +0100 Bastian Tweddell <b.tweddell(a)fz-juelich.de> wrote: > The reason was, that we use it as a TOTP-only solution. > I had a testsetup with slapo-otp as well, but this module required > userPassword + TOTP, IIRC; where we cannot not have userPassword. > > Our setup is to use TOTP as 2FA for ssh logins against the centralized > LDAP infrstructure. The ssh-login 1FA is ssh pubkey (also in LDAP) and > 2FA is TOTP. To achieve this we use a PAM module which does an ldapbind > against the user-DN which has the userPassword schema '{TOTP1}'. > > Maybe I wrong or outdated here and slapo-opt also supports TOTP-only > authentication now? After discussion in today's project team meeting, we've opened an issue to have this supported by slapo-otp in the future: <https://bugs.openldap.org/show_bug.cgi?id=10169> If you follow that bug, once a solution is in, we'd always welcome testing of it. :) Regards, Quanah

2 1

Plans for the next LTS release?
by Sergio Durigan Junior 01 Feb '24

01 Feb '24

Hi there, Two years ago I sent an announcement mentioning that the OpenLDAP 2.5.x series was accepted for a Micro Release Exception in Ubuntu Jammy (20.04). This meant that I'd be able to release any updates to the 2.5.x series on Jammy, which I have been doing since then. We are now getting ready to work on the next Ubuntu LTS release, which will come out next April. I seem to remember upstream discussions mentioning that the next OpenLDAP LTS release would likely be the 2.7.x series, but I don't remember seeing anything else about it. Are there any plans to start working on the OpenLDAP LTS major series? Thanks a lot, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14

3 5

UNKNOWN attributeDescription "..." inserted.
by Bastian Tweddell 01 Feb '24

01 Feb '24

Dear all, We are facing 'UNKNOWN attributeDescription' errors in our infrastructure, caused by two different reasons. I realized those only by using `slapcat` which prints the following error/warning message to STDERR: ``` UNKNOWN attributeDescription "..." inserted. ``` In both cases, this issue does not degrade the production of our system. All operations including syncreplication are working in normal parameter. Case A: In our production, a dedicated slapd syncrepl consumer has the totp module from contrib enabled and ldapbind calls against '{TOTP1}' are performed. This module introduces a new attribute "authTimestamp". IIUC, `slapcat` cannot know about this attribute, because it is not in the config. But attributes of that type are stored in the MDB. I'd like to ask: - How should we deal with this situation? - Is it safe to continue as is or should we define the attribute "authTimestamp" in our schema extension as well? Case B: We are about to remove some attribute definitions from our schema extension. These are obsolete and not in use in the DB anymore. On the testbed slapd+syncrepl works as expected. But here as well, even though that the DB does not contain any of the obsolete attributes in any entry, `slapcat` throws the same error/warning for all removed attributes from the schema file. My first approach was to re-index the database (even with truncate mode), which did not solve the situation. Stopping the consumer slapd, removing the mdb files and restarting the syncrepl solves it. But on production I would not want to do re-sync everything unnecessarily (it would be possible though). I'd like to ask here: - Is there a way to cleanup MDB from obsolete attributes? - Where/how are those attributes referenced in MDB? - Would it harm to ignore those errors? - Is the removal of attribute definitions from the schema not supported/suggested at all? Btw, we are running slapd 2.6.3 with mdb backend. (Upgrade to 2.6.7 is in planning now). During the composition of this mail, further issues came up with slapd-totp and I would like to add some follow-up questions here. If you prefer, I'll write another mail or I could open an issue on bugzilla. 1. By reading some code in slapd-totp.c I recognized that the introduced attribute authTimestamp is SINGLE-VALUE. But slapcat reveals that entries have multiple values of authTimestamp. This sounds not correct to me. 2. In slapd-totp.c: line 856 and 873 both call `ch_calloc` for the same structm, shadowing the same pointer. This looks like a memory leak to me, because also only one free is called. (I might be wrong though). Many thanks in advance, -- Bastian Tweddell Juelich Supercomputing Centre phone: +49 (2461) 61-6586 High Performance Systems --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens --------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------

3 6

Upgrade Openldap software from 2.4 to 2.6
by kalybox2020＠gmail.com 24 Jan '24

24 Jan '24

Hello, I would like to upgrade the openldap software from 2.4 to 2.6 version. Can you please describe the high level steps involved? Is it going to be in place upgrade? Or we need to install a new 2.6 instance and export the data from old 2.4 and import into 2.4? Pleas elet me know -Kaly

3 2

Performance tuning in Openldap 2.4
by kalybox2020＠gmail.com 24 Jan '24

24 Jan '24

Hello Team, What are the various Tuning parameters that we should look at for performance tuning Openldap 2.4? 1. Indexing (See logs and find out if any unindexed searches, and index them as needed) 2. DB_CONFIG tuning various parameters such as cachesize etc Anything else, please let me know. Thank you -Kaly

2 1

How to check the version of openldap running
by kalybox2020＠gmail.com 22 Jan '24

22 Jan '24

How to check the current openldap version software running? I am told its 2.4. But is there a command to validate? Thank you -Kaly

3 3

olcDbMultival configuration
by david.gracjan＠gmail.com 22 Jan '24

22 Jan '24

Hello, As part of a project, we'd like to know how to integrate olcDbMultival into an existing and running configuration. Can this configuration be done while running ? Is it necessary to restart the directories after integration? Is it necessary to rebuild the primary database? In what order should we proceed? And the same question if we want to remove this attribute from a configuration. Thanks in advance

2 1

etime calculation
by david.gracjan＠gmail.com 22 Jan '24

22 Jan '24

Hello, As part of a project we'd like to know exactly how etime is calculated in openldap. Is it purely the calculation time taken by openldap to execute the request, or are other parameters also taken into account? Like client time? For exemple, in local with a specific filter i do the search in 1 second and the etime in my logs are 1 second. Now i have a client who do the same search with the same filter and he perferm the search in 27 second and the etime in my log are 27 second too. Does the transfer time count? Does anything else count? Thanks in advance

2 1

RE25 testing call (2.5.17) #1
by Quanah Gibson-Mount 21 Jan '24

21 Jan '24

This is the first testing call for OpenLDAP 2.5.17. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.17 Engineering Fixed liblber missing newline on long msg (ITS#10105) Fixed libldap exit handling with OpenSSL3 (ITS#9952) Fixed libldap with TLS and multiple ldap URIs (ITS#10101) Fixed libldap OpenSSL cipher suite handling (ITS#10094) Fixed libldap OpenSSL 3.0 and Diffie-Hellman param files (ITS#10124) Fixed libldap timestamps on Windows (ITS#10100) Fixed lloadd to work when resolv.conf is missing (ITS#10070) Fixed lloadd handling of closing connection (ITS#10083) Fixed slapd handling of regex testing in ACLs (ITS#10089) Fixed slapd-asyncmeta when remote suffix is empty (ITS#10076) Fixed slapo-dynlist so it can't be global (ITS#10091) Build Fixed lloadd type mismatches (ITS#10074) Fixed builds for Windows (ITS#10117) Fixed build with clang16 (ITS#10123 Documentation Fixed slapo-homedir(5) attribute name for olcHomedirArchivePath (ITS#10057) Minor Cleanup ITS#10059 ITS#10068 ITS#10109 ITS#10110 ITS#10129 ITS#10130 ITS#10135 ITS#10144 ITS#10145 ITS#10153 Regards, Quanah

4 5

RE26 testing call (2.6.7) #1
by Quanah Gibson-Mount 19 Jan '24

19 Jan '24

This is the first testing call for OpenLDAP 2.6.7. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.7 Engineering Fixed liblber missing newline on long msg (ITS#10105) Fixed libldap exit handling with OpenSSL3 (ITS#9952) Fixed libldap with TLS and multiple ldap URIs (ITS#10101) Fixed libldap OpenSSL cipher suite handling (ITS#10094) Fixed libldap OpenSSL 3.0 and Diffie-Hellman param files (ITS#10124) Fixed libldap timestamps on Windows (ITS#10100) Fixed lloadd to work when resolv.conf is missing (ITS#10070) Fixed lloadd handling of closing connection (ITS#10083) Fixed lloadd tiers to be correctly linked on startup (ITS#10142) Fixed slapd handling of regex testing in ACLs (ITS#10089) Fixed slapd sync replication with glued database (ITS#10080) Fixed slapd local logging on Windows (ITS#10092) Fixed slapd-asyncmeta when remote suffix is empty (ITS#10076) Fixed slapo-dynlist so it can't be global (ITS#10091) Build Fixed lloadd type mismatches (ITS#10074) Fixed builds for Windows (ITS#10117) Fixed build with clang16 (ITS#10123) Documentation Fixed slapo-homedir(5) attribute name for olcHomedirArchivePath (ITS#10057) Minor Cleanup ITS#10059 ITS#10068 ITS#10098 ITS#10109 ITS#10110 ITS#10129 ITS#10130 ITS#10135 ITS#10143 ITS#10144 ITS#10145 ITS#10153 Regards, Quanah

1 1

RE: openldap-technical mailing list probe message
by Marc 19 Jan '24

19 Jan '24

Any one else getting ~20 messages? > -----Original Message----- > From: openldap-technical- > bounces+c0b8b5a8faa7db954b532a84b16686b22acfeaee(a)openldap.org <openldap- > technical-bounces+c0b8b5a8faa7db954b532a84b16686b22acfeaee(a)openldap.org> > Sent: Friday, 19 January 2024 04:19 > To: Marc > Subject: openldap-technical mailing list probe message > > This is a probe message. You can ignore this message. > > The openldap-technical(a)openldap.org mailing list has received a number > of bounces from you, indicating that there may be a problem delivering > messages to xxxxx. A sample is attached below. > Please examine this message to make sure there are no problems with > your email address. You may want to check with your mail > administrator for more help. > > You don't need to do anything to remain an enabled member of the > mailing list. > > If you have any questions or problems, you can contact the mailing > list owner at > > openldap-technical-owner(a)openldap.org

4 4

Re: libldap with openssl
by dextá 11 Jan '24

11 Jan '24

Quanah, Regarding ltb, which package contains libldap? [ ] openldap-ltb-contrib-overlays_2.5.15.1_amd64.deb 2023-07-11 17:40 405K [ ] openldap-ltb-contrib-overlays_2.5.16.1_amd64.deb 2023-08-22 18:27 405K [ ] openldap-ltb-dbg_2.5.15.1_amd64.deb 2023-07-11 17:40 2.2M [ ] openldap-ltb-dbg_2.5.16.1_amd64.deb 2023-08-22 18:27 2.2M [ ] openldap-ltb-explockout_2.5.15.1_amd64.deb 2023-07-11 17:40 32K [ ] openldap-ltb-explockout_2.5.16.1_amd64.deb 2023-08-22 18:27 32K [ ] openldap-ltb-mdb-utils_2.5.15.1_amd64.deb 2023-07-11 17:40 53K [ ] openldap-ltb-mdb-utils_2.5.16.1_amd64.deb 2023-08-22 18:27 53K [ ] openldap-ltb_2.5.15.1_amd64.deb 2023-07-11 17:40 1.6M [ ] openldap-ltb_2.5.16.1_amd64.deb 2023-08-22 18:27 1.6M and Symas? https://repo.symas.com/repo/deb/main/release25/pool/main/s/symas-openldap/ Em qua., 10 de jan. de 2024 às 16:21, Quanah Gibson-Mount < quanah(a)fast-mail.org> escreveu: > > > --On Wednesday, January 10, 2024 4:01 PM -0300 dextá > <dexter7bbot(a)gmail.com> wrote: > > > > > hello, thanks for the answers!! > > > > @quanah, Is it possible to install only libldap with openssl and not the > > whole of openldap? > > I know the Symas packages provide libldap separately from the server > package. I believe the LTB project does as well. > > Regards, > Quanah > > > >

3 2

libldap with openssl
by dextá 10 Jan '24

10 Jan '24

Hello, Is there a way to compile only the libldap with OpenSSL? I ask because I have installed on Debian 12 a version that uses GnuTLS, and I need to change it to OpenSSL. Regards, Dextá

3 3

Re: libldap with openssl
by dextá 10 Jan '24

10 Jan '24

Nice Quanah!!! I installed the above package, configured the path of the new lib via ldconfig and it worked. I needed it to be compatible with freeradius. Thanks for the help!!! Em qua., 10 de jan. de 2024 às 16:57, Quanah Gibson-Mount < quanah(a)fast-mail.org> escreveu: > > > --On Wednesday, January 10, 2024 4:38 PM -0300 dextá > <dexter7bbot(a)gmail.com> wrote: > > > > > Quanah, > > > > > > Regarding ltb, which package contains libldap? > > > Ok looks like LTB project doesn't separate it out. > > > > > and Symas? > > > https://repo.symas.com/repo/deb/main/release25/pool/main/s/symas-openldap/ > > Pretty apparent: > > symas-openldap-lib > > --Quanah > > > >

1 0

Re: libldap with openssl
by dextá 10 Jan '24

10 Jan '24

hello, thanks for the answers!! @quanah, Is it possible to install only libldap with openssl and not the whole of openldap? Em qua., 10 de jan. de 2024 às 15:50, Quanah Gibson-Mount < quanah(a)fast-mail.org> escreveu: > > > --On Wednesday, January 10, 2024 2:22 PM -0300 Lucas Castro > <lucas(a)gnuabordo.com.br> wrote: > > > > > Em 10/01/2024 13:59, dextá escreveu: > >> Hello, > >> > >> Is there a way to compile only the libldap with OpenSSL? I ask because > >> I have installed on Debian 12 a version that uses GnuTLS, and I need > >> to change it to OpenSSL. > > > > Hello Dexter, > > > > Debian openldap is already build against openSSL. Guess there's some > > other package on your debian that require GnuTLS installed. > > > > But openldap is really build against openSSL. > > This is incorrect. The OpenLDAP shipped by Debian is built against > GnuTLS, > not OpenSSL. If an OpenSSL linked version of OpenLDAP for Debian is > desired, I would suggest using the packages from Symas or the LTB project. > > > <https://repo.symas.com/> > <https://www.ltb-project.org/download.html> > > Regards, > Quanah > >

2 1

Modify default port 389 to custom port 11389 for openldap-servers
by Kaushal Shriyan 10 Jan '24

10 Jan '24

Hi, I am running OpenLdap server 2.4.59 on Red Hat Enterprise Linux release 8.8 (Ootpa) OS in standalone mode without any replication. # rpm -qa | grep openldap symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # # cat modify.ldif dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcDbURI olcDbURI: ldap://127.0.0.1:11389/ # ldapmodify -x -D "cn=admin,dc=corporate,dc=example,dc=in" -W -f modify.ldif Enter LDAP Password: modifying entry "olcDatabase={2}mdb,cn=config" ldap_modify: Undefined attribute type (17) * additional info: olcDbURI: attribute type undefined* # Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Backup and restore OpenLdap server 2.4.59.
by Kaushal Shriyan 10 Jan '24

10 Jan '24

Hi, I am running OpenLdap server 2.4.59 on Red Hat Enterprise Linux release 8.8 (Ootpa) OS in standalone mode without any replication. # rpm -qa | grep openldap symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # As per this https://repo.symas.com/, I see 2.5 LTS and 2.6 current feature release, I am not sure which one I need to upgrade from 2.4 → 2.5 or 2.6? Also, is there a way to back up and restore OpenLdap server 2.4.59? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Scaling slapd nodes in Kubernetes with the MDB Backend
by Alejandro Imass 05 Jan '24

05 Jan '24

Hi there! We are working on a new installation and decided to try something new.. In the past I would have gone with multi-master with ldap balancer but after reading and researching more and more on MDB, we decided to try to integrate OpenLDAP into our current CI/CD pipelines using K8s. What we tried so far and it seems to work is initialize a common persistence storage and then an auto scaling group that shares that common drive. Ech pod has as many threads as virtual CPU it may have, and none of the pods can write, except a dedicated write pod (single instance) with multiple threads for writing. Is there anything else we are missing here? Any experience scaling OpenLDAP with Kubernetes or other container technology. Thank you in advance for any comments, pointers or recommendations! -- Alex

3 4

Symas repos for Debian 12
by Uwe Sauter 05 Jan '24

05 Jan '24

Dear Symas team, Happy new year! Whenever there are issues with distribution provided packages you are promoting your own repositories at https://repo.symas.com . I was wondering if there are any plans to provide an OpenLDAP 2.6 repo for Debian 12 Bookworm? I understand that you save the effort for OpenLDAP 2.5 as it being the version Debian 12 supplies. Thank you for all the work you put into OpenLDAP, Uwe

3 2

Enable multi master replication for OpenLDAP server running in standalone mode.
by Kaushal Shriyan 29 Dec '23

29 Dec '23

Hi, I am running OpenLdap server 2.4.59 on Red Hat Enterprise Linux release 8.8 (Ootpa) OS in standalone mode without any replication. # rpm -qa | grep openldap symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # Is there a way to enable multi master replication for OpenLDAP server, which is currently servicing clients in Production environment? Please guide me. Thanks in advance. Best Regards, Kaushal

2 2

Most efficient way to update multivalued attributes
by Frédéric Goudal 20 Dec '23

20 Dec '23

Hello, I have to update records with mutlivalued attributes, and I wonder what is the best (fastest, or lighter for the server) to do : - either just set the value with the new list - or calculate which values to add and which to delete and than do the add and remove operations. And to be a bit more precise, if we have a big number of values is one of the two way best ? Thanks in advance f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 2

Trying to get dynlist overlay to work
by Christoph Pleger 20 Dec '23

20 Dec '23

Hello, I am using OpenLDAP 2.5.13 from Debian and want to use the dynamic list overlay for replacing the memberOf overlay, but I cannot get it to work. As I read in several places, I first imported dyngroup.ldif, then created an ldif to load the dynlist module and the dynlist schema, like this: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: dynlist dn: olcOverlay=dynlist,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: groupOfURLs memberURL member Then, I created a group with this ldif: dn: cn=Group1,ou=groups,dc=cs,dc=tu-dortmund,dc=de objectClass: groupOfURLs cn: Group1 memberURL: ldap:///dc=cs,dc=tu-dortmund,dc=de??sub?(employeeType=IT) But though some of the users have employeeType=IT, I cannot get a user attribute memberOf or alike that says that, for example ITuser1 is a member of Group1 . So, I tried another approach with dynlist that I read elsewhere: dn: olcOverlay=dynlist,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {1}dynlist olcDlAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames But with this, I got an error message that memberOf@groupOfNames is unknown. So, I have some questions: 1. Does dynlist work this way only in OpenLDAP 2.6? 2. If no, do I have to import additional overlay ldifs? 3. Do I have to load additional modules other than dynlist? 4. Do I have to set other overlay attributes for the dynlist overlay? Regards Christoph

2 6

SSL certificate install
by Jean-Luc Chandezon 15 Dec '23

15 Dec '23

Hello dear community, I'm trying to enable LDAPS. I don't understanrd what is cause error. Is anybody have an idea please? OpenLDAP is 2.5.13, on Debian 12. Here is our certificate chain definition: dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/LEXP_Infra_CA1.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/annuaire.lexp.fr.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/annuaire.lexp.fr.pem - Request is: root@bea-chicago:/etc# ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/01-SSL.ldif Result: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80) Here are slapd logs: cago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.094605+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.094773+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.094922+01:00 bea-chicago slapd[63531]: slap_listener_activate(10): 2023-12-13T08:30:42.095070+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.095216+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.095352+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 busy 2023-12-13T08:30:42.095489+01:00 bea-chicago slapd[63531]: >>> slap_listener(ldapi:///) 2023-12-13T08:30:42.095658+01:00 bea-chicago slapd[63531]: daemon: accept() = 12 2023-12-13T08:30:42.095790+01:00 bea-chicago slapd[63531]: daemon: listen=10, new connection on 12 2023-12-13T08:30:42.095927+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.096046+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.096165+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.096284+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.096424+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.096545+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.096701+01:00 bea-chicago slapd[63531]: daemon: added 12r (active) listener=(nil) 2023-12-13T08:30:42.096832+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.096981+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.097099+01:00 bea-chicago slapd[63531]: 12r 2023-12-13T08:30:42.097227+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.097335+01:00 bea-chicago slapd[63531]: daemon: read active on 12 2023-12-13T08:30:42.097503+01:00 bea-chicago slapd[63531]: conn=1001 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) 2023-12-13T08:30:42.097727+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.097845+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.098084+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.098282+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.098501+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.098688+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.098848+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.099006+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.099205+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.099396+01:00 bea-chicago slapd[63531]: connection_get(12) 2023-12-13T08:30:42.099620+01:00 bea-chicago slapd[63531]: connection_get(12): got connid=1001 2023-12-13T08:30:42.099824+01:00 bea-chicago slapd[63531]: connection_read(12): checking for input on id=1001 2023-12-13T08:30:42.100038+01:00 bea-chicago slapd[63531]: op tag 0x60, time 1702452642 2023-12-13T08:30:42.100268+01:00 bea-chicago slapd[63531]: conn=1001 op=0 do_bind 2023-12-13T08:30:42.100499+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.100687+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.100882+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.101076+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.101292+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.101503+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.101781+01:00 bea-chicago slapd[63531]: >>> dnPrettyNormal: <> 2023-12-13T08:30:42.102002+01:00 bea-chicago slapd[63531]: <<< dnPrettyNormal: <>, <> 2023-12-13T08:30:42.102205+01:00 bea-chicago slapd[63531]: conn=1001 op=0 BIND dn="" method=163 2023-12-13T08:30:42.102431+01:00 bea-chicago slapd[63531]: do_bind: dn () SASL mech EXTERNAL 2023-12-13T08:30:42.102525+01:00 bea-chicago slapd[63531]: ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 2023-12-13T08:30:42.102620+01:00 bea-chicago slapd[63531]: SASL Canonicalize [conn=1001]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.102709+01:00 bea-chicago slapd[63531]: slap_sasl_getdn: conn 1001 id=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [len=55] 2023-12-13T08:30:42.102817+01:00 bea-chicago slapd[63531]: ==>slap_sasl2dn: converting SASL name gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN 2023-12-13T08:30:42.102908+01:00 bea-chicago slapd[63531]: <==slap_sasl2dn: Converted SASL name to <nothing> 2023-12-13T08:30:42.103004+01:00 bea-chicago slapd[63531]: SASL Canonicalize [conn=1001]: slapAuthcDN="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.103121+01:00 bea-chicago slapd[63531]: SASL proxy authorize [conn=1001]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.103220+01:00 bea-chicago slapd[63531]: conn=1001 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 2023-12-13T08:30:42.103322+01:00 bea-chicago slapd[63531]: SASL Authorize [conn=1001]: proxy authorization allowed authzDN="" 2023-12-13T08:30:42.103421+01:00 bea-chicago slapd[63531]: send_ldap_sasl: err=0 len=-1 2023-12-13T08:30:42.103527+01:00 bea-chicago slapd[63531]: conn=1001 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL bind_ssf=0 ssf=71 2023-12-13T08:30:42.103619+01:00 bea-chicago slapd[63531]: do_bind: SASL/EXTERNAL bind: dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" bind_ssf=0 2023-12-13T08:30:42.103713+01:00 bea-chicago slapd[63531]: send_ldap_response: msgid=1 tag=97 err=0 2023-12-13T08:30:42.103804+01:00 bea-chicago slapd[63531]: conn=1001 op=0 RESULT tag=97 err=0 qtime=0.000061 etime=0.000517 text= 2023-12-13T08:30:42.103913+01:00 bea-chicago slapd[63531]: <== slap_sasl_bind: rc=0 2023-12-13T08:30:42.104010+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.104102+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.104185+01:00 bea-chicago slapd[63531]: 12r 2023-12-13T08:30:42.104268+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.104352+01:00 bea-chicago slapd[63531]: daemon: read active on 12 2023-12-13T08:30:42.104435+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.104518+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.104600+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.104683+01:00 bea-chicago slapd[63531]: connection_get(12) 2023-12-13T08:30:42.104766+01:00 bea-chicago slapd[63531]: connection_get(12): got connid=1001 2023-12-13T08:30:42.104851+01:00 bea-chicago slapd[63531]: connection_read(12): checking for input on id=1001 2023-12-13T08:30:42.104941+01:00 bea-chicago slapd[63531]: op tag 0x66, time 1702452642 2023-12-13T08:30:42.105037+01:00 bea-chicago slapd[63531]: conn=1001 op=1 do_modify 2023-12-13T08:30:42.105129+01:00 bea-chicago slapd[63531]: conn=1001 op=1 do_modify: dn (cn=config) 2023-12-13T08:30:42.105223+01:00 bea-chicago slapd[63531]: >>> dnPrettyNormal: <cn=config> 2023-12-13T08:30:42.105316+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor 2023-12-13T08:30:42.105401+01:00 bea-chicago slapd[63531]: daemon: activity on: 2023-12-13T08:30:42.105486+01:00 bea-chicago slapd[63531]: 2023-12-13T08:30:42.105587+01:00 bea-chicago slapd[63531]: <<< dnPrettyNormal: <cn=config>, <cn=config> 2023-12-13T08:30:42.105675+01:00 bea-chicago slapd[63531]: conn=1001 op=1 modifications: 2023-12-13T08:30:42.105770+01:00 bea-chicago slapd[63531]: #011add: olcTLSCACertificateFile 2023-12-13T08:30:42.105862+01:00 bea-chicago slapd[63531]: #011#011one value, length 33 2023-12-13T08:30:42.105951+01:00 bea-chicago slapd[63531]: #011add: olcTLSCertificateKeyFile 2023-12-13T08:30:42.106034+01:00 bea-chicago slapd[63531]: #011#011one value, length 37 2023-12-13T08:30:42.106124+01:00 bea-chicago slapd[63531]: #011add: olcTLSCertificateFile 2023-12-13T08:30:42.106219+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=8 active_threads=0 tvp=zero 2023-12-13T08:30:42.106303+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=9 active_threads=0 tvp=zero 2023-12-13T08:30:42.106387+01:00 bea-chicago slapd[63531]: daemon: epoll: listen=10 active_threads=0 tvp=zero 2023-12-13T08:30:42.106469+01:00 bea-chicago slapd[63531]: #011#011one value, length 35 2023-12-13T08:30:42.106557+01:00 bea-chicago slapd[63531]: conn=1001 op=1 MOD dn="cn=config" 2023-12-13T08:30:42.106644+01:00 bea-chicago slapd[63531]: conn=1001 op=1 MOD attr=olcTLSCACertificateFile olcTLSCertificateKeyFile olcTLSCertificateFile 2023-12-13T08:30:42.106737+01:00 bea-chicago slapd[63531]: => access_allowed: result not in cache (olcTLSCACertificateFile) 2023-12-13T08:30:42.106823+01:00 bea-chicago slapd[63531]: => access_allowed: add access to "cn=config" "olcTLSCACertificateFile" requested 2023-12-13T08:30:42.106918+01:00 bea-chicago slapd[63531]: => acl_get: [1] attr olcTLSCACertificateFile 2023-12-13T08:30:42.107007+01:00 bea-chicago slapd[63531]: => acl_mask: access to entry "cn=config", attr "olcTLSCACertificateFile" requested 2023-12-13T08:30:42.107095+01:00 bea-chicago slapd[63531]: => acl_mask: to value by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0) 2023-12-13T08:30:42.107182+01:00 bea-chicago slapd[63531]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 2023-12-13T08:30:42.107283+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] applying manage(=mwrscxd) (stop) 2023-12-13T08:30:42.107374+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] mask: manage(=mwrscxd) 2023-12-13T08:30:42.107457+01:00 bea-chicago slapd[63531]: => slap_access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.107543+01:00 bea-chicago slapd[63531]: => access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.107636+01:00 bea-chicago slapd[63531]: => access_allowed: result not in cache (olcTLSCertificateKeyFile) 2023-12-13T08:30:42.107724+01:00 bea-chicago slapd[63531]: => access_allowed: add access to "cn=config" "olcTLSCertificateKeyFile" requested 2023-12-13T08:30:42.107812+01:00 bea-chicago slapd[63531]: => acl_get: [1] attr olcTLSCertificateKeyFile 2023-12-13T08:30:42.107898+01:00 bea-chicago slapd[63531]: => acl_mask: access to entry "cn=config", attr "olcTLSCertificateKeyFile" requested 2023-12-13T08:30:42.107992+01:00 bea-chicago slapd[63531]: => acl_mask: to value by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0) 2023-12-13T08:30:42.108074+01:00 bea-chicago slapd[63531]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 2023-12-13T08:30:42.108157+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] applying manage(=mwrscxd) (stop) 2023-12-13T08:30:42.108240+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] mask: manage(=mwrscxd) 2023-12-13T08:30:42.108323+01:00 bea-chicago slapd[63531]: => slap_access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.108398+01:00 bea-chicago slapd[63531]: => access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.108494+01:00 bea-chicago slapd[63531]: => access_allowed: result not in cache (olcTLSCertificateFile) 2023-12-13T08:30:42.108589+01:00 bea-chicago slapd[63531]: => access_allowed: add access to "cn=config" "olcTLSCertificateFile" requested 2023-12-13T08:30:42.108678+01:00 bea-chicago slapd[63531]: => acl_get: [1] attr olcTLSCertificateFile 2023-12-13T08:30:42.108762+01:00 bea-chicago slapd[63531]: => acl_mask: access to entry "cn=config", attr "olcTLSCertificateFile" requested 2023-12-13T08:30:42.108852+01:00 bea-chicago slapd[63531]: => acl_mask: to value by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0) 2023-12-13T08:30:42.108936+01:00 bea-chicago slapd[63531]: <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 2023-12-13T08:30:42.109014+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] applying manage(=mwrscxd) (stop) 2023-12-13T08:30:42.109090+01:00 bea-chicago slapd[63531]: <= acl_mask: [1] mask: manage(=mwrscxd) 2023-12-13T08:30:42.109172+01:00 bea-chicago slapd[63531]: => slap_access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.109253+01:00 bea-chicago slapd[63531]: => access_allowed: add access granted by manage(=mwrscxd) 2023-12-13T08:30:42.109337+01:00 bea-chicago slapd[63531]: slap_get_csn: conn=1001 op=1 generated new csn=20231213073042.095886Z#000000#000#000000 manage=1 2023-12-13T08:30:42.109424+01:00 bea-chicago slapd[63531]: slap_queue_csn: queueing 0x7f57dc000ce0 20231213073042.095886Z#000000#000#000000 2023-12-13T08:30:42.109535+01:00 bea-chicago slapd[63531]: oc_check_required entry (cn=config), objectClass "olcGlobal" 2023-12-13T08:30:42.109647+01:00 bea-chicago slapd[63531]: oc_check_allowed type "objectClass" 2023-12-13T08:30:42.109739+01:00 bea-chicago slapd[63531]: oc_check_allowed type "cn" 2023-12-13T08:30:42.109829+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcArgsFile" 2023-12-13T08:30:42.109917+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcLogLevel" 2023-12-13T08:30:42.110080+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcPidFile" 2023-12-13T08:30:42.110173+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcToolThreads" 2023-12-13T08:30:42.110266+01:00 bea-chicago slapd[63531]: oc_check_allowed type "structuralObjectClass" 2023-12-13T08:30:42.110367+01:00 bea-chicago slapd[63531]: oc_check_allowed type "entryUUID" 2023-12-13T08:30:42.110464+01:00 bea-chicago slapd[63531]: oc_check_allowed type "creatorsName" 2023-12-13T08:30:42.110541+01:00 bea-chicago slapd[63531]: oc_check_allowed type "createTimestamp" 2023-12-13T08:30:42.110617+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcTLSCACertificateFile" 2023-12-13T08:30:42.110707+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcTLSCertificateKeyFile" 2023-12-13T08:30:42.110793+01:00 bea-chicago slapd[63531]: oc_check_allowed type "olcTLSCertificateFile" 2023-12-13T08:30:42.110875+01:00 bea-chicago slapd[63531]: oc_check_allowed type "entryCSN" 2023-12-13T08:30:42.110972+01:00 bea-chicago slapd[63531]: oc_check_allowed type "modifiersName" 2023-12-13T08:30:42.111058+01:00 bea-chicago slapd[63531]: oc_check_allowed type "modifyTimestamp" 2023-12-13T08:30:42.111144+01:00 bea-chicago slapd[63531]: send_ldap_result: conn=1001 op=1 p=3 2023-12-13T08:30:42.111233+01:00 bea-chicago slapd[63531]: send_ldap_result: err=80 matched="" text="" 2023-12-13T08:30:42.111321+01:00 bea-chicago slapd[63531]: send_ldap_response: msgid=2 tag=103 err=80 2023-12-13T08:30:42.111407+01:00 bea-chicago slapd[63531]: conn=1001 op=1 RESULT tag=103 err=80 qtime=0.000070 etime=0.002380 text= 2023-12-13T08:30:42.111498+01:00 bea-chicago slapd[63531]: slap_graduate_commit_csn: removing 0x7f57dc000ce0 20231213073042.095886Z#000000#000#000000 2023-12-13T08:30:42.111590+01:00 bea-chicago slapd[63531]: daemon: activity on 1 descriptor Best regards, Jean-Luc

5 8

superuser and normal user in OpenLdap services
by Kaushal Shriyan 13 Dec '23

13 Dec '23

Hi, I am running the openldap server on Red Hat Enterprise Linux release 8.8 (Ootpa) # rpm -qa | grep -i ldap sssd-ldap-2.8.2-3.el8_8.x86_64 symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # Do we have root and normal user privileges in OpenLDAP service as similar to Linux OS? For example, if I have to reset cn=admin password, do we need to use root or something? I am a little confused. Are there superuser concept in OpenLDAP? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

lloadd and cn=config
by Stefan Kania 11 Dec '23

11 Dec '23

Hi to all, when I setup the loadbalancer lloadd via slapd.conf everything is working fine. Here my slapd.conf ----------------- TLSCertificateFile /opt/symas/etc/openldap/example-net-cert.pem TLSCertificateKeyFile /opt/symas/etc/openldap/example-net-key.pem TLSCACertificateFile /opt/symas/etc/openldap/cacert.pem pidfile /var/symas/run/slapd.pid argsfile /var/symas/run/slapd.args loglevel 256 modulepath /opt/symas/lib/openldap moduleload lloadd.la backend lload listen "ldap://:1389 ldaps://:1636" feature proxyauthz TLSShareSlapdCTX true bindconf bindmethod=simple network-timeout=5 binddn=uid=lloadd,ou=users,dc=example,dc=net credentials=geheim tls_cacert="/opt/symas/etc/openldap/cacert.pem" tls_cert="/opt/symas/etc/openldap/example-net-cert.pem" tls_key="/opt/symas/etc/openldap/example-net-key.pem" tier roundrobin backend-server uri=ldaps://provider01.example.net retry=5000 max-pending-ops=50 conn-max-pending=10 numconns=10 bindconns=5 backend-server uri=ldaps://provider02.example.net retry=5000 max-pending-ops=50 conn-max-pending=10 numconns=10 bindconns=5 database monitor rootdn cn=monitor rootpw geheim ----------------- As soon as I change to cn=config with the following configuration: ----------------- dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 olcTLSCACertificateFile: /opt/symas/etc/openldap/cacert.pem olcTLSCertificateFile: /opt/symas/etc/openldap/example-net-cert.pem olcTLSCertificateKeyFile: /opt/symas/etc/openldap/example-net-key.pem dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: lloadd.la olcModuleLoad: argon2.la dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config #olcRootPW: geheim olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage dn: olcBackend={0}lload,cn=config objectClass: olcBackendConfig objectClass: olcBkLloadConfig olcBackend: {0}lload olcBkLloadBindconf: bindmethod=simple timeout=0 network-timeout=5 binddn="uid=lloadd,ou=users,dc=example,dc=net" credentials="geheim" keepalive=0:0:0 tcp-user-timeout=0 tls_cert="/opt/symas/etc/openldap/example-net-cert.pem" tls_key="/opt/symas/etc/openldap/example-net-key.pem" tls_cacert="/opt/symas/etc/openldap/cacert.pem" olcBkLloadIOThreads: 1 olcBkLloadListen: ldap://:1389 olcBkLloadListen: ldaps://:1636 olcBkLloadSockbufMaxClient: 16777215 olcBkLloadSockbufMaxUpstream: 16777215 olcBkLloadMaxPDUPerCycle: 10 olcBkLloadIOTimeout: 10000 olcBkLloadFeature: proxyauthz olcBkLloadTLSCRLCheck: none olcBkLloadVerifyClient: never olcBkLloadTLSProtocolMin: 0.0 olcBkLloadTLSShareSlapdCTX: TRUE olcBkLloadClientMaxPending: 0 olcBkLloadWriteCoherence: 0 dn: cn={0}tier 1,olcBackend={0}lload,cn=config objectClass: olcBkLloadTierConfig cn: {0}tier 1 olcBkLloadTierType: roundrobin dn: cn={0}server 1,cn={0}tier 1,olcBackend={0}lload,cn=config objectClass: olcBkLloadBackendConfig cn: {0}server 1 olcBkLloadBackendUri: ldaps://provider01.example.net olcBkLloadNumconns: 10 olcBkLloadBindconns: 5 olcBkLloadRetry: 5000 olcBkLloadMaxPendingOps: 50 olcBkLloadMaxPendingConns: 10 olcBkLloadStartTLS: critical olcBkLloadWeight: 1 dn: cn={1}server 2,cn={0}tier 1,olcBackend={0}lload,cn=config objectClass: olcBkLloadBackendConfig cn: {1}server 2 olcBkLloadBackendUri: ldaps://provider02.example.net olcBkLloadNumconns: 10 olcBkLloadBindconns: 5 olcBkLloadRetry: 5000 olcBkLloadMaxPendingOps: 50 olcBkLloadMaxPendingConns: 10 olcBkLloadWeight: 1 dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read ----------------- The slapd is stating and with "ss -tlpn" I see port 1636 and 1389 as listen (next to 636 and 389) I git the following errormessage when I try to contect the ldap-server via the loadbalancer. ------------------- ldap_bind: Server is unavailable (52) additional info: no connections available ------------------- Did I miss sommthing? I also try to translate the working slapd.conf with slaptest, but the result is the same. Stefan

3 14

slapd 2.5 forwarding request .. please help
by enrico.becchetti＠gmail.com 09 Dec '23

09 Dec '23

Hi everyone, I have a particular setup and I need your help. I have a Slapd 2.5 running in a debian virtual machine. This ldap server has its own tree, dc=example,dc=com. I need this slapd server to forward the authentication requests for two domains other than its own, for example dc=example2,dc=com towards -> 192.168.1.1 dc=example3,dc=com towards -> 192.168.2.1 I read in the documentation that it is possible to do this forward but I can't modify the configuration using ldapmodify. Can you help me ? Thanks Willy

2 2

ldapsearch and own .ldaprc
by Stefan Kania 05 Dec '23

05 Dec '23

Hi to all, I just started to use my own .ldaprc file in $HOME: ------------- URI ldaps://provider01.example.net ldaps://provider02.example.net BASE dc=example,dc=net BINDDN uid=repl-user,ou=users,dc=example,dc=net TLS_REQCERT demand TLS_CACERT /opt/symas/etc/openldap/cacert.pem ------------- All options are working except "BINDDN". If I use the same user with "-D" it works, so the user is present. I expected that ldapsearch will ask for a password when using "BINDDN" but ldapsearch is executing as anonymous. Did I miss something? If "yes" then what? Stefan

3 8

Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
by Ben Poliakoff 01 Dec '23

01 Dec '23

This is more of a practical question than a technical one, but it's prompted by a technical change: I'm *very* **very** belatedly transitioning from flat file slapd.conf config to slapd.d/OLC. With flat file configuration, it was straightforward to include text comments (e.g. "# blah blah"), but as far as I know there isn't any sort of analog for comments, when using slapd.d. Looking for any tips about how best to annotate slapd configuration, in a slapd.d/olc world. Does anyone have a practice that they find works well for them? Do people just maintain separate documents/wiki pages/etc that describe their servers' configs? Ben

13 15

solaris client ldap-backend to AD and DSE
by Craig H Silva (Cenitex) 30 Nov '23

30 Nov '23

I need to configure openldap as a proxy to AD so that AD can be upgraded to version 2019. Currently using Unix services for Windows, which works to provide nis information to solaris (11) and zfsappliance but it was deprecated after windows 2012. There's still nis info info in various attributes in AD schema, but the nis service is about to go. So an alternative is needed. I have the proxy configured with ldap-backend and its very happy to provide all the attribute information, but the solaris ldap client wants the DSE through the proxy and for the life of me I can't work out what is impeding it. I can "ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base -LLL "+"" on the openldap system and the DSE is returned and I can get the DSE with an ldapsearch from the solaris client if I point directly at the AD ldap server, but if i point solaris at the openldap proxy - nada. This really upsets the ldapclient on solaris - it feels degraded. It feels like its an access issue as I can get a DSE when root on the openldap system. from config: # {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=myorg,dc=lcl olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Schema" by * read olcAccess: {2}to dn.base="cn=Subschema" by * read olcAccess: {3}to * by self read by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbURI: "ldaps://myorgdevad.myorgdev.lcl:636" Any guidance appreciated - logs available on request. Craig Silva | Specialist Engineer – Unix & Storage Services Level 18, 80 Collins Street, Melbourne 3000 (03) 9063 5126 cenitex.vic.gov.au Cenitex acknowledges the Traditional Owners and custodians of the land and we pay our respects to their Elders, past, present and emerging. We are an inclusive workplace that embraces diversity in all its forms. ---------------------------------------------------------------------- Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email.

2 2

Re: Need assistant to Implement and Configure OpenLDAP for users authentication from Multi-Domain
by Quanah Gibson-Mount 28 Nov '23

28 Nov '23

--On Thursday, November 23, 2023 12:21 PM +0000 Sunil Sharma <sunil.sharma(a)mdsglobalit.com> wrote: > • What would be the Best OS for OpenLDAP currently, is it Linux, > CentOS or any other? Generally any current linux distribution with a current openldap release. > • We have users from Multi-Domain where these domains do not have any > trust relationship between each other and we need to authenticate the > users from multi-Domain for UC applications (CUCM, CUC, CER, UCCE, > Expressways and Jabber). > > > > We are looking if we can sync the user database from > these multidomain to a single OpenLDAP server and then from this OpenLDAP > to UC applications using single search base for authentication, is this > possible? Probably? --Quanah

1 0

Access to cn=monitor from read-only ldap
by Kevin Cousin 21 Nov '23

21 Nov '23

Hi List, I've got an LDAP architecture with one read-write OpenLDAP (primary) and some read-only OpenLDAP (replica). I load the cn=monitor backend on the primary? is it sufficient to have the cn=monitor backend on the slave too or should I activate it on the replicas ? Regards, Kevin C

3 2

syncrepl between 2.4.57.0.1 and 2.6.2-3
by Frank, Michael 16 Nov '23

16 Nov '23

Airbus Amber Dear all, basically I trying to establish a syncrepl/refreshAndpersist Setup between: OpenLDAP: 2.4.57.0.1 @ Solaris < - > OpenLDAP: 2.6.2-3 @ Rhel 9.latest (don`t ask) An intial syncrepl activation does works properly (replication of ou`s content in both directions), but when I afterwards restart one of the replication Partners, the sync failes and in consequence on one of replication Partner the ou`s are deleted. From logging point of view there are somekind of issues to identify the remote object via the UUID which leads then to the deletion: ##schnipp 6538d3db.38892890 0x7f9fe65fe640 nonpresent_callback: rid=044 nonpresent UUID 25a0c72c-0364-103e-83af-fb52f2a7ef64, dn ou=permissions,dc=xxx,dc=xxxx,dc=xxxxxx 6538d3db.388983a6 0x7f9fe65fe640 nonpresent_callback: rid=044 adding entry ou=permissions,dc=xxxx,dc=xxxxx,dc=xxxx to non-present list ###schnapp Unfortunately I cannot find any Information which says something useful about the basic backward compatibility of the synrepl/refreshAndPersist implementation from 2.6 to 2.4. Can someone state why this mission is hopeless in detail or should the setup work basically ? (I know the best practice : everywhere same versions...) Best regards and thanks in advance, michael This Item has been reviewed and was determined as not listed under German regulation, nor EU export controls, nor U.S. export controls. However, in the case of the item has to be resold, transferred, or otherwise disposed of to an embargoed country, to an end user of concern or in support of a prohibited end use, you may be required to obtain an export license. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

3 8

"user"/"users" keyword in documentation
by Uwe Sauter 12 Nov '23

12 Nov '23

Hi all, in the ACL chapter of the online documentation to OpenLDAP 2.6 (and likely the versions before) there might be a mismatch of singular/plural usage of the "users" keyword. In chapter 8.3.2 "who to grant access to" table 5.3 lists specifier "users" as "authenticated users" entities. This is further shown in chapter 8.4.2 "matching anonymous and authenticated users". In chapter 8.4.9 "tips for using regular expressions in access control" the singular is used: "Use shorthands. The user directive matches authenticated users and the anonymous directive matches anonymous users." As well as in the subchapters 8.5.x where the singular is used in set definitions. My question now is: does it matter whether singular or plural of user is used in ACLs? If so, where to use one and where to use the other? Does it follow natural language useage? Thanks, Uwe

2 2

Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors
by xiaoya2wei＠gmail.com 09 Nov '23

09 Nov '23

Greetings LMDB Community, I am delving into the thread-safety aspects of LMDB, specifically regarding the use of readonly cursors across multiple threads. With the MDB_NOTLS flag enabled, which disables thread-local storage, my understanding is that readonly transactions may be shared between threads, provided there is proper synchronization to prevent concurrent access. Building upon this, I seek clarity on the following: Can multiple threads safely access a single readonly cursor derived from such a synchronized readonly transaction when MDB_NOTLS is enabled? Upon reviewing the LMDB source code, I noticed that cursors are tied to transactions (see mdb.c#L1335). This suggests that if threads can synchronously share a transaction, they might also share a cursor associated with it for data retrieval. Meanwhile, while looking at the LMDB document (http://www.lmdb.tech/doc/group__mdb.html#gad7ea55da06b77513609efebd44b26920), it says “Cursors may not span transactions”, which is a little confusing for me. To be crystal transparent, does it mean that, even if MDB_NOTLS is set, a cursor opened by a readonly transaction still has to stay with one single thread for its entire lifetime, and cannot be used by another thread even at a different time? Thank you in advance for your assistance! Best, Xiaoya

2 4

Issue with refint and rwm overlay
by Maksim Saroka 07 Nov '23

07 Nov '23

Hello, We have a strange situation with refint and rwm overlays on ldap replica. Looks like those overlays depend on each other and on position in the slapd.conf file regarding database section. However refint overlay is working in any position if rwm overlay is not specified. Here are the examples with positions in the file: Refint overlay work if: 1. rwm overlay section database section refint overlay section Refint overlay does not work if: 1. database section refint overlay section rwm overlay section 2. rwm overlay section refint overlay section database section Could you please explain to us the root cause of that as I can't find any explanation in the docs. -------- Maksim Saroka DevOps/System Administrator Exadel.com <https://exadel.com/> Follow Us on LinkedIn <https://www.linkedin.com/company/exadel/> -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

2 5

email aliases - extended version
by Chris Vogel 01 Nov '23

01 Nov '23

Hi, I moved from a mailserver using exim/mysql to one based on postfix/ldap and found a question I couldn't answer by searching: Is there a way to put "email aliases like I'm used to" into the directory? By "email aliases like I'm used to" I mean 1-m aliases with the following properties: - An email received for an alias address is send to multiple maildrops and/or email addresses Additinally I'd like to add information about ownership/permissions: - An alias has got one or more owner(s) who - are able to edit the list of receivers - are allowed to delete the alias - change permission on it like described below - An alias has properties that describe the permission local receivers have (for all of the local receivers or every single local): - its open to subscription by every uid (user on the system) or only the owners are allowed to add new receivers - delete oneself from the list of receivers - allowed to use the alias address as email sender for emails delivered by the account I know this sounds like mailinglist, but most of that has been possible in exim using files and file permissions or values in a mysql database. A listmanager would add some interface for managing this, but that is not what I'm looking for. I'm looking for an existing standard or quasi-official way on how to represent this in the directory before inventing the wheel a second time. Along my way I stumbled over this two messages on the list which seem to point in a similar direction: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… Thanks for any references or help Chris

2 1

OpenLDAP 2.4 (released October 2007) - Question
by Steffano Festa 01 Nov '23

01 Nov '23

Hi team, Is the OpenLDAP 2.4 (released October 2007) still actively maintained? Or can we consider it as EOL? [cid:image001.png@01DA0CCC.4B603970]

2 1

lastbind not working on consumer since version 2.6.3
by alexjl1＠thenode.info 01 Nov '23

01 Nov '23

Hi, I have a single provider / multiple consumers setup with olcLastBind enabled on all servers but excluding the pwdLastSuccess attribute from syncing, so that the provider and each consumer have their own values. After updating one of the consumers from 2.6.2 to 2.6.3, I noticed that pwdLastSuccess stopped refreshing on new binds. So, on a test machine I installed 2.6.3 and then 2.6.6 and verified that when the server is set to read only or as a simple consumer (no multiprovider), pwdLastSuccess is not modified. Is this a result of the fixes for ITS#9863 in 2.6.3? If this is not a bug, but intended behavior, is there a way to have lastbind work in a simple consumer (without making it writable)?

1 0

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

Re: No matter what I try I get: ldap_modify: Insufficient access (50)
by Alejandro Imass 27 Oct '23

27 Oct '23

On Fri, Oct 27, 2023 at 5:58 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, October 27, 2023 10:51 AM +0200 Alejandro Imass > <aimass(a)yabarana.com> wrote: > > > Again for future people reading this, if you encounter ACL issues and you > > want to modify the LDIF database in /etc/openldap/slapd.d don't do it > > manually. > > Your advice here is generally wrong. > > You mean they SHOULD edit them manually ? I'm actually suggesting to use slapadd and slapmodify directly on the filesystem if everything else fails. What's wrong with that suggestion? >

2 1

No matter what I try I get: ldap_modify: Insufficient access (50)
by Alejandro Imass 27 Oct '23

27 Oct '23

OpenLDAP 2.6.6r1 on Apline Linux aarch64 Not sure what I am doing wrong but I am unable to change the rootDN's password. # ldapmodify -H ldapi:/// -Y EXTERNAL -D 'cn=config' << EOF > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcRootPW > olcRootPW: {SSHA}cZbRoOhRew8MBiWGSEOiFX0XqbAQwXUr > EOF SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={0}config,cn=config" ldap_modify: Insufficient access (50) I also tried remotely, and same thing. I noticed *olcAccess: {0}to * by * none* in the config DB but I didn't put that there, and not sure how to change it. Here is the slapcat output: (Also, at the end I copied the LDIF I use to initialize the LDAP) / # slapcat -n 0 dn: cn=config objectClass: olcGlobal cn: config olcDisallows: bind_anon olcRequires: authc structuralObjectClass: olcGlobal entryUUID: 3ebf1971-b32e-41eb-ac58-a0a30fe18734 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.508761Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/openldap olcModuleLoad: {0}back_mdb.so olcModuleLoad: {1}refint.so olcModuleLoad: {2}memberof.so olcModuleLoad: {3}argon2.so structuralObjectClass: olcModuleList entryUUID: 3b732d07-c664-4294-87ca-d5e29a32aa6c creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.509009Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema structuralObjectClass: olcSchemaConfig entryUUID: c38bf741-8d4a-4e36-b012-22a70577d429 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.509955Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: cn={0}core,cn=schema,cn=config objectClass: olcSchemaConfig cn: {0}core [snip] ... dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcPasswordHash: {ARGON2} structuralObjectClass: olcDatabaseConfig entryUUID: 4459a62b-80f9-449c-b4a6-20cd2108a486 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.512390Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config *olcAccess: {0}to * by * none* olcAddContentAcl: TRUE olcLastMod: TRUE olcLastBind: FALSE olcLastBindPrecision: 0 olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 08d3cdfa-b552-45ab-a183-fc5802e9c910 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.512505Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/openldap/openldap-data olcSuffix: dc=foo,dc=bar olcRootDN: cn=admin,dc=foo,dc=bar olcRootPW:: e0FSR09OMn0kYXJnb24yaSR2PTE5JG09NDA5Nix0PTMscD0xJHVKeWYwVWZCMjVTUV RmWDdvQ3lLMnckVTQ1REpxRUZ3RDB5RmFMdlRWeUFDSEx2R013ek5HZjE5ZHZ6UFI4WHZHYw== olcDbIndex: objectClass eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: 169807ec-3bfc-4a20-b4ab-e60cddd777a2 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.512483Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf structuralObjectClass: olcMemberOfConfig entryUUID: f45b11d4-aba8-40ec-83b5-5688aa6c4c42 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.513061Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {1}refint olcRefintAttribute: memberof olcRefintAttribute: member olcRefintAttribute: uniqueMember olcRefintAttribute: manager olcRefintAttribute: owner olcRefintNothing: cn=admin,dc=foo,dc=bar structuralObjectClass: olcRefintConfig entryUUID: 498d5840-1ebf-43d9-ad16-264069969adc creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.513211Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z dn: olcDatabase={2}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}monitor olcRootDN: cn=config olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 82712ebd-5149-496a-bec8-a2853249d9f3 creatorsName: cn=config createTimestamp: 20231025213204Z entryCSN: 20231025213204.513336Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20231025213204Z Here is the LDIF I am using to initialize the LDAP and populate slapd.d: # config global dn: cn=config objectClass: olcGlobal cn: config #TODO: fine tune security rlevel estrictions #olcSecurity: ssf=1 update_ssf=112 simple_bind=64 olcDisallows: bind_anon olcRequires: authc # dynamic backend modules: dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.so olcModuleLoad: refint.so olcModuleLoad: memberof.so olcModuleload: argon2.so # schemas dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/inetorgperson.ldif include: file:///etc/openldap/schema/nis.ldif include: file:///etc/openldap/schema/dynamodel.ldif # frontend settings dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcPasswordHash: {ARGON2} # LMDB database definitions dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=foo,dc=bar olcRootDN: cn=admin,dc=foo,dc=bar olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$uJyf0UfB25SQTfX7oCyK2w$U45DJqEFwD0yFaLvTVyACHLvGMwzNGf19dvzPR8XvGc olcDbDirectory: /var/lib/openldap/openldap-data olcDbIndex: objectClass eq # memberOf overlay dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf # refint overlay dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {1}refint olcRefintAttribute: memberof olcRefintAttribute: member olcRefintAttribute: uniqueMember olcRefintAttribute: manager olcRefintAttribute: owner olcRefintNothing: cn=admin,dc=foo,dc=bar dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: monitor olcRootDN: cn=config olcMonitoring: FALSE Thank you in advance for any pointers ! -- Alex

3 5

Re: No matter what I try I get: ldap_modify: Insufficient access (50)
by Alejandro Imass 27 Oct '23

27 Oct '23

On Thu, Oct 26, 2023 at 11:13 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thu> Try the following (and replace with the correct URL): > > > > $ ldifmodify -x -H ldap://localhost/ -D cn=config -W << EOF > > > dn: olcDatabase={0}config,cn=config > > > changetype: modify > > > add: olcRootPW > > > olcRootPW: {SSHA}cZbRoOhRew8MBiWGSEOiFX0XqbAQwXUr > > > EOF > > There doesn't appear to be an old olcRootPW value either, so that wouldn't > work. > > Thanks for your response. There actually is one in dn: olcDatabase={1}mdb,cn=config Anyway I solved my issue and was able to modify the config DB using slapadd and slapmodify directly on the filesystem as root and that is that. Thanks again for your help! -- Alex

2 1

Re: Replication issue during performance test with MMR configuration and LastBind enabled
by Quanah Gibson-Mount 26 Oct '23

26 Oct '23

--On Tuesday, October 24, 2023 10:01 AM +0200 Óscar Remírez de Ganuza Satrústegui <oscarrdg(a)unav.edu> wrote: > What architecture would you suggest for implementing lastbind? > Is it better to use a Master-Slave with the chain overlay to send the > lastbind writes from the slave to the master? If you want the value to have general meaning for most deployments, yes. Generally I'd go with Multi-provider replication in a active/passive configuration, with some number of read only consumer nodes, where the read only nodes forward their updates to the active provider. --Quanah

1 0

We cannot connect to TLS/SSL ldaps using openldap's built-in tools
by 228844797＠qq.com 23 Oct '23

23 Oct '23

Hello developers, Can you help me see how to solve this problem We are working with the client that comes with openldap and cannot connect to TLS/SSL ldaps,But I was able to access it using ldap:389 The server configuration information is as follows: Linux System version：Ubuntu 22.04.3 LTS OpenLDAP version：2.6.6 openssl version：OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) The slapd.ldif certificate is configured as follows: olcTLSCACertificateFile: /usr/local/openldap-2.6.6/cert/demoCA/newcerts/cacert.pem olcTLSCertificateFile: /usr/local/openldap-2.6.6/cert/demoCA/newcerts/slapd01-server.pem olcTLSCertificateKeyFile: /usr/local/openldap-2.6.6/cert/demoCA/private/slapd01-server-key.pem The server startup information is as follows: slapd -4 -F /usr/local/openldap-2.6.6/etc/openldap/slapd.d -h ldap:/// ldaps:/// ldapi:/// Configure the ldap.conf certificate on the client as follows: TLS_CACERT /usr/local/openldap-2.6.6/cert/demoCA/newcerts/ ####################################################################################################### Server local test failed: ldapwhoami -H ldaps://slapd.zxactions.com -d 1 The failure information is as follows: root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# ldapwhoami -H ldaps://slapd.zxactions.com -d 1 ldap_url_parse_ext(ldaps://slapd.zxactions.com) ldap_create ldap_url_parse_ext(ldaps://slapd.zxactions.com:636/??base) ldap_pvt_sasl_getmech ldap_search put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP slapd.zxactions.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.174.128:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in error TLS: can't connect: error:0A000410:SSL routines::sslv3 alert handshake failure. ldap_err2string ldap_sasl_interactive_bind: Can't contact LDAP server (-1) additional info: error:0A000410:SSL routines::sslv3 alert handshake failure ####################################################################################################### Failed to use the openssl tool: openssl s_client -connect slapd.zxactions.com:636 -debug The failure information is as follows: root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# openssl s_client -connect slapd.zxactions.com:636 -debug CONNECTED(00000003) write to 0x556ccbdb5c40 [0x556ccbdc5b30] (321 bytes => 321 (0x141)) 0000 - 16 03 01 01 3c 01 00 01-38 03 03 1a eb eb eb ad ....<...8....... 0010 - 52 f0 12 36 b2 cd ad 9c-6f c9 de 67 54 13 e3 47 R..6....o..gT..G 0020 - 23 ac 44 5c d9 51 2f d4-a5 0b cf 20 e6 f9 c1 6c #.D\.Q/.... ...l 0030 - e5 ce 18 9c ea f1 d6 67-a2 1f 71 3c 78 d4 c6 fb .......g..q<x... 0040 - 25 23 98 bd 38 90 1f 8c-13 94 b1 00 00 3e 13 02 %#..8........>.. 0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........ 0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.' 0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3.. 0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 b1 ...=.<.5./...... 0090 - 00 00 00 18 00 16 00 00-13 73 6c 61 70 64 2e 7a .........slapd.z 00a0 - 78 61 63 74 69 6f 6e 73-2e 63 6f 6d 00 0b 00 04 xactions.com.... 00b0 - 03 00 01 02 00 0a 00 16-00 14 00 1d 00 17 00 1e ................ 00c0 - 00 19 00 18 01 00 01 01-01 02 01 03 01 04 00 23 ...............# 00d0 - 00 00 00 16 00 00 00 17-00 00 00 0d 00 2a 00 28 .............*.( 00e0 - 04 03 05 03 06 03 08 07-08 08 08 09 08 0a 08 0b ................ 00f0 - 08 04 08 05 08 06 04 01-05 01 06 01 03 03 03 01 ................ 0100 - 03 02 04 02 05 02 06 02-00 2b 00 05 04 03 04 03 .........+...... 0110 - 03 00 2d 00 02 01 01 00-33 00 26 00 24 00 1d 00 ..-.....3.&.$... 0120 - 20 92 75 81 9c 09 28 95-68 b4 eb b1 9e 2c d5 9b .u...(.h....,.. 0130 - e3 99 13 36 68 87 b5 72-4d d6 3e 60 0f 47 50 db ...6h..rM.>`.GP. 0140 - 15 . read from 0x556ccbdb5c40 [0x556ccbdbc913] (5 bytes => 5 (0x5)) 0000 - 15 03 03 00 02 ..... read from 0x556ccbdb5c40 [0x556ccbdbc918] (2 bytes => 2 (0x2)) 0000 - 02 28 .( 800B77514E7F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1584:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 321 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- read from 0x556ccbdb5c40 [0x556ccbd0d650] (8192 bytes => 0) ************************************************************************************************************************************* I can access it using ldap:389 root@openldap-1:/usr/local/openldap-2.6.6/etc/openldap# ldapsearch -x -D "cn=Manager,dc=my-domain,dc=com" -H ldap://slapd.zxactions.com -w 123456 -b "dc=my-domain,dc=com" -d 256 # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # my-domain.com dn: dc=my-domain,dc=com dc: my-domain o: www.zxactions.com objectClass: dcObject objectClass: organization # copy of my-domain, my-domain.com dn: ou=copy of my-domain,dc=my-domain,dc=com ou: copy of my-domain objectClass: top objectClass: organizationalUnit # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2

3 3

Openldap version / behavior wih duplicates
by maudez.eric＠neuf.fr 23 Oct '23

23 Oct '23

Hello, I notice a different behavior between versions OpenLDAP 2.4 and OpenLDAP 2.6 for synchronization management and duplicates. In the version OpenLDAP 2.4, there is no error when duplicates are found (different branch in openldap) during synchronizations (syncrepl) With version OpenLDAP 2.6, synchronizations are in error Do you know why?

2 3

ldap proxy, attribute rwm
by Krisztián Gáhor 17 Oct '23

17 Oct '23

I created an LDAP proxy using an LDAP backend to connect to our Active Directory server. Unfortunately, our AD server has incorrect usernames in the sAMAccountName attribute, so I would like to override this with the prefix of the value found in the userPrincipalName attribute (the part before @domain). Is this possible at all? Unfortunately, I haven't succeeded in doing this so far.

1 0

Key/value chunk sizes / alignment?
by Sam Dave 14 Oct '23

14 Oct '23

Hello, I have two LMDB databases, identical except one has key size 34 bytes and the other key size 33 bytes. (Both have same value sizes and same number of pairs). How can the file sizes on disk be exactly the same? Is this because of the 2-byte alignment mentioned here? https://github.com/AltSysrq/lmdb-zero/issues/8 I wonder if this 2-byte alignment was documented anywhere. This doesn't bother me btw. I was just expecting the file sizes to differ (got scared I had a bug in my program until I did an mdb_dump to see the real difference) Thanks, Samuel

2 2

Trying to create master/slave solution with syncrepl
by Christoph Pleger 13 Oct '23

13 Oct '23

Hello, I am trying to create an OpenLDAP master/slave solution with syncrepl, but I have not been successful so far. I followed the suggestions of this site, with another sync password: https://www.itzgeek.com/how-tos/linux/configure-openldap-master-slave-repli… One thing I made different, on the master server, I created the replication user with a userPassword: in SSHA-Format instead of clear text. Additionally, I set, following the suggestion of another website: olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq Now, I can see with tcpdump that the slave server contacts the master server and that the master server send replies, but no LDAP users are synchronized to the slave. Unfortunately, nothing about replication is logged to syslog, though I started slapd on both master and slave with options "-s Sync -c rid=001". Any idea what is wrong or how I can at least get some debgging output about what is happening on master and slave, related to replication? Regards Christoph

4 6

contextCSN via slapcat outdated, despite having set syncprov-checkpoint
by cYuSeDfZfb cYuSeDfZfb 13 Oct '23

13 Oct '23

Hi, We are running replication checks, including one where we compare "slapcat | grep contextCSN" output across our 4 different openldap 2.5 MRR servers. Relevant config (on each server identically through ansible) database mdb maxsize 10737418240 suffix "o=company,c=com" rootdn "cn=ldapadmin,o=company,c=com" rootpw {SSHA}h9xyz..... directory /var/symas/openldap-data overlay syncprov syncprov-checkpoint 100 1 Now using this config, we would expect the contextCSN to be faily up-to-date across all servers, however, this is not always the case. There are occasions where servers contextCSN become 'outdated', while others are up-to-date. If we query contextCSN though ldapsearch, the correct contextCSN is returned on all servers. This situation can remain for long, and restarting openldap solves it immediately. We could of course change our logging to query contextCSN through an ldapsearch, but we see advantages (no network, no authentication, etc, etc) in using slapcat as well. Is there anything we can do to update on-disk contextCSN more often..? We would expect " syncprov-checkpoint 100 1" to take care of this..? Have a nice weekend, everybody! MJ

2 2

Re: refresh and persistant not always persisting :-)
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi Quanah, I feel stupid for not having googled "openldap keepalive", and instead write to the list. I have read so much (and seen so many samples) about replication configuration lately, that I thought I did everything correctly. Thanks for patiently pointing at what I should have been able to find out myself. MJ On Wed, 11 Oct 2023 at 16:29, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, October 11, 2023 4:49 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > Of course I add many more details like detailed configs and logs, just > > ask. > > > > > > We have a 4-host MMR setup, that all replicate to the three others, > > relevant snippets from the config: > > > > We wondered what could cause this behaviour, and started thinking in the > > direction of long-lived tcp connections that perhaps are used in > > refreshAndPersist functionality. (much like in IMAP idle) > > > > > > Is anything special needed to make refreshAndPersistwork reliably through > > firewalls, and across subnets? Does refreshAndPersistwork use (some kind > > of) long-lived network connections..? Is there a kind of "keepalive" > > setting that we could try..? > > Read the section on keepalive settings. This is a common issue with > firewalls and why those settings were introduced. I usually use > keepalive=240:10:30 to go under the (usually default) 5 minute disconnect > most firewalls have. > > --Quanah > >

1 0

refresh and persistant not always persisting :-)
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi, Of course I add many more details like detailed configs and logs, just ask. We have a 4-host MMR setup, that all replicate to the three others, relevant snippets from the config: * moduleload syncprov.la * different (and consistent) serverID's configured correctly on all hosts and then on each host the three other LDAP servers are defined like the below sample from ldapm01.company.com : syncrepl rid=212 provider=ldaps://ldapm02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=232 provider=ldaps://ldaps01.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=242 provider=ldaps://ldaps02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand MirrorMode True We observe that usually replication is quick and instant. But "sometimes" (yes, sometimes...) a replication line (rid) can become 'stuck', and suddeny, after an hour or so it syncs up again. Restarting openldap make it sync immediately. We notice that because we compare contextCSN's across our nodes to monitor replication. There is no significant load, firewall ports are open, but hosts are in different subnets: subnet A: ldapm01 / ldapm02, subnet B: ldaps01 / ldaps02 Of course 389/636 ports are open between the subnets. We wondered what could cause this behaviour, and started thinking in the direction of long-lived tcp connections that perhaps are used in refreshAndPersist functionality. (much like in IMAP idle) Is anything special needed to make refreshAndPersistwork reliably through firewalls, and across subnets? Does refreshAndPersistwork use (some kind of) long-lived network connections..? Is there a kind of "keepalive" setting that we could try..? Input would be appreciated. Also input like: you are looking in the wrong direction, better look into this or that. :-) Thanks!

2 1

pwdEndTime usage
by Volodymyr Lisnyi 11 Oct '23

11 Oct '23

Hello all, I updated our slapd daemon from 2.4 to 2.5 and want to use pwdEndTime operation attribute I read a lot of docs and can not find how I can add this attribute for all existing users. It is an internal operation attribute that was introduced in slapd version 2.5 (OpenLDAP 2.5+ now ships the ppolicy schema hard-coded in the overlay slapo-ppolicy) So as I see this attribute has no true/false or other flag (it is internal scheme attribute), which allows me to add it to dn: cn=passwordDefault,ou=Policies,dc=zone,dc=net or policy overlay olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config os is there any way I can enable it and update existing users with pwdEndTime attribute?

3 11

Re: [EXT] Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi Ulrich, I thought the same, but it seems yum/dnf do not have a post-install 'hook', like debian has with DPkg::Pre-Install-Pkgs & DPkg::Post-Invoke, that allows you to define commands/scripts to run before and after. Not sure how to do something similar on RHEL. I have now excluded openldap from auto updates, and added instructions on our manual update.instructions. Any ideas here..? On Wed, 11 Oct 2023 at 11:05, Windl, Ulrich <u.windl(a)ukr.de> wrote: > I wonder: > Couldn't some RPM "pre-script" remember the current permissions for some > RPM "post script" to restore them (after they were messed up)? > > -----Original Message----- > From: cYuSeDfZfb cYuSeDfZfb <cyusedfzfb(a)gmail.com> > Sent: Thursday, September 21, 2023 10:54 AM > To: Ondřej Kuzník <ondra(a)mistotebe.net> > Cc: openldap-technical(a)openldap.org; Dimitar Stoychev <dstoychev(a)symas.com > > > Subject: [EXT] Re: regular yum symas-openldap-servers update breaks > permissions on /var/symas/openldap-data > > Hi Ondřej, > > Thanks for your reply. > > Yes, we are putting our (single file) mdb straight in > /var/symas/openldap-data, using subdirs never crossed our minds. > > Anyway, we just have to document this behaviour in our upgrade > documentation. > > Must say: the behaviour, for us, is a little bit unexcpected. We didn't > expect rpm upgrades to "mess" with fs permissions, but we can simply work > around it. > > Thanks again for your reply, appreciated! > > > On Wed, 13 Sept 2023 at 12:25, Ondřej Kuzník <ondra(a)mistotebe.net <mailto: > ondra(a)mistotebe.net> > wrote: > > > On Tue, Sep 12, 2023 at 04:44:15PM +0200, cYuSeDfZfb cYuSeDfZfb > wrote: > > Hi, > > > > We're seeing this quite consistently. > > > > Before updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx------. 3 ldap ldap 50 Aug 28 16:28 openldap-data > > > > After updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx------. 3 root root 50 Aug 28 16:28 openldap-data > > > > And afterwards symas-openldap-server (running as ldap:ldap) no > longer > > starts, since permission denied on /var/symas/openldap-data. > > > > Reverting the permissions back to ldap:ldap solves it. But...WHY > is this > > happening. > > > > Are we somehow encouraged to run openldap as root..? > > > > Why would a post-install script reset permissions on > > /var/symas/openldap-data? > > Hi, > openldap-data is owned by the package and as such you'll have to > tell > rpm somehow (a trigger, ...) that you don't want it to mess with > it. > AFAIK there's work ongoing to make the directory 711 which should > sort > things for you. > > That's unless you're putting the databases directly into > /var/symas/openldap-data, we advise you create a subdirectory per > DB, > e.g. /var/symas/openldap-data/dc=example,dc=com or > /var/symas/openldap-data/cn=accesslog. > > Regards, > > -- > Ondřej Kuzník > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP > > >

1 0

Replication issue during performance test with MMR configuration and LastBind enabled
by Ziani Meheni 10 Oct '23

10 Oct '23

Hello, we are working on a project and we've come across a problem with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure and *LastBind enabled*, we're able to perform 300 BIND/s without any replication delays. Beyond that, we start to generate delays. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict We've already run several tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS}

2 1

export certificate and key
by Stefan Kania 05 Oct '23

05 Oct '23

Hi to all, I have autoca running with my own CA. And I can create certificates and keys for users and hosts. But now I would like to use the certificate and key for radius 802.1x authentication so I need to export the certificate and the key. I know how to convert a DER certificate to a pem certificate. But before I can convert the key and the certificate I need to export it. So how can I do that? Another question: Is there any default password in the key or is it without any password? Stefan

3 6

Re: error while setting password policy
by Quanah Gibson-Mount 05 Oct '23

05 Oct '23

--On Tuesday, October 3, 2023 11:57 PM -0400 Jignesh Patel <jignesh(a)icare.com> wrote: > > We are using LDAP version 2.5.16 . > > > when we try to set policy > we are getting this error olcAttributeTypes: value #0 olcAttributeTypes: > Duplicate attributeType: > "1.3.6.1.4.1.42.2.27.8.1.1" slapadd: could not add entry > The .ldif file is as attached. > > > And if we don't import than we are getting pException: [LDAP result > code 17 - undefinedAttributeType] pwdAttribute: attribute type undefined I suggest carefully reading the release notes for OpenLDAP 2.5, specifically around the changes to ppolicy since the 2.4 series. --Quanah

3 2

Configuring custom port 10389 for openldap-servers
by Kaushal Shriyan 04 Oct '23

04 Oct '23

Hi, I am running the openldap server on Red Hat Enterprise Linux release 8.8 (Ootpa) # rpm -qa | grep -i ldap sssd-ldap-2.8.2-3.el8_8.x86_64 symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # Port 389 is the default port. Can it be configured for custom port 10389 for example? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Group ACLs
by Emmanuel Seyman 04 Oct '23

04 Oct '23

Hello, all. I have an instance of OpenLDAP in which I use groups to manage access controls, similar to the way the FAQ and admin guide describe it. My DIT layout: uid=userildr1,ou=people,o=gdAA,dc=example,dc=com uid=userildr2,ou=people,o=gdAA,dc=example,dc=com ... cn=readINT,ou=groups,o=gdAA,dc=example,dc=com cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com ... ou=people,o=INT,dc=example,dc=com ... ou=groups,o=INT,dc=example,dc=com Outside of the DIT, my slapd.conf file (yes, I know) contains: access to dn.sub="o=INT,dc=example,dc=com" by self write by group/groupOfUniqueNames/uniqueMember="cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com" write by group/groupOfUniqueNames/uniqueMember="cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com" write by group/groupOfUniqueNames/uniqueMember="cn=readINT,ou=groups,o=gdAA,dc=example,dc=com" read The uid=userildr1,ou=people,o=gdAA,dc=example,dc=com entry is in the readINT group yet seems unable to run a search. I get an error 50 ("Operations are restricted to bind/unbind/abandon/StartTLS/modify password") and cannot figure out why this is happening. If anyone can tell me what's going on, I would appreciate it. I'm seeing "config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context" in the log files but this looks harmless. This is OpenLDAP 2.5.14 running on RHEL 8, with the LTB packages. Logs and the configuration file are available if necessary. Emmanuel

2 1

Re: setup two DNs on one single Openldap server running on Red Hat Enterprise Linux release 8.8 (Ootpa)
by Kaushal Shriyan 04 Oct '23

04 Oct '23

On Tue, Oct 3, 2023 at 11:45 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, October 2, 2023 2:26 PM +0530 Kaushal Shriyan > <kaushalshriyan(a)gmail.com> wrote: > > > Is there a way to set up two DN's in OpenLDAP server? > > > > > > dn: cn=admin,dc=corporate,dc=mydomain,dc=com > > > > dn: cn=admin,dc=checker,dc=mydomain,dc=com > > This is trivial to create as 2 different entries in your > dc=mydomain,dc=com > database. There's no need for them to be rootdns, you can simply give > them > manage access to whatever they need to control. > > --Quanah > Thanks Quanah for the email response. Much appreciated. I am not sure if I completely understand it. Do I need to have the below format as explained by you to create as 2 different entries in your dc=mydomain,dc=com? dn: cn=admin,ou=*corporate*,dc=mydomain,dc=com dn: cn=admin,ou=*checker*,dc=mydomain,dc=com Please guide me. Thanks in advance. Best Regards, Kaushal

1 0

setup two DNs on one single Openldap server running on Red Hat Enterprise Linux release 8.8 (Ootpa)
by Kaushal Shriyan 04 Oct '23

04 Oct '23

Hi, I am running the openldap server on Red Hat Enterprise Linux release 8.8 (Ootpa) # rpm -qa | grep -i ldap sssd-ldap-2.8.2-3.el8_8.x86_64 symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # Is there a way to set up two DN's in OpenLDAP server? dn: cn=admin,dc=corporate,dc=mydomain,dc=com dn: cn=admin,dc=checker,dc=mydomain,dc=com Please guide me. Thanks in advance. Best Regards, Kaushal

6 13

reset openldap root and cn=admin password
by Kaushal Shriyan 02 Oct '23

02 Oct '23

Hi, Is there a way to reset both openldap root and cn=admin password? Please guide me. Thanks in Advance. Best Regards, Kaushal

2 2

Limit number of concurrent sessions to OpenLDAP 2.6.3 server running on windows
by awsome jang 28 Sep '23

28 Sep '23

Hello, I would like to ask if it's possible to limit the number of concurrent sessions of an openldap server running on Windows? I found in FAQ: https://www.openldap.org/faq/data/cache/1126.html https://www.openldap.org/faq/data/cache/1127.html What I understand it requires rebuilding of OpenLDAP but I would like to change it as a parameter. Is there any other way to do it dynamically without recompilation? On Linux there is possibility to configure iptables to limit number of connections: -A RH-Firewall-1-INPUT -p tcp --dport ldaps -m connlimit --connlimit-above 100 -j REJECT Thank you in advance for your response, Best regards, Piotr

1 0

Unable to ldapadd Kerberos schema in LDIF format
by Uwe Sauter 26 Sep '23

26 Sep '23

Dear all, I'm currently experimenting with (MIT) Kerberos and got to the point where I need to add the Kerberos definitions to LDAP (krb5-kdc.ldif). (This is on Rocky Linux 9 with symas-openldap-servers-2.6.6-1.el9.x86_64.) First question: is this the correct schema file or should I use the one provided by MIT Kerberos 1.20.1 (/usr/share/doc/krb5-server-ldap/kerberos.ldif) ? If I use krb5-kdc.ldif I get the following: [root@gateway ~]# cd /opt/symas/etc/openldap/schema/ [root@gateway schema]# ldapadd -Y EXTERNAL -H ldapi:/// -f krb5-kdc.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=krb5-kdc,cn=schema,cn=config" ldap_add: Constraint violation (19) additional info: structuralObjectClass: no user modification allowed Is this a permission issue or does the provided LDIF file contain lines that prevent the addition of the schema? If I use the file provided by MIT Kerberos I get: [root@gateway ~]# cd /usr/share/doc/krb5-server-ldap [root@gateway krb5-server-ldap]# ldapadd -Y EXTERNAL -H ldapi:/// -f kerberos.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=schema" ldap_modify: Invalid syntax (21) additional info: attributetypes: value #0 invalid per syntax The book I'm following still uses Symas' LDAP 2.4 and thus needs to convert the .schema file to .ldif provided by MIT Kerberos. The procedure is: #### start instructions #### # echo 'include /usr/share/doc/krb5-server-ldap/kerberos.schema' > /tmp/slapd.conf # mkdir /tmp/slapd.d # slaptest -f /tmp/slapd.conf -F /tmp/slapd.d # cp '/tmp/slapd.conf/cn=config/cn=schema/cn={0}kerberos.ldif' /tmp/kerberos.conf Further instructions say: - remove '{0}' in /tmp/kerberos.conf in lines startig with 'dn:' and 'cn:' - add 'cn=schema,cn=config' to the DN - remove the lines containing 'structuralObjectClass', 'entryUUID', 'creatorsName', 'createTimestamp', 'modifiersName', 'modifyTimestamp' and 'entryCSN' at the end of the file After the modifications, there should be only lines containing 'objectClass', 'olcAttributeTypes', 'olcObjectClasses', 'cn' or 'dn'. #### end instructions #### If I follow these instructions and use the converted LDIF file the command succeeds: [root@gateway tmp]# ldapadd -Y EXTERNAL -H ldapi:/// -f kerberos.ldif.converted SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=kerberos,cn=schema,cn=config" Is there an explanation for this behavior? Do the files provided by Symas and MIT contain errors? (For convenience I attached all three files to this mail.) Thank you, Uwe

3 4

Help troubleshooting SSL certificates issue
by Jérôme BECOT 26 Sep '23

26 Sep '23

Hello, We have a couple of old ldap servers (Debian 7/openldap 2.4.31) on which we try to replace the certificates. On these servers we have a bundled configuration: # config dn: cn=config olcTLSCACertificateFile: /etc/ldap/tls/multi.deverywa.re.pem olcTLSCertificateFile: /etc/ldap/tls/multi.deverywa.re.pem olcTLSCertificateKeyFile: /etc/ldap/tls/multi.deverywa.re.pem The file is a bundle containing both the certificates (wildcard and it's issuer) and the key. Until this year we just had to upload the new bundle and restart slapd. This year Gandi changed their signing certificate but it is still issued by UserTrust. But OpenLDAP refuses to use it now. We tried to set LogLevel to any, but nothing really showed in the log. On the server side: slapd[9217]: connection_read(16): TLS accept failure error=-1 id=1041, closing On the client side (localhost): openssl s_client -connect localhost:636 -servername ldap.deverywa.re CONNECTED(00000003) 140365161965224:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 315 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1695652388 Timeout : 300 (sec) Verify return code: 0 (ok) We still use 2048 RSA key to generate the certificates. We have checked permissions and it is fine. How could I debug what's wrong on the server side ? Thank you -- *Jérôme BECOT* Ingénieur DevOps Infrastructure Téléphone fixe: 01 82 28 37 06 Mobile : +33 757 173 193 Deveryware - 43 rue Taitbout - 75009 PARIS https://www.deveryware.com <https://www.deveryware.com> Deveryware_Logo <https://www.deveryware.com>

4 4

changing certificate and key for autoca
by Stefan Kania 21 Sep '23

21 Sep '23

Hi all, I like to change the certificate and the key for autoca, but I can't find any description how to do it. I tried the following LDIF: --------------- dn: dc=example,dc=net changetype: modify replace: cACertificate;binary cACertificate;binary:< file:///root/mycert/cacert.pem - replace: cAPrivateKey;binary cAPrivateKey;binary:< file:///root/mycert/cakey.pem --------------- I got: --------------- root@ldap-r01:~# ldapmodify -Y external -H ldapi:/// -f change-cert.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "dc=example,dc=net" ldap_modify: Invalid syntax (21) additional info: cACertificate;binary: value #0 invalid per syntax ---------------- So what is the right way to change the certificate and the key? Thank's Stefan

2 4

openldap + bind-dyndb-ldap + bind
by Marc 21 Sep '23

21 Sep '23

Anyone experience with openldap and dyndb from bind? I am getting this: critical extension is not recognized: unable to start SyncRepl session: is RFC 4533 supported by LDAP

5 8

Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
by cYuSeDfZfb cYuSeDfZfb 21 Sep '23

21 Sep '23

Hi, We're seeing this quite consistently. Before updating: [root@ldaps01 log]# ls -l /var/symas/ drwx------. 3 ldap ldap 50 Aug 28 16:28 openldap-data After updating: [root@ldaps01 log]# ls -l /var/symas/ drwx------. 3 root root 50 Aug 28 16:28 openldap-data And afterwards symas-openldap-server (running as ldap:ldap) no longer starts, since permission denied on /var/symas/openldap-data. Reverting the permissions back to ldap:ldap solves it. But...WHY is this happening. Are we somehow encouraged to run openldap as root..? Why would a post-install script reset permissions on /var/symas/openldap-data? Thanks!

2 2

assert error + core dump slapd v 2.6.6
by Frédéric Goudal 14 Sep '23

14 Sep '23

Hello, Openldap version 2.6.6 compiled on ubuntu 22.4 LTS For test purpose I’m trying to add an object with objectClass top+person at the root of my openldap (which is not empty), The dn is cn=toto,dc=my,dc=domain When I do something on this object, the slapd server crash, but when restarted the operation has been done. It seems that it is the accelog database that is causing a problem The error is : 501d0f3.15b397b4 0x7f929fc44700 <= index_entry_add( 5, "reqStart=20230913151043.000000Z,cn=accesslog" ) success 6501d0f3.15b410ee 0x7f929fc44700 => mdb_entry_encode(0x00000005): reqStart=20230913151043.000000Z,cn=accesslog 6501d0f3.15b4564d 0x7f929fc44700 <= mdb_entry_encode(0x00000005): reqStart=20230913151043.000000Z,cn=accesslog 6501d0f3.15e04a0b 0x7f929fc44700 mdb_add: added id=00000005 dn="reqStart=20230913151043.000000Z,cn=accesslog" 6501d0f3.15e0bab7 0x7f929fc44700 send_ldap_result: conn=1000 op=12 p=3 6501d0f3.15e0f6a9 0x7f929fc44700 send_ldap_result: err=0 matched="" text="" 6501d0f3.15e1603a 0x7f929fc44700 slap_graduate_commit_csn: removing 0x7f92901234d0 20230913151043.360508Z#000000#057#000000 6501d0f3.15e1c5a6 0x7f929fc44700 accesslog_response: adding minCSN 20230913151043.360508Z#000000#057#000000 6501d0f3.15e20736 0x7f929fc44700 accesslog_response: adding a new csn=20230913151043.360508Z#000000#057#000000 into minCSN 6501d0f3.15e3a20c 0x7f929fc44700 mdb_modify: cn=accesslog 6501d0f3.15e40781 0x7f929fc44700 mdb_dn2entry("cn=accesslog") 6501d0f3.15e45a2d 0x7f929fc44700 => mdb_dn2id("cn=accesslog") 6501d0f3.15e50b53 0x7f929fc44700 <= mdb_dn2id: got id=0x1 6501d0f3.15e57cc9 0x7f929fc44700 => mdb_entry_decode: 6501d0f3.15e5bb28 0x7f929fc44700 <= mdb_entry_decode 6501d0f3.15e5f9b4 0x7f929fc44700 mdb_modify_internal: 0x00000001: cn=accesslog 6501d0f3.15e63487 0x7f929fc44700 <= acl_access_allowed: granted to database root 6501d0f3.15e6881d 0x7f929fc44700 mdb_modify_internal: add minCSN slapd: attr.c:481: attr_merge: Assertion `( nvals == NULL && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != NULL && ( ( (*a)->a_vals == NULL && (*a)->a_nvals == NULL ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )' failed. Aborted (core dumped) Is it a bug ? f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 2

slapd-watcher -i X refreshing unexpectedly...?
by cYuSeDfZfb cYuSeDfZfb 13 Sep '23

13 Sep '23

Hi, We noticed that, when using "slapd-watcher -i X" option to refresh display every X seconds, lagging replication statuses are often not cleared, when in fact replication as already recovered. In our MMR environment, we often see this for longer periods of time in slapd-watcher output : contextCSN: 20230913104435.605937Z#000000#0dd#000000 actv@2023-09-13 10:44:35, idle@2023-09-13 10:44:37 But when running like this: do timeout --foreground 1 $SLAPDWATCHER -b $BASE -D $LDAPBINDDN -w $ADMINPW "${SERVERURIS[@]}" -s ${SERVERIDS[*]} done the lagging replication lines change back to "idle, sync'd" immediately after replication has recovered. It feels like perhaps there is something wrong in the way the -i X option is implemented. For the rest: great tool to have!

3 3

Trying to understand mdb_env_set_mapsize
by Siddharth Jain 12 Sep '23

12 Sep '23

Hello, can someone help me understand this parameter: http://www.lmdb.tech/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5 1. why does a user need to specify this apriori? Other databases don't require user to declare the size of the db beforehand. its not something a user knows in advance. 2. quoting: "The size of the memory map is also the maximum size of the database.". what happens when the size of the db overflows this parameter? 3. what is the trade-off if a user sets this parameter too large than is necessary? S.

2 2

Enable debug logging on OpenLDAP 2.4.59 server running on Red Hat Enterprise Linux 8.7 (Ootpa)
by Kaushal Shriyan 31 Aug '23

31 Aug '23

Hi, I have the below settings as per https://www.openldap.org/doc/admin25/slapdconfig.html. I did check both /var/log and /etc/default/ on RHEL 8.7 but was unable to locate the log files. # grep olcLogLevel /etc/openldap/slapd.d/cn=config.ldif olcLogLevel: 256 # ldapwhoami: @(#) $OpenLDAP: ldapwhoami 2.4.59 (Jun 4 2021 16:57:15) $ build@c8rpm :/home/build/git/rheldap8/RHEL8_x86_64/BUILD/symas-openldap-2.4.59/openldap-2.4.59/clients/tools (LDAP library: OpenLDAP 20459) Is there a way to enable debug logging on openldap server and openldap client on "Red Hat Enterprise Linux 8.7 (Ootpa)" for debugging the ldap user logging issue? Please comment. Thanks in advance. Best Regards, Kaushal

2 1

removed syncrepl getting Server is unwilling to perform (53)
by Marc 31 Aug '23

31 Aug '23

I removed the synrepl from a ldap server. Now I am getting errors when deleting entries ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral I also tried adding this, but does not change anything. dn: olcDatabase={0}config,cn=config changetype:modify add: olcMirrorMode olcMirrorMode: FALSE I don't think it is the acl's as I was able to change logging level before, when it was a slave. However now I am also not able to update the logging level. What config settings should I look at?

3 8

Re: [EXT] rhel8 OS rpm spec file
by Kaushal Shriyan 31 Aug '23

31 Aug '23

On Thu, Aug 24, 2023 at 2:39 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, August 21, 2023 11:54 PM +0530 Kaushal Shriyan > <kaushalshriyan(a)gmail.com> wrote: > > > Thanks Quanah for the quick response. I am > > following https://unixcop.com/how-to-install-openldap-on-rockylinux-or-c > > entos-8-step-by-step/. Are there any tutorials or guides to setup > > symas-openldap-servers-2.5.16-1.el8.x86_64 on Red Hat Enterprise Linux > > release 8.7 (Ootpa)? > > I would read the official documentation from the OpenLDAP website. > > --Quanah > > Thanks Quanah for the quick response and help. Much appreciated.

1 0

regular yum update 2.5.14 -> 2.5.16 resets rights on /var/symas/openldap-data
by cYuSeDfZfb cYuSeDfZfb 28 Aug '23

28 Aug '23

Hi, Just a quick warning to all: we upgraded a RHEL9 test system from 2.5.14 to 2.5.16, and see: Before: [root@ldaps01 log]# ls -l /var/symas/ drwx------. 3 ldap ldap 50 Aug 28 16:28 openldap-data After: [root@ldaps01 log]# ls -l /var/symas/ drwx------. 3 root root 50 Aug 28 16:28 openldap-data So after the update, ldap no longer started, due to "invalid path: Permission denied" Reverting the permissions back to ldap:ldap solves it. But... is this somehow on purpose, or....?

1 0

syncrepl default value questions
by Dick Visser 28 Aug '23

28 Aug '23

Hi I'm configuring syncrepl and have some questions about its parameters. The version used is: @(#) $OpenLDAP: slapd 2.5.13+dfsg-5 (Feb 8 2023 01:56:12) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> I'm using the docs from https://www.openldap.org/doc/admin25/slapdconfig.html. It says there: "The network-timeout parameter sets how long the consumer will wait to establish a network connection to the provider. Once a connection is established, the timeout parameter determines how long the consumer will wait for the initial Bind request to complete. The defaults for these parameters come from *ldap.conf*(5)." But, "man 5 ldap.conf " does not seem to list those defaults. Instead it says this about them: NETWORK_TIMEOUT <integer> Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity. TIMEOUT <integer> Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also used for any ldap_result(3) calls where a NULL timeout pa‐ rameter is supplied. So, I wonder what is being used as default for these. In case there is none, that would come down to 'infinite'. But I don't find that information either. Something similar goes for 'keepalive', that is described as: "The keepalive parameter sets the values of idle, probes, and interval used to check whether a socket is alive; idle is the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes; probes is the maximum number of keepalive probes TCP should send before dropping the connection; interval is interval in seconds between individual keepalive probes. Only some systems support the customization of these values; the keepalive parameter is ignored otherwise, and system-wide settings are used. For example, keepalive="240:10:30" will send a keepalive probe 10 times, every 30 seconds, after 240 seconds of idle activity. If no response to the probes is received, the connection will be dropped." The "man 5 ldap.conf" has these keepalive params: KEEPALIVE_IDLE Sets/gets the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes. Linux only. KEEPALIVE_PROBES Sets/gets the maximum number of keepalive probes TCP should send before dropping the con‐ nection. Linux only. KEEPALIVE_INTERVAL Sets/gets the interval in seconds between indi‐ vidual keepalive probes. Linux only. Again, no defaults. We do run this on Linux, and the kernel has corresponding values for: root@foo:/proc/sys/net/ipv4# for i in tcp_keepalive_*; do echo "$i = $(cat $i)"; done tcp_keepalive_intvl = 75 tcp_keepalive_probes = 9 tcp_keepalive_time = 7200 So, I'm guessing in my case "keepalive" will use "7200:9:75" - right? I.e. the defaults are from the OS' TCP stack configuration. Many thanks Dick Visser

1 0

still stuck with allowing access to all attributes except 1 or 2
by Marc 27 Aug '23

27 Aug '23

olcAccess: {0} to dn.exact="" by * read olcAccess: {1} to dn.exact="cn=Subschema" by * read olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self read by ssf=256 anonymous auth by * none break ... olcAccess: {7} to dn.subtree="xxxxxx" filter=(objectClass=posixAccount) attrs= by ssf=64 dn.exact="yyyy" read by * break olcAccess: {8} to dn.subtree="xxxxxx" by ssf=256 dn.exact="yyyy" search by ssf=256 self read by anonymous is there not a syntax or so for attrs=-userPassword Or am I approaching this incorrectly?

3 5

Re: [EXT] rhel8 OS rpm spec file
by Kaushal Shriyan 23 Aug '23

23 Aug '23

On Mon, Aug 21, 2023 at 10:29 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, August 21, 2023 10:38 PM +0530 Kaushal Shriyan > <kaushalshriyan(a)gmail.com> wrote: > > > > Prepare the database template included in OpenLDAP installed > > > ># cp -r /usr/share/openldap-servers/DB_CONFIG.example > ># /var/lib/ldap/DB_CONFIG > > cp: cannot stat '/usr/share/openldap-servers/DB_CONFIG.example': No such > > file or directory > > > ># ls -l /usr/share/openldap-servers/DB_CONFIG.example > > ls: cannot access '/usr/share/openldap-servers/DB_CONFIG.example': No > > such file or directory > ># ls -l /etc/openldap/slapd.d/cn=config/olcDatabase={2}mdb.ldif > > ls: cannot access > > '/etc/openldap/slapd.d/cn=config/olcDatabase={2}mdb.ldif': No such file > > or directory > > I don't know where you are getting information about > /usr/share/openldap-servers/DB_CONFIG.example. That doesn't exist in > OpenLDAP 2.5+ > > --Quanah > Thanks Quanah for the quick response. I am following https://unixcop.com/how-to-install-openldap-on-rockylinux-or-centos-8-step-…. Are there any tutorials or guides to setup symas-openldap-servers-2.5.16-1.el8.x86_64 on Red Hat Enterprise Linux release 8.7 (Ootpa)? Please suggest further. Thanks in advance. Best Regards, Kaushal

2 2

lmdb usage in containers
by Vitaly Repin 21 Aug '23

21 Aug '23

Hello, I have a question about usage of the same lmdb database in different containers and in the host machine. So far I just mapped lmdp file in docker-compose.yml: volumes: - "/var/spool/lmdbenv/:/var/spool/lmdbenv/" And I'm reading/writing to/from the database from different containers. Everything seems to work at a first glance. Example of adding an element to lmdb: /usr/bin/python -mlmdb --env /var/spool/lmdbenv edit \ --set "client"="{ \"client_ip\" : \"$client_ip\", \"client_data\" : \"$client_data\" }" Is it the proper use case for lmdb? Is there any special "flush" API which I have to use to make sure that the record inserted in one container becomes visible in another? Thanks in advance! -- WBR & WBW, Vitaly

2 2

Re: [EXT] rhel8 OS rpm spec file
by Kaushal Shriyan 21 Aug '23

21 Aug '23

Hi, Are there any tutorials or guides to configure symas based Openldap server on Red Hat Enterprise Linux release 8.7 (Ootpa)? # rpm -qa | grep openldap symas-openldap-servers-2.5.16-1.el8.x86_64 symas-openldap-servers-selinux-1.0.6-1.el8.noarch symas-openldap-libs-2.5.16-1.el8.x86_64 symas-openldap-clients-2.5.16-1.el8.x86_64 # Please guide me. Thanks in Advance. Best Regards, Kaushal On Wed, Aug 9, 2023 at 11:19 PM Kaushal Shriyan <kaushalshriyan(a)gmail.com> wrote: > > > On Mon, Aug 7, 2023 at 12:01 PM Windl, Ulrich <u.windl(a)ukr.de> wrote: > >> I think the question is somewhat off-topic here: Learn how to build an >> RPM package from elsewhere, maybe >> https://www.redhat.com/sysadmin/create-rpm-package or >> https://developers.redhat.com/blog/2019/03/18/rpm-packaging-guide-creating-… >> or https://linuxconfig.org/how-to-create-an-rpm-package >> >> -----Original Message----- >> From: Kaushal Shriyan <kaushalshriyan(a)gmail.com> >> Sent: Sunday, August 6, 2023 3:51 AM >> To: openldap-technical(a)openldap.org >> Subject: [EXT] rhel8 OS rpm spec file >> >> Hi, >> >> Is there a way to generate openldap-servers.x86_64 rpm spec file from >> https://www.openldap.org/software/download/OpenLDAP/openldap-release/openld… >> >> >> # ll >> total 900 >> -rw-r--r-- 1 1001 1001 11109 Jul 10 21:59 aclocal.m4 >> -rw-r--r-- 1 1001 1001 6100 Jul 10 21:59 ANNOUNCEMENT >> drwxr-xr-x 2 1001 1001 4096 Jul 10 21:59 build >> -rw-r--r-- 1 1001 1001 14120 Jul 10 21:59 CHANGES >> drwxr-xr-x 3 1001 1001 38 Jul 10 21:59 clients >> -rwxr-xr-x 1 1001 1001 753489 Jul 10 21:59 configure >> -rw-r--r-- 1 1001 1001 99724 Jul 10 21:59 configure.ac < >> http://configure.ac> >> drwxr-xr-x 7 1001 1001 129 Jul 10 21:59 contrib >> -rw-r--r-- 1 1001 1001 2345 Jul 10 21:59 COPYRIGHT >> drwxr-xr-x 8 1001 1001 102 Jul 10 21:59 doc >> drwxr-xr-x 3 1001 1001 4096 Jul 10 21:59 include >> -rw-r--r-- 1 1001 1001 3793 Jul 10 21:59 INSTALL >> drwxr-xr-x 8 1001 1001 123 Jul 10 21:59 libraries >> -rw-r--r-- 1 1001 1001 2214 Jul 10 21:59 LICENSE >> -rw-r--r-- 1 1001 1001 1029 Jul 10 21:59 Makefile.in >> -rw-r--r-- 1 1001 1001 3594 Jul 10 21:59 README >> drwxr-xr-x 4 1001 1001 52 Jul 10 21:59 servers >> drwxr-xr-x 5 1001 1001 93 Jul 10 21:59 tests >> # ./configure --help | grep spec >> To assign environment variables (e.g., CC, CFLAGS...), specify them as >> Defaults for the options are specified in brackets. >> --help=short display options specific to this package >> `/usr/local/bin', `/usr/local/lib' etc. You can specify >> --with-odbc with specific ODBC support >> compiler's sysroot if not specified). >> # >> >> Please guide me. >> >> Thanks in Advance. >> >> Best Regards, >> >> Kaushal >> >> > Thanks Quanah and Ulrich for the quick email response. Much appreciated > for guiding me. Thanks once again. > > Best Regards, > > Kaushal >

2 2

enable SSL
by Jean-Luc Chandezon 21 Aug '23

21 Aug '23

Hello dear community, I want to enable SSL, but I cannot find "/etc/sysconfig/slapd" file. OpenLDAP version is 2.4.59, on , for testing.. I'm going to migrate to last version next month. OS is Rocky Linux 8.8. Thanks, Jean-Luc

6 6

mdb_env_close, mdb_dbi_close, mdb_dbi_open
by Sam Dave 21 Aug '23

21 Aug '23

Hi, I'm interested in understanding these functions better. These are not criticisms.. since these functions are called rarely, I have no problem synchronizing them. I ask only for curiosity's sake. * mdb_env_close: "Only a single thread may call this function." Why can't different environments (separate files/dirs on disk) be closed from different threads? * mdb_dbi_close: "Handles should only be closed by a single thread." Why can't at least databases on different environments (separate files/dirs on disk) be closed from different threads? * mdb_dbi_open: "This function must not be called from multiple concurrent transactions in the same process." Why can't this function be called from different threads to open at least databases on different environments (separate files/dirs on disk)? What are the reasons for these limitations, under the hood? Could these functions have been designed in a different way, to allow for more multithreading (again, I'm not asking for this, I'm just curious). - Sam

2 4

Re: ldap_add: Naming violation (64) additional info: value of single-valued naming attribute 'dc' conflicts with value present in entry
by Kaushal Shriyan 18 Aug '23

18 Aug '23

On Thu, Aug 17, 2023 at 9:41 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, August 17, 2023 7:25 AM +0530 Kaushal Shriyan > <kaushalshriyan(a)gmail.com> wrote: > > ># cat mydomain.ldif > > dn: dc=corporate,dc=mydomain,dc=in > > objectClass: dcObject > > objectClass: organization > > dc: mydomain > > o: mydomain > > > > > ># ldapadd -f mydomain.ldif -D cn=admin,dc=corporate,dc=mydomain,dc=in -W > > > > adding new entry "dc=corporate,dc=mydomain,dc=in" > > ldap_add: Naming violation (64) > > additional info: value of single-valued naming attribute 'dc' > > conflicts with value present in entry > > As it stated, "dc: mydomain" does not equal "dc: corporate". Fix the > naming value. > > --Quanah > > Thanks Quanah for the quick email response. It worked like a charm. Much appreciated for guiding me. Thanks once again. Best Regards, Kaushal

1 0

Questions about slapo-memberof
by Alex Samad - Yieldbroker 18 Aug '23

18 Aug '23

Hi I am using slapo-memberof wondering about its performance, I have a couple of groups that have a large pool of unique member attributes. I had some maintenance code that would update the largest group - say about 4k uniquemember entries. The code is wrong it rewrite all of the attributes instead of just updating the diff. But what we noticed is that for upto 13 sec the memberof attrib could be wrong on a user object whilst I presume slapo-memberof re evaluated all of the memberships Question I am in the middle of rewritting the maintenance code - will slapo-memberof only reprocess the additions / diffs or will it reeval all ... Do I have any control over how many threads or are there any control knobs I can tune for the slapo-memberof to help with this ? Thanks Alex

1 0

Re: 2.6.4 replication oddness
by Quanah Gibson-Mount 17 Aug '23

17 Aug '23

--On Thursday, August 17, 2023 2:02 PM -0400 Brendan Kearney <bpk678(a)gmail.com> wrote: >> Generally an export of the cn=config DB, minus any passwords of the >> different providers. If the config is identical across all 3, then >> just one copy of the config. >> >> --Quanah > > i have attached the export of cn=config, with sensitive data removed. > the config is intended to be identical between the nodes, though i have > broken things apart, in an attempt to rectify some issues and update > things to new functionality. I'm going to take this off list, but your config is an utter mess and contains a lot of things that need fixing. ;) I'll follow up once I have some time to fix it. --Quanah

2 2

slapd module thread synchronization and portability. __atomic_xxx().
by Sean Gallagher 17 Aug '23

17 Aug '23

Hi OpenLDAP affiliates, I'm working on a slapd module and have started looking at thread safety. I've noticed that lloadd uses __atomic_xx GCC builtins but slapd does not. Is there are reason for this? Does lloadd compile and run on all the same targets that slapd does? Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com

2 1

2.6.4 replication oddness
by Brendan Kearney 17 Aug '23

17 Aug '23

list members, i am implementing slapd 2.6.4, having had 2.4.x running for quite some time. i had 2 primary nodes with n-way multi primary replication working like a charm, and want to have 2.6.4 with 3 primary nodes. i keep running into some odd issues when i bring up all three nodes and they begin replicating between each of the nodes. i have failure messages showing the instances core-dumping and want to find why the core dumps occur. Aug 08 16:21:20 server1 systemd[1]: slapd.service: Main process exited, code=dumped, status=11/SEGV Aug 08 16:21:20 server1 systemd[1]: slapd.service: Failed with result 'core-dump'. i have enable "stats" log level, and don't get much more info. i can run one instance and seem to be working without core dumping, but if i turn up one or both of the other slapd instances, all 3 of the instances begin failing. should i bump the log level up or is there diagnostics i can run, to find the reason things are failing? any insight is greatly appreciated. if i need to provide more info, let me know what is needed. thanks in advance, brendan

2 8

ldap_add: Naming violation (64) additional info: value of single-valued naming attribute 'dc' conflicts with value present in entry
by Kaushal Shriyan 17 Aug '23

17 Aug '23

Hi, I am running the below mentioned openldap server version on CentOS Linux release 7.9.2009 (Core). The details are as follows. # cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" # # rpm -qa | grep openldap openldap-clients-2.4.44-25.el7_9.x86_64 openldap-servers-2.4.44-25.el7_9.x86_64 openldap-2.4.44-25.el7_9.x86_64 # # slapd -VV @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $ mockbuild(a)x86-01.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd # systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2023-08-17 05:57:50 IST; 5min ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Process: 6448 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 6410 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS) Main PID: 6450 (slapd) CGroup: /system.slice/slapd.service └─6450 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Aug 17 05:59:50 cbopenldap slapd[6450]: conn=1001 op=1 RESULT tag=105 err=64 text=value of single-valued naming attribute 'dc' conflicts with value present in entry Aug 17 05:59:50 cbopenldap slapd[6450]: conn=1001 op=2 UNBIND Aug 17 05:59:50 cbopenldap slapd[6450]: conn=1001 fd=11 closed Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 fd=11 ACCEPT from IP=[::1]:42840 (IP=[::]:389) Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=0 BIND dn="" method=128 Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=0 RESULT tag=97 err=0 text= Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=1 SRCH base="dc=corporate,dc=mydomain,dc=in" scope=2 deref=0 filter="(objectClass=*)" Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 op=2 UNBIND Aug 17 06:00:01 cbopenldap slapd[6450]: conn=1002 fd=11 closed # # netstat -antup | grep -i 389 tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 6450/slapd tcp6 0 0 :::389 :::* LISTEN 6450/slapd # The distinguished name is *dc=corporate,dc=mydomain,dc=in * # cat mydomain_config.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=corporate,dc=mydomain,dc=in dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=admin,dc=corporate,dc=mydomain,dc=in #ldapmodify -Y EXTERNAL -H ldapi:/// -f mydomain_config.ldif # cat mydomain_config2.ldif dn: olcDatabase={2}hdb,cn=config changeType: modify replace: olcRootPW olcRootPW: {SSHA}m2NMC1NMrp5BavWVSHm2Becq7J2fHDNa #ldapmodify -Y EXTERNAL -H ldapi:/// -f mydomain_config2.ldif # cat mydomain_config3.ldif dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by dn.base="cn=admin,dc=corporate,dc=mydomain,dc=in" read by * none #ldapmodify -Y EXTERNAL -H ldapi:/// -f mydomain_config3.ldif The distinguished name is *dc=corporate,dc=mydomain,dc=in * # cat mydomain.ldif dn: dc=corporate,dc=mydomain,dc=in objectClass: dcObject objectClass: organization dc: mydomain o: mydomain # ldapadd -f mydomain.ldif -D cn=admin,dc=corporate,dc=mydomain,dc=in -W adding new entry "dc=corporate,dc=mydomain,dc=in" ldap_add: Naming violation (64) additional info: value of single-valued naming attribute 'dc' conflicts with value present in entry # ldapsearch -x -b dc=corporate,dc=mydomain,dc=in *Output of ldapsearch -x -b dc=corporate,dc=mydomain,dc=in command* # extended LDIF # # LDAPv3 # base <dc=corporate,dc=mydomain,dc=in> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1 # I am encountering the below issue as explained with the steps mentioned above ldap_add: Naming violation (64) > additional info: value of single-valued naming attribute 'dc' conflicts > with value present in entry Am I missing anything? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Re: ldapmodify: wrong attributeType at line 5, entry "olcDatabase={2}hdb,cn=config"
by Kaushal Shriyan 11 Aug '23

11 Aug '23

On Wed, Aug 9, 2023 at 8:29 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, August 9, 2023 7:31 PM +0530 Kaushal Shriyan > <kaushalshriyan(a)gmail.com> wrote: > > > Configure OpenLDAP server while sending the configuration to the LDAP > > server. > ># cat db.ldif > > dn: olcDatabase={2}hdb,cn=config > > changetype: modify > > replace: olcSuffix > > olcSuffix: dc=itzgeek,dc=local > > dn: olcDatabase={2}hdb,cn=config > > changetype: modify > > replace: olcRootDN > > olcRootDN: cn=ldapadm,dc=itzgeek,dc=local > > dn: olcDatabase={2}hdb,cn=config > > changetype: modify > > replace: olcRootPW > > olcRootPW: {SSHA}RCQG8Sec/XtirtjxXL2cbAyeeWH2A9r/ > > > This is not valid LDIF change format. I suggest reading documentation on > how to create valid LDIF changes. > > <https://ldap.com/ldif-the-ldap-data-interchange-format/> has some good > detail, see the section on: > > LDIF Modify Change Records > > Regards, > Quanah > > Thanks Quanah for the quick email response. Is there a way to validate the LDIF file once it is created? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

ldapmodify: wrong attributeType at line 5, entry "olcDatabase={2}hdb,cn=config"
by Kaushal Shriyan 09 Aug '23

09 Aug '23

Hi, I am running the below mentioned openldap server version on CentOS Linux release 7.9.2009 (Core) # rpm -qa | grep openldap openldap-servers-2.4.44-25.el7_9.x86_64 openldap-servers-sql-2.4.44-25.el7_9.x86_64 openldap-devel-2.4.44-25.el7_9.x86_64 openldap-2.4.44-25.el7_9.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-clients-2.4.44-25.el7_9.x86_64 # # slapd -VV @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $ mockbuild(a)x86-01.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd # # systemctl status slapd ● slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2023-08-09 18:17:23 IST; 3min 36s ago Docs: man:slapd man:slapd-config man:slapd-hdb man:slapd-mdb file:///usr/share/doc/openldap-servers/guide.html Main PID: 16246 (slapd) CGroup: /system.slice/slapd.service └─16246 /usr/sbin/slapd -u ldap -h ldapi:/// ldap:/// Aug 09 18:17:22 cbopenldap slapd[16243]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $ mockbuild(a)x86-01.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd Aug 09 18:17:23 cbopenldap slapd[16246]: slapd starting Aug 09 18:17:23 cbopenldap systemd[1]: Started OpenLDAP Server Daemon. Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 fd=11 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 BIND dn="" method=163 Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber...l,cn=auth" Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 op=1 UNBIND Aug 09 18:20:04 cbopenldap slapd[16246]: conn=1000 fd=11 closed Hint: Some lines were ellipsized, use -l to show in full. # *Setup LDAP admin password* slappasswd -h {SSHA} -s ldappassword # cd /etc/openldap/slapd.d/ # ls -ltrh total 4.0K -rw------- 1 ldap ldap 589 Aug 5 16:27 cn=config.ldif drwxr-x--- 3 ldap ldap 182 Aug 5 16:37 cn=config # cd cn\=config # ls -ltrh total 20K -rw------- 1 ldap ldap 378 Aug 5 16:27 cn=schema.ldif -rw------- 1 ldap ldap 609 Aug 5 16:27 olcDatabase={2}hdb.ldif -rw------- 1 ldap ldap 443 Aug 5 16:27 olcDatabase={-1}frontend.ldif -rw------- 1 ldap ldap 513 Aug 5 16:27 olcDatabase={0}config.ldif -rw------- 1 ldap ldap 611 Aug 5 16:37 olcDatabase={1}monitor.ldif drwxr-x--- 2 ldap ldap 108 Aug 5 16:38 cn=schema # cd cn=schema # ls -ltrh total 40K -rw------- 1 ldap ldap 16K Aug 5 16:27 cn={0}core.ldif -rw------- 1 ldap ldap 12K Aug 5 16:38 cn={1}cosine.ldif -rw------- 1 ldap ldap 6.5K Aug 5 16:38 cn={2}nis.ldif -rw------- 1 ldap ldap 2.9K Aug 5 16:38 cn={3}inetorgperson.ldif # Configure OpenLDAP server while sending the configuration to the LDAP server. # cat db.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=itzgeek,dc=local dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=ldapadm,dc=itzgeek,dc=local dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}RCQG8Sec/XtirtjxXL2cbAyeeWH2A9r/ # # ldapmodify -Y EXTERNAL -H ldapi:/// -f db.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 ldapmodify: wrong attributeType at line 5, entry "olcDatabase={2}hdb,cn=config" # Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Help writing a slapd plugin
by John Scott 07 Aug '23

07 Aug '23

Hi, Inspired by the proprietary server at ldap.dnssek.info, I'd like to make a slapd plugin that, when queried for a particular email address, finds the OpenPGP keys and S/MIME certificates by doing DNS lookups (possibly aided by DANE), and then serves them back to the requestor. Currently the documentation in the OpenLDAP Administrator's Guide still needs to be written. Since not a lot of software supports DANE right now, but a lot of programs *do* support LDAP, I think a bridge between the two is something that could really benefit the Internet community. Could someone steer me in the right direction on how to get started? Thanks

3 2

Idea for security module: Using dnX509peerNormalize() to validate client certificates
by Sean Gallagher 07 Aug '23

07 Aug '23

Hi OpenLDAP team, I am investigating writing a module to perform certificate validation as has been discussed in previous posts (See the "Proposal to strengthen slapd EXTERNAL authentication" thread on the openldap-technical(a)openldap.org list). The idea is to inspect the subject name on the client certificate as soon as possible after TLS is established and close the connection if it does not match some predefined pattern. This would allow client certificates signed by public CAs to be used safely with slapd. Looking through the code, I see that dnX509peerNormalize() is called almost immediately after the TLS is established and that it may be handled by a callable handler installed by the register_certificate_map_function() entry point. This would be an ideal place to inspect the certificate. The only problem being it that there is no way to "reject" a certificate and force the connection to be closed. It may be possible to use the ssl context passed into the dnX509peerNormalize() function to close the connection but this would not be very clean and likely have undesirable side effects. What would be good is if dnX509peerNormalize() could return a particular error code to signal that the connection should be immediately closed. I see that LDAP_INVALID_CREDENTIALS is already used to signal benign invalid credentials. Maybe a new error code is required. something like "LDAP_HOSTILE_CREDENTIALS". connection.c: connection_read() could then detect this and close the connection in an orderly fashion by calling connection_closing( c, "TLS Client certificate rejected" ); connection_close( c ); This would seem to be a generally useful thing to have in the slapd core. Is this something the OpenLDAP project would consider doing? Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com

2 5

ACL with filter memberOf
by Carsten Jäckel 07 Aug '23

07 Aug '23

Dear experts, an accessUser account used for application access has to be granted read access to member accounts of a group (groupOfNames). The list of attributes to be read by the accessUser is limited. The accessUser has to search in the limited attribute list (e. g. uid=abcd). Using OpenLDAP 2.4.49 (with configured overlay 'memberOf') we achieved this goal by configuring the following ACLs in olcAcces of olcDatabase={1}mdb,cn=config: {0}to * by self read by anonymous auth by * break {1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break {2}to dn.subtree="dc=users,dc=example,dc=com" filter="(memberOf=cn=group1,dc=groups,dc=example,dc=com)" attrs="entry,objectclass,uid,cn,displayName,telephoneNumber,ou,mail,memberOf,entryDN" by dn.exact="cn=accessUser,dc=accessUsers,dc=example,dc=com" read by * break During migration to OpenLDAP 2.5 we eliminated the overlay 'memberOf' and replaced it's functionality by the overlay 'dynlist'. As a consequence we experienced that the filter statement in ACL {2} doesn't work any longer in OpenLDAP 2.5. Result of ldapsearch -x -W -D "cn=accessUser,dc=accessUsers,dc=example,dc=com" -b "dc=users,dc=example,dc=com" -s sub "(memberOf=cn=group1,dc=groups,dc=example,dc=com)" "entry objectclass uid cn displayName telephoneNumber ou mail memberOf entryDN" doesn't return any results alhough the group object contains members. We suppose that it has something to to with memberOf becoming some kind of 'virtual' attribute which may be only calculated when explicitly asked for. (Please correct this assumtion if it's incorrect.) These are the relevant parts of our configuration in OpenLDAP 2.5: Frontend: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=subschema" by * read mdb: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/symas/openldap-data olcAccess: {0}to * by self read by anonymous auth by * break olcAccess: {1}to dn.subtree="dc=example,dc=com" filter="(|(dc=example)(dc=us ers))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc=accessUse rs,dc=example,dc=com" read by * break olcAccess: {3}to dn.subtree="dc=users,dc=example,dc=com" filter="(|(dc=examp le)(dc=users))" attrs="entry,Objectclass,dc" by dn.exact="cn=accessUser,dc= accessUsers,dc=example,dc=com" read by * break" olcDbIndex: cn olcDbIndex: default eq,sub olcDbIndex: departmentNumber pres,eq,sub olcDbIndex: displayName olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: gidNumber eq olcDbIndex: givenName olcDbIndex: host eq olcDbIndex: inetUserStatus olcDbIndex: mail eq olcDbIndex: mailLocalAddress eq olcDbIndex: member eq olcDbIndex: memberOf eq olcDbIndex: memberUid eq olcDbIndex: objectclass eq olcDbIndex: sn olcDbIndex: sudoHost eq,sub olcDbIndex: sudoUser eq,sub olcDbIndex: uid olcDbIndex: uidNumber eq olcDbIndex: uniqueMember eq olcDbMaxReaders: 126 olcDbMaxSize: 10000000000 olcReadOnly: FALSE olcRootDN: cn=manager,dc=example,dc=com olcRootPW:: <abcd1234> olcSuffix: dc=example,dc=com dn: olcOverlay={0}refint,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {0}refint olcRefintAttribute: member olcRefintNothing: cn=someone,dc=example,dc=com dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyDefault: cn=passwordDefault,ou=password_policies,ou=configurations ,dc=example,dc=com olcPPolicyHashCleartext: TRUE dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcDynListConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: {3}syncprov olcSpCheckpoint: 10 1 olcSpSessionlog: 20000 dn: olcOverlay={4}dds,olcDatabase={1}mdb,cn=config objectClass: olcDDSConfig objectClass: olcOverlayConfig olcOverlay: {4}dds olcDDSinterval: 1h olcDDSmaxTtl: 10d olcDDSminTtl: 10s olcDDSstate: TRUE olcDDStolerance: 5s dn: olcOverlay={5}otp,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: top olcOverlay: {5}otp My question now is: what is the correct ACL configuration/filter statement to ask for a user's group memberships to achieve our goal in OpenLDAP 2.5? Any help would be greatly appreciated! --Carsten

2 1

rhel8 OS rpm spec file
by Kaushal Shriyan 06 Aug '23

06 Aug '23

Hi, Is there a way to generate openldap-servers.x86_64 rpm spec file from https://www.openldap.org/software/download/OpenLDAP/openldap-release/openld… # ll total 900 -rw-r--r-- 1 1001 1001 11109 Jul 10 21:59 aclocal.m4 -rw-r--r-- 1 1001 1001 6100 Jul 10 21:59 ANNOUNCEMENT drwxr-xr-x 2 1001 1001 4096 Jul 10 21:59 build -rw-r--r-- 1 1001 1001 14120 Jul 10 21:59 CHANGES drwxr-xr-x 3 1001 1001 38 Jul 10 21:59 clients -rwxr-xr-x 1 1001 1001 753489 Jul 10 21:59 configure -rw-r--r-- 1 1001 1001 99724 Jul 10 21:59 configure.ac drwxr-xr-x 7 1001 1001 129 Jul 10 21:59 contrib -rw-r--r-- 1 1001 1001 2345 Jul 10 21:59 COPYRIGHT drwxr-xr-x 8 1001 1001 102 Jul 10 21:59 doc drwxr-xr-x 3 1001 1001 4096 Jul 10 21:59 include -rw-r--r-- 1 1001 1001 3793 Jul 10 21:59 INSTALL drwxr-xr-x 8 1001 1001 123 Jul 10 21:59 libraries -rw-r--r-- 1 1001 1001 2214 Jul 10 21:59 LICENSE -rw-r--r-- 1 1001 1001 1029 Jul 10 21:59 Makefile.in -rw-r--r-- 1 1001 1001 3594 Jul 10 21:59 README drwxr-xr-x 4 1001 1001 52 Jul 10 21:59 servers drwxr-xr-x 5 1001 1001 93 Jul 10 21:59 tests # ./configure --help | grep spec To assign environment variables (e.g., CC, CFLAGS...), specify them as Defaults for the options are specified in brackets. --help=short display options specific to this package `/usr/local/bin', `/usr/local/lib' etc. You can specify --with-odbc with specific ODBC support compiler's sysroot if not specified). # Please guide me. Thanks in Advance. Best Regards, Kaushal

2 1

requested some clean up / verification of my acls (paid)
by Marc 04 Aug '23

04 Aug '23

I have ~11 acl's that could use more attention, limiting access to what is required (to mta, system, cron). They are working, but I would to have an expert look at them. I think someone with experience could tune some things better. Anyone interested?

2 2

excluding attribute in acl
by Marc 03 Aug '23

03 Aug '23

Is it possible to specify something like allow access to all attributes - userPassword?

2 1

restricting acls more by adding a filter
by Marc 03 Aug '23

03 Aug '23

I have a ldapsearch that returns this object sendmailMTAClassName: w sendmailMTAClassValue: xxx sendmailMTAClassValue: yyy sendmailMTAClassValue: zzz objectClass: sendmailMTA objectClass: sendmailMTAClass I thought I could strengthen the acl by just appending to with a filter but if I add these below, the ldapsearch does not return anything err=32 filter=(objectClass=sendmailMTAClass) filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA)) filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA)) filter=(objectClass=sendmailMTA*) If I change the filter to this, I get the expected result again filter=(objectClass=*) Goal is to have ldapsearch only list the specific objectClasses. Or should I do this with listing only attributes.

3 6

Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
by Sean Gallagher 02 Aug '23

02 Aug '23

Hi All, This is loosely related to issue 10065 https://bugs.openldap.org/show_bug.cgi?id=10065, but can be read independently. I have devised a work-around to slapd's inability to check client names on Client certificates and am in the process of removing a proxy (haproxy) I had in front of my slapd server. I have however come across an annoying compromise and I'm offering here a suggestion on how to remove it. In particular, with the proxy, I could write rules targeting particular clients that worked, even before their initial "bind" operation by using the "sockname=" pattern in the access control rules. This does not seem possible when slapd talks directly to the clients. before the initial "bind" operation, only the IP address is available to tell clients apart, which are not very reliable. IP addresses are easily spoofed. It would be much better to use the client certificate to match against the particular client. Currently the client ID on the certificate is passed to the SASL layer with the sasl_setprop(...,SASL_AUTH_EXTERNAL,...) call. There it remains until the client performs a "bind" using the SASL EXTERNAL mechanism. At this point, the EXTERNAL client ID is used to derive a distinguished name by filtering it through the "olcAuthzRegexp". It should be noted that LDAP v3 does not require the client to perform such a bind operation. My Proposal is to expose the EXTERNAL identity to the ACL rules in a similar way to how the "real" prefix exposes the authentication identity - by creating an "external" prefix. As such, the matching rules externalanonymous externalusers externalself externaldn externaldnattr Could be used to restrict access to clients, even before or without a bind operation. To maintain naming consistency, The name passed to SASL could have the "olcAuthzRegexp" mapping applied before the ACL rule is applied. In this case, the "external" identity would be the same as the unprefixed identity, after a bind using SASL EXTERNAL mechanism had occured. This arrangement would have several advantages including: *) only exposing the userPassword to the particular client that needs it. *) enforcing client/IP address associations in a rigorous manner. *) general ACL rules for operations that do not need a "bind" operation. *) restricting SIMPLE binds to particular clients. Any Thoughts ? -- This email has been checked for viruses by AVG antivirus software. www.avg.com

6 27

updating from el7 to alpine openldap 2.6
by Marc 01 Aug '23

01 Aug '23

I am updating my ldap container and migrate from el7 to alpine. While running some test queries I noticed that the new 2.6 alpine has probably different defaults, I am getting "Size limit exceeded (4)". However this does not show in the ldap error log. What would be good loglevel config to see quickly if there is an issue with client queries? I am a little worried that if MTA's are getting incomplete results and dropping mail.

2 2

OpenLDAP with DANE
by John Scott 31 Jul '23

31 Jul '23

Hello, Thanks to the TLS callback support, I discovered that using DANE with libldap is actually really easy. OpenSSL has DANE support built-in, so all you have to do is turn it on and get the DNS records. As a proof-of-concept, I've written an example that disables the use of certificate authorities and uses DANE alone, in accordance with their preference in the TLSA record, to connect to Debian's LDAP instance. Note that Debian currently uses GnuTLS for OpenLDAP which has, in my opinion, not so good DANE support, so this code won't work. I'm offering my help to the Debian maintainers though to change that. Code is at https://salsa.debian.org/-/snippets/649

2 1

lmdb and alignment clarification
by bach＠bullno1.com 27 Jul '23

27 Jul '23

I have read a few threads on lmdb alignment but I am still not clear on what kind of padding should be done. Use case: I want to store aligned SIMD vectors in the value and operate on them directly with SIMD instructions without copying. As I understand it, lmdb guarantees 2-byte alignment. However, it can also move nodes around for tree rebalancing or page reclaiming. Thus, merely aligning the key and value might not be enough. Right now, based on my reading of the code, I'm assuming that the data layout in a leaf page is like this: [page_header][mp_ptrs]...[node_header][key][value][node_header][key][value] Basically, nodes are stored contiguously in memory with `node_header` and `key` always aligned to 2-byte. New nodes are allocated from the bottom of the page and offsets are stored/allocated into MDB_page.mp_ptrs from the top. Is this correct? If so, to ensure that `value` has a certain alignment, even when accounting for nodes being moved around, one would also have to ensure that `sizeof(node_header) + sizeof(key) + sizeof(value)` is a multiple of the alignment. Is this reasoning correct? For the overflow page, is the structure similar? Just that one single page header is used for a number of contiguous pages.

2 2

Slapd migrate from hdb to lmdb on 2.5.13
by Richard Rosner 24 Jul '23

24 Jul '23

Hi, I just upgraded our servers from Debian 11 to 12. I'm not sure if this is an upstream change, but slapd 2.5 on Debian 12 doesn't support the HDB and BDB backends, so the database needs to be migrated to LMDB. Unfortunately I neglected to check the backend in use for all instances. Our main slapd instance already used LMDB, but another instance, that's just getting a copy of that database through sync replication, was still using HDB. At first I only noticed an error during upgrade. I found a guide (https://sources.debian.org/src/openldap/2.5.13%2Bdfsg-5/debian/slapd.README… line 255 following) to do the upgrade to 2.5.x if it fails, which showed me the error. lt_dlopenext failed: (back_hdb) file not foundslapadd: could not add entry dn="cn=module{0},cn=config" (line=16): <olcModuleLoad> handler exited with 1 Closing DB... So I followed the setps under "BDB/HDB backends removed: migrating to LMDB backend". But upon trying to restore the backup again, it just told me slapadd: could not add entry dn="cn=config" (line=1): Closing DB... The first set of lines in cn\=config.ldif reads dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 71b384b4-aca9-1032-883a-d9850217023f creatorsName: cn=config createTimestamp: 20130908080726Z entryCSN: 20130908080726.757296Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130908080726Z So I'm not sure what it wants to tell me now. I already checked against the config of the main instance, made a few modifications, but the error message is the same. Here the modifications: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 71b384b4-aca9-1032-883a-d9850217023f creatorsName: cn=config createTimestamp: 20130908080726Z olcTLSCACertificateFile: /etc/ssl/certs/xyz-chain.pem olcTLSCertificateFile: /etc/ssl/certs/mail.domain.de.cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/mail.domain.de.private.pem entryCSN: 20130908080726.757296Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=mail modifyTimestamp: 20130908080726Z Could anybody tell me what exactly the problem is? Richard

2 12

SASL DIGEST-MD5 users/radius?
by Quanah Gibson-Mount 24 Jul '23

24 Jul '23

Hello, There is work underway for a new release of cyrus-sasl 2.1 series that offiicially supports OpenSSL 3.0. One issue that has been encountered is that there is no remaining supported cipher algorithms in the cyrus-sasl DIGEST-MD5 implementation, which used the historic rc4/des or 3des, when compiling against OpenSSL3. The general question for this list is, is there anyone who is still using the historic SASL DIGEST-MD5 mechanism and would not be able to move to a secure SASL mechanism such as SCRAM? Thanks! --Quanah

1 0

slapindex a 60GB mdb in reasonable time
by maud.parratt＠bjss.com 24 Jul '23

24 Jul '23

Hi, I have an openldap instance that I'd like to migrate to arm64, just loading a mdb from an amd64 instance results in all filtered queries returning empty results, which is resolved by running slapindex. I've managed to get this to complete in reasonable time using an arm64 mac and a tmpfs volume to hold a smaller test mdb in memory, but I can't replicate this performance in the cloud and I can't fit the prod mdb into tmpfs and have enough memory to work with left over. I've noticed that despite setting olcToolThreads high, it only ever pins one CPU, so I wonder if it's the difference in single threaded performance of my m1max mac vs a graviton2 instance? Is there any way to get slapindexing to use more than one cpu, or are there any other performance improvements you can suggest? I need it to complete within 6 hours maximum to fit into a change window. I'd prefer not to resort to running a parallel instance out of service and then swap the two over if it can be helped. It doesn't go at a consistent rate, but right now it looks like it'd take 2-3 days to complete. I'm passing -t and -q to slapindex. I'd appreciate any advice you could give.

4 22

In mirrormode on mode, one of the machines lost data.
by w2574694205＠sina.com 24 Jul '23

24 Jul '23

"I built two openldap servers using mirrormode on mode. After stopping the openldap processes on both servers and restarting them, one of the openldap servers lost some data while the other one remained normal. I waited for several synchronization cycles but the lost data could not be recovered. When I tried to query the lost data, I could not find it, and when I tried to add it, I was told that it already existed. Before shutting down, I took a snapshot of the machines. After restoring to the snapshot, I only started one openldap process on either of the two machines and their data was normal. However, after one data synchronization, the data on one of the machines was lost again." server01 lost some data this is server01 slapd.conf: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverID 1 syncrepl rid=150 provider=ldap://server02 bindmethod=simple binddn="cn=admin,dc=xitong,dc=qianxin,dc=com" credentials="passwd" searchbase="dc=xitong,dc=qianxin,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on this is server02 slapd.conf: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 serverID 20 syncrepl rid=150 provider=ldap://server01 bindmethod=simple binddn="cn=admin,dc=xitong,dc=qianxin,dc=com" credentials="passwd" searchbase="dc=xitong,dc=qianxin,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on This is the log when I start server02 and then start server01： server02： slapd[153895]: slap_client_connect: URI=ldap://server01 DN="cn=admin,dc=xitong,dc=qianxin,dc=com" ldap_sasl_bind_s failed (-1) slapd[153895]: do_syncrepl: rid=150 rc -1 retrying slapd[153895]: slap_client_connect: URI=ldap://server01 DN="cn=admin,dc=xitong,dc=qianxin,dc=com" ldap_sasl_bind_s failed (-1) slapd[153895]: do_syncrepl: rid=150 rc -1 retrying slapd[153895]: conn=1003 fd=11 ACCEPT from IP=server01-ip:64036 (IP=0.0.0.0:389) slapd[153895]: conn=1003 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" method=128 slapd[153895]: conn=1003 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" mech=SIMPLE bind_ssf=0 ssf=0 slapd[153895]: conn=1003 op=0 RESULT tag=97 err=0 qtime=0.000066 etime=0.000462 text= slapd[153895]: conn=1003 op=1 SRCH base="dc=xitong,dc=qianxin,dc=com" scope=2 deref=0 filter="(objectClass=*)" slapd[153895]: conn=1003 op=1 SRCH attr=* + slapd[153895]: conn=1003 op=1 syncprov_op_search: got a persistent search with a cookie=rid=150,sid=001,csn=20230716091536.511728Z#000000#001#000000 slapd[153895]: conn=1003 op=1 syncprov_findbase: searching conn=1003 op=1 syncprov_op_search: registered persistent search conn=1003 op=1 syncprov_findcsn: mode=FIND_CSN csn=20230716091536.511728Z#000000#001#000000 slapd[153895]: conn=1003 op=1 syncprov_findcsn: csn==20230716091536.511728Z#000000#001#000000 not found slapd[153895]: conn=1003 op=1 syncprov_findcsn: csn<=20230716091536.511728Z#000000#001#000000 found slapd[153895]: conn=1003 op=1 syncprov_findcsn: mode=FIND_PRESENT csn= slapd[153895]: conn=1003 op=1 syncprov_sendinfo: present syncIdSet cookie= slapd[153895]: conn=1003 op=1 INTERMEDIATE oid=1.3.6.1.4.1.4203.1.9.1.4 slapd[153895]: conn=1003 op=1 ENTRY dn="cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=system,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=security,cn=system,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=audit,cn=system,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="ou=gidnumber,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="ou=policies,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 ENTRY dn="cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com" slapd[153895]: conn=1003 op=1 syncprov_search_response: cookie=rid=150,sid=014,csn=20230716091536.629686Z#000000#001#000000 slapd[153895]: conn=1003 op=1 syncprov_sendinfo: refreshPresent cookie=rid=150,sid=014,csn=20230716091536.629686Z#000000#001#000000 slapd[153895]: conn=1003 op=1 INTERMEDIATE oid=1.3.6.1.4.1.4203.1.9.1.4 slapd[153895]: conn=1003 op=1 syncprov_search_response: detaching op slapd[153895]: do_syncrep1: rid=150 starting refresh (sending cookie=rid=150,sid=014,csn=20230716091536.629686Z#000000#001#000000) slapd[153895]: syncrepl_message_to_entry: rid=150 DN: ou=gidNumber,dc=xitong,dc=qianxin,dc=com, UUID: 11ba8ea0-b805-103d-9ccd-b18d19d8567b slapd[153895]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7fb4fa8f2700 slapd[153895]: syncrepl_entry: rid=150 inserted UUID 11ba8ea0-b805-103d-9ccd-b18d19d8567b slapd[153895]: dn_callback : entries have identical CSN ou=gidNumber,dc=xitong,dc=qianxin,dc=com 20230720112814.263879Z#000000#000#000000 slapd[153895]: syncrepl_entry: rid=150 be_search (0) slapd[153895]: syncrepl_entry: rid=150 ou=gidNumber,dc=xitong,dc=qianxin,dc=com slapd[153895]: syncrepl_entry: rid=150 entry unchanged, ignored (ou=gidNumber,dc=xitong,dc=qianxin,dc=com) slapd[153895]: syncrepl_message_to_entry: rid=150 DN: cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com, UUID: 4320059e-bb3c-103d-8a4c-37ca95023e01 slapd[153895]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7fb4fa8f2700 slapd[153895]: syncrepl_entry: rid=150 inserted UUID 4320059e-bb3c-103d-8a4c-37ca95023e01 slapd[153895]: dn_callback : entries have identical CSN cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com 20230720112815.295348Z#000000#000#000000 slapd[153895]: syncrepl_entry: rid=150 be_search (0) slapd[153895]: syncrepl_entry: rid=150 cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com slapd[153895]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com) slapd[153895]: do_syncrep2: rid=150 LDAP_RES_INTERMEDIATE - REFRESH_DELETE slapd[153895]: do_syncrep1: rid=150 finished refresh slapd[153895]: do_syncrepl: rid=150 rc -1 retrying slapd[153895]: conn=1003 op=2 UNBIND slapd[153895]: conn=1003 fd=11 closed server01: slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.472410Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.472535Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.474296Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.474368Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.474657Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.474825Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.474897Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.474932Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.474973Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475011Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475037Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475128Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475154Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475183Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475217Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475241Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475270Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475351Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475392Z#000000#001#000000 manage=0 slapd[85336]: slap_get_csn: conn=-1 op=0 generated new csn=20230720114843.475414Z#000000#001#000000 manage=0 slapd[85336]: syncprov_db_open: starting syncprov for suffix dc=xitong,dc=qianxin,dc=com slapd[85336]: slapd starting slapd[85336]: do_syncrep1: rid=150 starting refresh (sending cookie=rid=150,sid=001,csn=20230716091536.511728Z#000000#001#000000) slapd[85336]: do_syncrep2: rid=150 LDAP_RES_INTERMEDIATE - SYNC_ID_SET slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com, UUID: 11ab4eb8-b805-103d-972c-b9f3032e5223 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 be_add cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com (68) slapd[85336]: dn_callback : new entry is older than ours cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com ours 20230716091536.553583Z#000000#001#000000, new 20230716091536.513653Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com, UUID: 11acb24e-b805-103d-972d-b9f3032e5223 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 be_add cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com (68) slapd[85336]: dn_callback : new entry is older than ours cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com ours 20230716091536.561584Z#000000#001#000000, new 20230716091536.522757Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com, UUID: 11ade9f2-b805-103d-972e-b9f3032e5223 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 be_add cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com (68) slapd[85336]: dn_callback : new entry is older than ours cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com ours 20230716091536.569582Z#000000#001#000000, new 20230716091536.530734Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com, UUID: 11ae9050-b805-103d-972f-b9f3032e5223 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 be_add cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com (68) slapd[85336]: dn_callback : new entry is older than ours cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com ours 20230716091536.573931Z#000000#001#000000, new 20230716091536.534994Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com, UUID: 11af3d48-b805-103d-9730-b9f3032e5223 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 be_add cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com (68) slapd[85336]: dn_callback : new entry is older than ours cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com ours 20230716091536.579566Z#000000#001#000000, new 20230716091536.539423Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=system,dc=xitong,dc=qianxin,dc=com, UUID: 11b08284-b805-103d-9731-b9f3032e5223 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 be_add cn=system,dc=xitong,dc=qianxin,dc=com (68) slapd[85336]: dn_callback : new entry is older than ours cn=system,dc=xitong,dc=qianxin,dc=com ours 20230716091536.591594Z#000000#001#000000, new 20230716091536.547746Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=system,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com, UUID: 11b12d4c-b805-103d-9732-b9f3032e5223 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 be_add cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com (68) slapd[85336]: dn_callback : new entry is older than ours cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com ours 20230716091536.595832Z#000000#001#000000, new 20230716091536.552121Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=security,cn=system,dc=xitong,dc=qianxin,dc=com, UUID: 11b885c4-b805-103d-9ccb-b18d19d8567b slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: dn_callback : entries have identical CSN cn=security,cn=system,dc=xitong,dc=qianxin,dc=com 20230716091536.600260Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=security,cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=security,cn=system,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=audit,cn=system,dc=xitong,dc=qianxin,dc=com, UUID: 11b95bf2-b805-103d-9ccc-b18d19d8567b slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: dn_callback : entries have identical CSN cn=audit,cn=system,dc=xitong,dc=qianxin,dc=com 20230716091536.605744Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=audit,cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=audit,cn=system,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: ou=gidNumber,dc=xitong,dc=qianxin,dc=com, UUID: 11ba8ea0-b805-103d-9ccd-b18d19d8567b slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: dn_callback : new entry is older than ours ou=gidNumber,dc=xitong,dc=qianxin,dc=com ours 20230720112814.263879Z#000000#000#000000, new 20230716091536.613594Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 ou=gidNumber,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (ou=gidNumber,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: ou=policies,dc=xitong,dc=qianxin,dc=com, UUID: 11bc5082-b805-103d-9cce-b18d19d8567b slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: dn_callback : entries have identical CSN ou=policies,dc=xitong,dc=qianxin,dc=com 20230716091536.625081Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 ou=policies,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (ou=policies,dc=xitong,dc=qianxin,dc=com) slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com, UUID: 11bd03ec-b805-103d-9ccf-b18d19d8567b slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: dn_callback : entries have identical CSN cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com 20230716091536.629686Z#000000#001#000000 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com) slapd[85336]: do_syncrep2: rid=150 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT slapd[85336]: do_syncrep2: rid=150 cookie=rid=150,sid=014,csn=20230716091536.629686Z#000000#001#000000 slapd[85336]: do_syncrep1: rid=150 finished refresh slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11a73b5c-b805-103d-9cbd-b18d19d8567b, dn dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11a9b7b0-b805-103d-9cbe-b18d19d8567b, dn cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11ab0386-b805-103d-9cbf-b18d19d8567b, dn cn=ALL,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=ALL,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11ace4c6-b805-103d-9cc0-b18d19d8567b, dn cn=work,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=work,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11ad87b4-b805-103d-9cc1-b18d19d8567b, dn cn=yarn,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=yarn,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11aebb70-b805-103d-9cc2-b18d19d8567b, dn cn=mr,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=mr,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b01e84-b805-103d-9cc3-b18d19d8567b, dn cn=hbase,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=hbase,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b16668-b805-103d-9cc4-b18d19d8567b, dn cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b29f06-b805-103d-9cc5-b18d19d8567b, dn cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b3d75e-b805-103d-9cc6-b18d19d8567b, dn cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b48140-b805-103d-9cc7-b18d19d8567b, dn cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b55d68-b805-103d-9cc8-b18d19d8567b, dn cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b73340-b805-103d-9cc9-b18d19d8567b, dn cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=system,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 nonpresent UUID 11b7d8c2-b805-103d-9cca-b18d19d8567b, dn cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 adding entry cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com to non-present list slapd[85336]: nonpresent_callback: rid=150 present UUID 11b885c4-b805-103d-9ccb-b18d19d8567b, dn cn=security,cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 present UUID 11b95bf2-b805-103d-9ccc-b18d19d8567b, dn cn=audit,cn=system,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 present UUID 11bc5082-b805-103d-9cce-b18d19d8567b, dn ou=policies,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 present UUID 11bd03ec-b805-103d-9ccf-b18d19d8567b, dn cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com slapd[85336]: nonpresent_callback: rid=150 had 15 items left in the list slapd[85336]: slap_queue_csn: queueing 0x7f20fc10fd60 20230716091536.629686Z#000000#001#000000 slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b7d8c2-b805-103d-9cca-b18d19d8567b slapd[85336]: slap_graduate_commit_csn: removing 0x7f20fc10fd60 20230716091536.629686Z#000000#001#000000 slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=admin,cn=system,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=system,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=system,dc=xitong,dc=qianxin,dc=com (66) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=system,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_checkpoint: running checkpoint slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b73340-b805-103d-9cc9-b18d19d8567b slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b55d68-b805-103d-9cc8-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=noah,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b48140-b805-103d-9cc7-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=s3,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b3d75e-b805-103d-9cc6-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=flume,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b29f06-b805-103d-9cc5-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=kafka,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b16668-b805-103d-9cc4-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=hive,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=hbase,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11b01e84-b805-103d-9cc3-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=hbase,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=mr,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11aebb70-b805-103d-9cc2-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=mr,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=yarn,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11ad87b4-b805-103d-9cc1-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=yarn,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=work,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11ace4c6-b805-103d-9cc0-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=work,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=ALL,cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11ab0386-b805-103d-9cbf-b18d19d8567b slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=ALL,cn=default,dc=xitong,dc=qianxin,dc=com (0) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete cn=default,dc=xitong,dc=qianxin,dc=com (66) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=cn=default,dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11a9b7b0-b805-103d-9cbe-b18d19d8567b slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: syncrepl_del_nonpresent: rid=150 be_delete dc=xitong,dc=qianxin,dc=com (66) slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: conn=-1 op=0 syncprov_add_slog: adding csn=20230716091536.629686Z#000000#001#000000 to sessionlog, uuid=11a73b5c-b805-103d-9cbd-b18d19d8567b slapd[85336]: slap_queue_csn: queueing 0x7f20fc111370 20230716091536.629686Z#000000#001#000000 slapd[85336]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=dc=xitong,dc=qianxin,dc=com on opc=0x7f20fc006268 slapd[85336]: slap_graduate_commit_csn: removing 0x7f20fc111370 20230716091536.629686Z#000000#001#000000 slapd[85336]: conn=1000 fd=14 ACCEPT from IP=server02:52108 (IP=0.0.0.0:389) slapd[85336]: conn=1000 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" method=128 slapd[85336]: conn=1000 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" mech=SIMPLE bind_ssf=0 ssf=0 slapd[85336]: conn=1000 op=0 RESULT tag=97 err=0 qtime=0.000023 etime=0.000186 text= slapd[85336]: conn=1000 op=1 SRCH base="dc=xitong,dc=qianxin,dc=com" scope=2 deref=0 filter="(objectClass=*)" slapd[85336]: conn=1000 op=1 SRCH attr=* + slapd[85336]: conn=1000 op=1 syncprov_op_search: got a persistent search with a cookie=rid=150,sid=014,csn=20230716091536.629686Z#000000#001#000000 slapd[85336]: conn=1000 op=1 syncprov_findbase: searching slapd[85336]: conn=1000 op=1 syncprov_op_search: registered persistent search slapd[85336]: conn=1000 op=1 ENTRY dn="ou=gidnumber,dc=xitong,dc=qianxin,dc=com" slapd[85336]: conn=1000 op=1 syncprov_search_response: Entry cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com CSN 20230716091536.629686Z#000000#001#000000 older or equal to ctx 20230716091536.629686Z#000000#001#000000 slapd[85336]: conn=1000 op=1 ENTRY dn="cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com" slapd[85336]: conn=1000 op=1 syncprov_sendinfo: refreshDelete cookie= slapd[85336]: conn=1000 op=1 INTERMEDIATE oid=1.3.6.1.4.1.4203.1.9.1.4 slapd[85336]: conn=1000 op=1 syncprov_search_response: detaching op slapd[85336]: do_syncrep2: rid=150 cookie=rid=150,sid=014 slapd[85336]: syncrepl_message_to_entry: rid=150 DN: ou=gidNumber,dc=xitong,dc=qianxin,dc=com, UUID: 11ba8ea0-b805-103d-9ccd-b18d19d8567b slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=(none) tid 0x7f21088a2700 slapd[85336]: dn_callback : entries have identical CSN ou=gidNumber,dc=xitong,dc=qianxin,dc=com 20230720112814.263879Z#000000#000#000000 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 ou=gidNumber,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (ou=gidNumber,dc=xitong,dc=qianxin,dc=com) slapd[85336]: do_syncrep2: rid=150 cookie=rid=150,sid=014 slapd[85336]: syncrepl_message_to_entry: rid=150 DN: cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com, UUID: 4320059e-bb3c-103d-8a4c-37ca95023e01 slapd[85336]: syncrepl_entry: rid=150 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f21090a3700 slapd[85336]: dn_callback : entries have identical CSN cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com 20230720112815.295348Z#000000#000#000000 slapd[85336]: syncrepl_entry: rid=150 be_search (0) slapd[85336]: syncrepl_entry: rid=150 cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com slapd[85336]: syncrepl_entry: rid=150 entry unchanged, ignored (cn=test011,cn=default,dc=xitong,dc=qianxin,dc=com) This is the log printed by openldap when I try to get data from other machines: slapd[85336]: conn=1001 fd=15 ACCEPT from IP=Myserver:56212 (IP=0.0.0.0:389) slapd[85336]: conn=1001 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" method=128 slapd[85336]: conn=1001 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" mech=SIMPLE bind_ssf=0 ssf=0 slapd[85336]: conn=1001 op=0 RESULT tag=97 err=0 qtime=0.000043 etime=0.000286 text= Jul 20 19:49:20 4txf46unrccv slapd[85336]: conn=1001 op=1 UNBIND Jul 20 19:49:20 4txf46unrccv slapd[85336]: conn=1001 fd=15 closed Jul 20 19:49:20 4txf46unrccv slapd[85336]: conn=1002 fd=15 ACCEPT from IP=Myserver:56214 (IP=0.0.0.0:389) Jul 20 19:49:20 4txf46unrccv slapd[85336]: conn=1002 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" method=128 Jul 20 19:49:20 4txf46unrccv slapd[85336]: conn=1002 op=0 BIND dn="cn=admin,dc=xitong,dc=qianxin,dc=com" mech=SIMPLE bind_ssf=0 ssf=0 Jul 20 19:49:20 4txf46unrccv slapd[85336]: conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000047 etime=0.000188 text= slapd[85336]: conn=1002 op=1 SRCH base="dc=xitong,dc=qianxin,dc=com" scope=1 deref=0 filter="(objectClass=*)" slapd[85336]: conn=1002 op=1 SRCH attr=hasSubordinates objectclass entryFlags userAccountControl lockouttime msDS-UserAccountDisabled ms-DS-UserAccountAutoLocked slapd[85336]: conn=1002 op=1 ENTRY dn="ou=policies,dc=xitong,dc=qianxin,dc=com" slapd[85336]: conn=1002 op=1 ENTRY dn="ou=gidnumber,dc=xitong,dc=qianxin,dc=com" slapd[85336]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000043 etime=0.000524 nentries=2 text= slapd[85336]: conn=1002 op=2 SRCH base="ou=policies,dc=xitong,dc=qianxin,dc=com" scope=1 deref=0 filter="(objectClass=*)" slapd[85336]: conn=1002 op=2 SRCH attr=hasSubordinates objectclass entryFlags userAccountControl lockouttime msDS-UserAccountDisabled ms-DS-UserAccountAutoLocked slapd[85336]: conn=1002 op=2 ENTRY dn="cn=default,ou=policies,dc=xitong,dc=qianxin,dc=com" slapd[85336]: conn=1002 op=2 SEARCH RESULT tag=101 err=0 qtime=0.000045 etime=0.000417 nentries=1 text=

1 1

question on include ./acls/*.conf
by cYuSeDfZfb cYuSeDfZfb 20 Jul '23

20 Jul '23

Hi, We're wondering: is there some clever way to include any number of .conf files that exist in a certain directory? Something like, in slapd.conf: include /opt/symas/etc/openldap/acls/*.conf This would allow us to simply add & remove.conf files under that directory, and restart openldap. We're now getting errors: /opt/symas/etc/openldap/slapd.conf: line 109 (include /opt/symas/etc/openldap/acls/*.conf) could not stat config file " /opt/symas/etc/openldap/acls/*.conf": No such file or directory Is that way of configuring (wildcard includes) not supported..? Or are we missing something else? Is there some other way of doing this..?

3 3

Re: python-lmdb crashing ( d <= env->me_pglast' failed in mdb_freelist_save()) - unusable 300gb database
by mark jayson 19 Jul '23

19 Jul '23

Yep, my bad. LMDB version bundled is 0.9.29. >>> print(lmdb.version()) (0, 9, 29) On Wed, Jul 19, 2023 at 2:11 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, July 19, 2023 2:59 AM +0800 mark jayson > <mark.alvarez123(a)gmail.com> wrote: > > > > > The lmdb version I'm using is: > > > > Python 3.10.6 > > > > lmdb==1.4.1 > > I'm going to guess that's the version of the python LMDB library. But the > deeper question is what is the version of the LMDB C library it is linked > to? > > --Quanah > > > > >

1 0

python-lmdb crashing ( d <= env->me_pglast' failed in mdb_freelist_save()) - unusable 300gb database
by mark jayson 18 Jul '23

18 Jul '23

Hello, I've created a program that writes data to an lmdb database using python bindings. I've written about 300gb worth of data but when I was re-reading the database by running my script again, it crashes immediately. Did a backtrace in gdb and this is what I got: Really have no clue what's going on here. I suspect that the server has rebooted (or was rebooted by someone while I was running the script but I thought lmdb is crash-proof. Do you have any idea how to best troubleshoot this? The database is worth 300gb+ so it's not easy to share it, not to mention it contains sensitive information. Starting program: /usr/bin/python3 read_events.py -d jul012022-23/ [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". build/lib/mdb.c:3274: Assertion 'len >= 0 && id <= env->me_pglast' failed in mdb_freelist_save() Program received signal SIGABRT, Aborted. __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350283264) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) backtrace #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350283264) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140737350283264) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140737350283264, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007ffff7c96476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007ffff7c7c7f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007ffff62fb3e2 in mdb_assert_fail (env=0x5555565b49f0, expr_txt=expr_txt@entry=0x7ffff62fe308 "len >= 0 && id <= env->me_pglast", func=func@entry=0x7ffff62fe930 <__func__.13> "mdb_freelist_save", line=line@entry=3274, file=0x7ffff62fe010 "build/lib/mdb.c") at build/lib/mdb.c:1545 #6 0x00007ffff62f10df in mdb_freelist_save (txn=0x555556752950) at build/lib/mdb.c:3274 #7 mdb_txn_commit (txn=0x555556752950) at build/lib/mdb.c:3646 #8 0x00007ffff62f369b in txn_db_from_name (env=env@entry=0x7ffff61c8090, name=<optimized out>, flags=262144) at lmdb/cpython.c:1017 #9 0x00007ffff62f6e1d in env_open_db (self=0x7ffff61c8090, args=<optimized out>, kwds=<optimized out>) at lmdb/cpython.c:1665 #10 0x00005555556b23a9 in ?? () #11 0x0000555555699c14 in _PyEval_EvalFrameDefault () #12 0x0000555555696176 in ?? () #13 0x000055555578bc56 in PyEval_EvalCode () #14 0x00005555557b8b18 in ?? () #15 0x00005555557b196b in ?? () #16 0x00005555557b8865 in ?? () #17 0x00005555557b7d48 in _PyRun_SimpleFileObject () #18 0x00005555557b7a43 in _PyRun_AnyFileObject () #19 0x00005555557a8c3e in Py_RunMain () #20 0x000055555577ebcd in Py_BytesMain () #21 0x00007ffff7c7dd90 in __libc_start_call_main (main=main@entry=0x55555577eb90, argc=argc@entry=14, argv=argv@entry=0x7fffffffe378) at ../sysdeps/nptl/libc_start_call_main.h:58 #22 0x00007ffff7c7de40 in __libc_start_main_impl (main=0x55555577eb90, argc=14, argv=0x7fffffffe378, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe368) at ../csu/libc-start.c:392 #23 0x000055555577eac5 in _start () (gdb) client_loop: send disconnect: Broken pipe For what it's worth, this is how I've opened the database environment: dbenv = lmdb.open(db_dir, map_size=1099511627776, max_dbs=11, readahead=False)

3 3

Different loglevels based on IP prefix?
by Dick Visser 18 Jul '23

18 Jul '23

Hi Is there any way to configure slapd to log queries from certain addresses differently? I'm asking because we would like to have detailed logging for real traffic, but the loglevel we picked (stats + sync) our health checks cause a lot of noise. Since the health checks are located at specific IP addresses/prefixes, ideally we could have less or no logging for those. thanks Dick Visser

2 1

Re: [EXT] Re: pwdAccountLockedTime does not have any impact
by CVZ 17 Jul '23

17 Jul '23

Hi Everybody, Tanks Clément and tempo for your replies. Sorry for my late reply, last week was really busy. I confirm that applying ppolicy configuration, its now working fine. Ulrich, bellow, you have all the steps (Ubuntu with 2.5.14 openldap) Thanks / Merci Best Damien #configppolicy.ldif dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=abc,dc=org sudo -u openldap slapadd -n0 -l configppolicy.ldif ################### # Policies.ldif dn: ou=policies,dc=abc,dc=org objectClass: organizationalUnit ou: policies sudo -u openldap slapadd -n1 -l Policies.ldif ################### # Policies2.ldif dn: cn=default,ou=policies,dc=abc,dc=org objectClass: pwdPolicy objectClass: organizationalRole cn: default pwdAttribute: userPassword pwdMinAge: 0 pwdMinLength: .... pwdCheckQuality: 2 pwdMaxFailure: ... pwdLockout: TRUE pwdLockoutDuration: .... ... sudo -u openldap slapadd -n1 -l Policies2.ldif And restart slapd service On 12/7/23 15:42, Windl, Ulrich wrote: > Hi! > > You mean something like this?: > dn: cn=PP-Default,dc=policies,dc=...,dc=de > changetype: add > objectClass: namedObject > objectClass: pwdPolicy > cn: PP-Default > pwdAllowUserChange: TRUE > pwdAttribute: userPassword > pwdCheckQuality: 1 > pwdExpireWarning: 604800 > pwdFailureCountInterval: 1209600 > pwdLockout: TRUE > pwdLockoutDuration: 1800 > pwdMaxFailure: 10 > pwdMinAge: 30 > pwdMinLength: 8 > pwdMustChange: TRUE > pwdSafeModify: FALSE > > This is for an older version (obviously), however... > > Regards, > Ulrich > > -----Original Message----- > From: tempo(a)net-c.com <tempo(a)net-c.com> > Sent: Tuesday, July 11, 2023 6:02 PM > To: bremont(a)cvz.es; openldap-technical(a)openldap.org > Subject: [EXT] Re: pwdAccountLockedTime does not have any impact > > Hi, > > Could you show us your ppolicy settings please ? > > As far as I remember, you need at least pwdLockout set to TRUE in order to have the attribute pwdAccountLockedTime checked. > > > > > De : CVZ <bremont(a)cvz.es> > À : openldap-technical(a)openldap.org > Sujet : pwdAccountLockedTime does not have any impact > Date : 11/07/2023 11:41:41 Europe/Paris > > > > Hi Everybody, <https://urldefense.com/v3/__https://stackoverflow.com/posts/76341444/timeli… > > > Sorry, we are figghting with pwdAccountLockedTime. > > > I want to use "pwdAccountLockedTime" attribute to automatically lock an account using OpenLDAP (v.2.5.14). Whatever the value in the field, the account is never locked. > > I first started by activating the "ppolicy" module using slapadd and a ppolicy-module.ldif file suh as mentioned here "https://urldefense.com/v3/__https://stackoverflow.com/questions/49257247/ho… " <https://urldefense.com/v3/__https://stackoverflow.com/questions/49257247/ho… > , then I have checked that the module is loaded and I did not have any problem: > > $ sudo slapcat -n 0 | grep olcModuleLoad | grep ppolicy > olcModuleLoad: {0}ppolicy > > > Then, I have extended the LDAP scheme to allow using of ppolicy attributes such as "pwdAccountLockedTime". I have set it to "00000101000000Z" in order to lock permanently an account (to check if it was working). But I still can connect (using LDAP Admin tools) with the account that was supposed to be locked. > > We also tried to modify the value > > > dn: uid=... > replace: pwdAccountLockedTime > pwdAccountLockedTime: 20221021135537Z > > And even with dates in the future, but we are still able to connect. With whoami command, or from a SOGo webmail connected to the LDAP server. > > > Any idea? > Thank in advance for your help. > > > Best > Damien > >

1 0

Openldap 2.4 : Replication issue
by ramprasad.sharma＠orange.com 14 Jul '23

14 Jul '23

Dear Team, I'm facing a weird issue : My env is : root@repnode:~# ldap-utils/focal-security,focal-updates,now 2.4.49+dfsg-2ubuntu1.9 amd64 [installed,automatic] libldap-2.4-2/focal-security,focal-updates,now 2.4.49+dfsg-2ubuntu1.9 amd64 [installed,automatic] libldap-common/focal-security,focal-updates,now 2.4.49+dfsg-2ubuntu1.9 all [installed,automatic] sssd-ldap/focal-security,focal-updates,now 2.2.3-3ubuntu0.12 amd64 [installed,automatic] root@repnode:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal root@repnode:~# Earlier, I was using two replications, without any filter and attrs..both were working fine.. But I got the requirement to select specific attributes from the master node. I applied filters and attrs based on the requirement. ( I Checked it in ldapsearch and it was working fine ) ( searchbase in both replications are different ) Replication highlighted in green is working fine.. But the replication highlighted in red is not working when applied filters , attrs or both ( without filters and attrs , it will replicating full data of that subtree ). syncrepl rid=AAA provider=ldaps://master.node:636/ bindmethod=simple filter="(objectClass=posixAccount)" attrs="cn,uid,x1sshPubKey,x2sshPubKey,uidNumber,gidNumber,homeDirectory,gecos,loginShell,description,sshPublicKey" binddn="cn=rep,dc=di-diod,dc=tech" credentials=XX searchbase="ou=people,dc=di-diod,dc=tech" scope=sub schemachecking=on type=refreshOnly interval=00:00:00:01 retry="30 5 300 3" # Replication source # The replication source must declare before mirrormode syncrepl rid=BBB provider=ldaps://master.node:636/ bindmethod=simple binddn="cn=rep,dc=di-diod,dc=tech" credentials=XX searchbase="ou=groups,dc=di-diod,dc=tech" filter="(objectClass=posixGroup)" attrs="cn,gidNumber,memberUid" scope=sub schemachecking=on type=refreshOnly interval=00:00:00:01 retry="30 5 300 3" I'm wondering, what I've done wrong here..Please help me for this issue. Warm Regards, Ram Prasad Sharma +91-9871192778 Orange Restricted ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 1

Rotating olcRootPW
by thomaswilliampritchard＠gmail.com 14 Jul '23

14 Jul '23

Hi, We have a 3 node multi master replication configuration setup with many consumers replicating from all 3 provider nodes. The consumers and providers replicate the from the MDB tree dc=example,dc=com. They do not replicate their config databases. The root password we are rotating is for cn=admin,dc=example,dc=com. Upon updating the olcRootPW we see the provider where the password was updated commit a new CSN and then syncrepl seems to fail for connected consumers with slapd[9227]: conn=1439 op=1 syncprov_op_search: consumer 2102 state 20230712210938.878334Z#000000#836#000000 is newer than provider 2102 state 20230712210402.018624Z#000000#836#000000 It seems as if the consumers reconnect with a state newer than the provider that just committed a new CSN for the new root password? It did not seem like the root password was replicated across the cluster however which I imagine is a deliberate choice to not replicate root db DNs. Is there a recommended workflow to rotate the root credential for a replicated database to avoid syncrepl disruption? OpenLDAP 2.4.56 (we are working to upgrade to OpenLDAP 2.5 LTS)

3 3

Re: Problem with restoring using ldif, OpenLDAP 2.6.3
by awsome jang 13 Jul '23

13 Jul '23

Hello, Thank you for your response - it was very helpful. Bug is registered with a solution proposal: https://bugs.openldap.org/show_bug.cgi?id=10077 I also saw that entryCSN can be negative as well but the proposed solution should fix the problem. createTimestamp: 20230110130503 entryCSN: 20230110130503.*-060060Z*#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int I was wondering how to handle this issue in case there is already this negative context CSN in the database? So scenario would be as follow: 1) do a backup create ldif (contains contextCSN: 20230410125515*.-401856Z* #000000#000#000000 or entryCSN with minus) 2) do an update of openldap, 3) restore backup from ldif. In this case restoring backup ends up with an error so there is no possibility to restore the backup database. Could you please provide some guidance on how to clean up this corruption in a proper way? Should I remove the line with negative contextCSN/entryCSN or remove the minus in the ldif file to restore the backup? Or is there any other way? Configuration uses provider and consumer with replication. Thank you in advance for your response, BR, Peter Am Mi., 14. Juni 2023 um 17:09 Uhr schrieb Quanah Gibson-Mount < quanah(a)fast-mail.org>: > > > --On Tuesday, June 13, 2023 12:11 PM +0200 awsome jang > <jangawsome(a)gmail.com> wrote: > > > > > Hello, > > > > I am running openldap 2.6.3 configured as provider-consumer and I would > > like to do backup/restore of the database on the provider. > > > > I create a backup on working sladp using command(ends with success, file > > created): > > slapd.exe –T cat –f slapd.conf –l backup.ldif > > > > And then trying to load it using slapd command into a new > > database(restore): > > slapd.exe -T add -f slapd.conf -l backup.ldif -d -1 > > > > Command ends with: > > . > > creatorsName: uid=root,ou=invalid,dc=vmbox,dc=int > > createTimestamp: 20230410111050Z > > entryCSN: 20230410111051.368528Z#000000#000#000000 > > modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int > > modifyTimestamp: 20230410111050Z > > contextCSN: 20230410125515.-401856Z#000000#000#000000 > > > This appears to be a bug with generating the CSN on windows, likely due to > some type of overflow. Can you please file a bug report at > https://bugs.openldap.org > > Thanks! > > Regards, > Quanah > > >

3 3

auditlog to syslog
by cYuSeDfZfb cYuSeDfZfb 13 Jul '23

13 Jul '23

Hi, Playing with openldap 2.5 auditlog. Logging to a file works nicely. We wonder (as we use graylog for syslog aggregation for all (LDAP) servers) ... Is it possible to process the auditlogs through syslog? Tip for all: we have solved so many problems just by searching through graylog... if you don't use graylog (or some other log aggregation tool)... consider implementing it!

3 2

RE: [EXT] Re: CSN too old on each MOD, on working 4-node multi-master
by Quanah Gibson-Mount 12 Jul '23

12 Jul '23

--On Wednesday, July 12, 2023 2:13 PM +0000 "Windl, Ulrich" <u.windl(a)ukr.de> wrote: > Hi! > > I always wondered (assuming you have four MM servers A-D): > Assuming A has a local change, so it will sent them to B-D > When B receives a change from A, it will "check and perform", then > sending the changes to C and D (not back to A, right?) Likewise for C > and D > However B-D will send out more changes, but not to A (right?): > B->C, B->D > C->B, C->D > D->B, D->C > What will B (and C and D) do when receiving A's change via C for the > second time: Will it ignore the change, but still send out to other > (non-originating) nodes, or will it just "swallow" the change? I guess > it will "swallow", because otherwise the messages would circulate > forever, right? Correct, they discard ops they've already received. Which was the point of the log message referenced originally. --Quanah

1 0

LTB packages available for OpenLDAP 2.5.15 and 2.6.5
by Clément OUDOT 12 Jul '23

12 Jul '23

Hello, for people interested, the LDAP Tool Box project has published the packages for OpenLDAP 2.5.15 and 2.6.5. https://projects.ow2.org/view/ldaptoolbox/ltb-openldap-2-5-15-and-2-6-5-pac… -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

pwdAccountLockedTime does not have any impact
by CVZ 11 Jul '23

11 Jul '23

Hi Everybody, <https://stackoverflow.com/posts/76341444/timeline> Sorry, we are figghting with pwdAccountLockedTime. I want to use "pwdAccountLockedTime" attribute to automatically lock an account using OpenLDAP (v.2.5.14). Whatever the value in the field, the account is never locked. I first started by activating the "ppolicy" module using slapadd and a ppolicy-module.ldif file suh as mentioned here "https://stackoverflow.com/questions/49257247/how-to-activate-ppolicy-module…", then I have checked that the module is loaded and I did not have any problem: |$ sudo slapcat -n 0 | grep olcModuleLoad | grep ppolicy olcModuleLoad: {0}ppolicy | Then, I have extended the LDAP scheme to allow using of ppolicy attributes such as "pwdAccountLockedTime". I have set it to "00000101000000Z" in order to lock permanently an account (to check if it was working). But I still can connect (using LDAP Admin tools) with the account that was supposed to be locked. We also tried to modify the value dn: uid=... replace: pwdAccountLockedTime pwdAccountLockedTime: 20221021135537Z And even with dates in the future, but we are still able to connect. With whoami command, or from a SOGo webmail connected to the LDAP server. Any idea? Thank in advance for your help. Best Damien

3 2

Re: CSN too old on each MOD, on working 4-node multi-master
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Thanks for confirming what we already suspected (and hoped as well) :-) On Tue, 11 Jul 2023 at 16:54, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Tuesday, July 11, 2023 2:26 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems > > to work perfectly now. With some (highly appreciated) help from this > list. > > > > > But actually: content *is* replicated instantly (within the same second) > > and the actual served contents between the four ldap (MultiMaster) > > servers matches. > > The RID changes, and is always one of the configured replication lines, > > and the date/time on the four involved hosts is in sync. > > > > > > > > Is this 'just an informational message', and 'normal', and should we > > ignore it? Or is it something to worry about and investigate further? > > Yes, it's informational. Think of it this way: > > Server A receives the modification. Servers B, C, D, replicate the change. > Server A sees that a change was made on Server B, then sees it's too old > and discards it. Same happens when Server A sees the change show up on > Servers C & D as well. And same thing happens for B with servers C & D, > and Server C with B & D, etc. The replication protocol can be very chatty > with MMR because it's constantly noting it is skipping changes it already > received. > > --Quanah > > > >

1 0

CSN too old on each MOD, on working 4-node multi-master
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Hi, We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems to work perfectly now. With some (highly appreciated) help from this list. However, there is one observation we don't understand, that we would appreciate feedback on. On directory edits, such as a password change, using the rootDN: ldappasswd -H ldaps://ldap01.company.com -D "cn=admin,o=company,c=com" -W -S "uid=username,ou=Users,o=company,c=com" New password: <new_userpw> Re-enter new password: <new_userpw> Enter LDAP Password: <very_secret_root_pw> we always receive several (mostly three, sometimes four) of these messages instantly: do_syncrep2: rid=212 CSN too old, ignoring 20230710140929.887114Z#000000#0de#000000 (uid=username,ou=Users,o=company,c=com)" But actually: content *is* replicated instantly (within the same second) and the actual served contents between the four ldap (MultiMaster) servers matches. The RID changes, and is always one of the configured replication lines, and the date/time on the four involved hosts is in sync. Is this 'just an informational message', and 'normal', and should we ignore it? Or is it something to worry about and investigate further? In the latter case, of course I will share our configs, which are taken from https://www.openldap.org/doc/admin25/replication.html#N-Way%20Multi-Master As otherwise everything seems to be working correctly, I don't expect major issues there. (but again: of course willing to share!)

2 1

Re: trying to understand SID portion in contextCSN
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Hi Quanah, Thanks again for your answer. From what you have written, we understand now that we should not aim for four identical timestamps in contextCSN attributes on each node. As contextCSN is updated (as you said) only when a server receives a direct write. (and NOT for writes received through replication) So, as long as the contextCSN output across all four MM-ldap nodes is identical, replication is doing it's thing. Specifically, from my original post: > contextCSN: 20230622151102.137085Z#000000#001#000000 > contextCSN: 20230622151105.174343Z#000000#002#000000 > contextCSN: 20230627112536.529432Z#000000#0dd#000000 > contextCSN: 20230627112536.529512Z#000000#0de#000000 The first two servers (001/002) are just as up-to-date as the last two, only: more recent writes have come into the cluster through the 0de/0dd servers. I have written a script to compare actual ldap served content, and that confirms that they all serve the same data. If any of the above is wrong, I'd appreciate to be corrected :-) On Wed, 5 Jul 2023 at 17:09, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, July 5, 2023 11:17 AM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > serverID 222 ldaps://ldapm01.company.com > > serverID 221 ldaps://ldapm02.company.com > > serverID 212 ldaps://ldapm03.company.com > > serverID 211 ldaps://ldapm04.company.com > > > > And when I (quick and dirty) check contextCSN using slapcat (I know that > > ldapsearch is the better way) I get: > > > > [root@ldapm04 ~]# slapcat | grep contextcsn -i > > contextCSN: 20180917142109.765066Z#000000#000#000000 > > contextCSN: 20230622151102.137085Z#000000#001#000000 > > contextCSN: 20230622151105.174343Z#000000#002#000000 > > contextCSN: 20230627112536.529432Z#000000#0dd#000000 > > contextCSN: 20230627112536.529512Z#000000#0de#000000 > > > > The first 2018 contextCSN is irrelevant (it has alwas been there, and I > > should probably try to get rid of it) but the last four seem to be the > > "actual" configured replication 'lines' on each node to the other three, > > like this: > > > > > > Yet: all info I can find tells me that the third field of contextCSN is > > "the SID". > > > > > > Can anyone explain? Are they perhaps HEX? If why the large gap between to > > consequtive pairs..? > > > Hi! > > So #000# is as you noted an old SID from when the system used single > provider. > > The SID values are indeed in hex. Your current non-zero SIDS indicate: > > You have servers with SID values 001, 002 that last received a direct > write > operation on 2023/06/22, about 3 seconds apart. > > You have servers with SID values 221 (0dd) and 222 (0de) that last > received > a direct write operation on 2023/06/27, during the same second. > > Any server that has a different SID value that has never received a direct > write operation will not appear in the list. > > Regards, > Quanah > >

3 6

OpenLDAP 2.5 + GSSAPI + Kerberos
by dbarstis＠nd.edu 06 Jul '23

06 Jul '23

Total newbie here so please be gentle. I'm trying to set up a simple ldap server that uses SASL and Kerberos for authentication. I built OpenLDAP --with-cyrus-sasl and --enable-spasswd. I have the service principal and testsaslauthd works. I used slapadd to build the initial config (from slapd.ldif) and ldapadd to define a rootdn and basedn (basically ou=people and ou=groups). Added a user (me) and a group. I have a slapd.conf file at /usr/lib/sasl2 that defines keytab: krb5.keytab, mech_list: GSSAPI, pwcheck_method: saslauthd, saslauthd_path: /run/saslauthd/mux. Running pluginviewer, I see GSSAPI. Running ldapsearch ... supportedSASLMechanisms, it returns nothing. I've found websites that talk about adding sasl-realm <Kerberos-Realm> sasl-host <ldap-host> sasl-secprops none to slapd.conf. But this isn't the same slapd.conf I mentioned above correct? And since I used slapd.ldif to do the inital load, I don't have another slapd.conf. How to I define these variables? Also, it looks like I need a direct mapping i.e. authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=people,dc=example,dc=com Where and how does that get defined? Any and all help would be greatly appreciated!

3 5

-Y external and SUSE
by Stefan Kania 06 Jul '23

06 Jul '23

Hi to all, I just installed openSUSE 15.5 and the actual symas packages. After installing OpenLDAP I could start slapd but "ldapsearch -Y external -H ldapi:///" is giving me a "can't connect to ldapserver" I found out that the ldap-socket on SUSE is (the same a on Debian systems) in /var/symas/run/ldapi and I can see: ss -lp | grep slapd u_str LISTEN 0 2048 /var/symas/run/ldapi 15214 * 0 users:(("slapd",pid=1431,fd=9)) but doing a ldapsearch: provider01:~ # ldapmodify -Y EXTERNAL -H ldapi:/// -d 5 ldap_url_parse_ext(ldapi:///) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 3 ldap_connect_to_path: Trying /run/slapd/ldapi ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_close_socket: 3 ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) You can see, that ldapsearch is looking in /run/slapd/ for the socket. How can I change this? I tested with setting a link: ln -s /var/symas/run/ldapi /run/slapd/ and ldapseach wit "external" is working. But this was only a test. After rebooting the system the link is gone. So how can I either change the behavior of the ldap-commands or changing the path where the socket will be stored? Thank's for any help

5 5

trying to understand SID portion in contextCSN
by cYuSeDfZfb cYuSeDfZfb 05 Jul '23

05 Jul '23

Hi! Trying to better understand the contextCSN attribute. ContextCSN is formatted like: TIMESTAMP#COUNT#SID#MOD My question is on the SID part: ServerID. I have the following serverID configuration in our 4-server Multi-Master PoC setup: serverID 222 ldaps://ldapm01.company.com serverID 221 ldaps://ldapm02.company.com serverID 212 ldaps://ldapm03.company.com serverID 211 ldaps://ldapm04.company.com And when I (quick and dirty) check contextCSN using slapcat (I know that ldapsearch is the better way) I get: [root@ldapm04 ~]# slapcat | grep contextcsn -i contextCSN: 20180917142109.765066Z#000000#000#000000 contextCSN: 20230622151102.137085Z#000000#001#000000 contextCSN: 20230622151105.174343Z#000000#002#000000 contextCSN: 20230627112536.529432Z#000000#0dd#000000 contextCSN: 20230627112536.529512Z#000000#0de#000000 The first 2018 contextCSN is irrelevant (it has alwas been there, and I should probably try to get rid of it) but the last four seem to be the "actual" configured replication 'lines' on each node to the other three, like this: syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand Now the actual question: contextCSN displays these SID's: 001, 002, 0dd, 0de. None of which I have configured *anywhere*. Not as a SID, not as a RID, as can be seen above. Yet: all info I can find tells me that the third field of contextCSN is "the SID". Can anyone explain? Are they perhaps HEX? If why the large gap between to consequtive pairs..? Curious :-) Thanks!

2 1

RE: [EXT] Re: What drives CPU usage spikes?
by Quanah Gibson-Mount 04 Jul '23

04 Jul '23

--On Monday, July 3, 2023 2:25 PM +0000 "Windl, Ulrich" <u.windl(a)ukr.de> wrote: > Hi! > > I'm wondering: Did you examine whether some indices might help? Those don't help with the issue being addressed in regards to accesslog databases. --Quanah

1 0

Re: [EXT] Re: Proposal to strengthen slapd EXTERNAL authentication
by Jordan Brown 30 Jun '23

30 Jun '23

On 6/29/2023 11:29 PM, Windl, Ulrich wrote: > I think there's something missing: When *creating* the certificate "It proves that the bearer owns the DN" (done by RA/CA), but when *using* the certificate (by a client) the server should still check whether the certificate matches the client. Otherwise any stolen certificate could be used to gain access from everywhere. MHO. When you say "matches the client", what do you mean? That the client's IP address maps to a name on the certificate? Remember that in DNS the mapping from IP address to name is under the control of the person who owns the IP address, not the person who owns the name. Remember also that the client may be behind a NAT that hides their IP address. Finally, remember that the client may legitimately change its IP address and DNS name (if any) from time to time as it is moved from one location to another (think phone, or laptop, or desktop moving from one office to another) or networks are reconfigured around it. This is asymmetric from the more common server authentication. For server authentication, the server has a stable name, and that name was supplied by the human and so can be trusted (more or less) and checked against the certificate. In fact, that human-supplied name serves exactly the same purpose as an "authorized DN" list: it says which certificates are acceptable. Net... you're absolutely right, if somebody steals your certificate - more precisely, your private key - they can use it to gain access. It is exactly as for a password: a username and password authenticates the user, but if somebody steals your password, they can masquerade as you. Depending on your particular scenario, it might be appropriate to have *additional* checks - acceptable networks, et cetera - or require multiple factors (e.g. certificate plus password). Those additional checks are not part of the certificate-based authentication process. Somebody stealing your private key may well be Game Over. Don't let people steal it. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

1 0

Re: What drives CPU usage spikes?
by David Hawes 30 Jun '23

30 Jun '23

On Fri, 23 Jun 2023 at 12:04, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > In our 2.6.4 deployment, we had a significant spike in CPU usage one day > last week that lasted approximately 2 hours (8 AM UTC to 10 AM UTC). > During this time, some clients started timing out when talking to the LDAP > service, and search response times spiked as well, up to 9.5 seconds on > searches that normally take < 3 seconds (they do have large result sets). > This happened on all 6 of the read nodes that we have in our load balance > pool, so whatever the issue was hit all of them at the same time. It did > not happen to 2 specialized read nodes that only serve one specific > service, so it was something about the traffic going to those 6 nodes. The > number of ops/second during that time frame was actually lower than usual > across the cluster, with a peak of 200 ops/second. We often have higher > peaks than that without this type of CPU usage spiking. I've noticed similar behavior on large accesslog purges. High CPU, poor response times, sometimes slapd even becomes unresponsive. Do these systems have an accesslog that gets purged?

3 3

SASL for OAuth
by Pascal Jakobi 30 Jun '23

30 Jun '23

Hi there I am reading at the moment RFC 7628 (SASL for OAuth). The idea is to extend usage of OAuth outside of the HTTP world. It has obviously been written with SMTP & IAMP in mind. It seems that it could be a very nice solution for authenticating web frontends accessing dir. servers (typically web based directory browsers). Correct if I am missing a point here, pls. As far as I understand, OL does not support it (again, feel free to correct). Are there any plans to look into it ? Best, P

2 1

RSfd in top, memory, etc.
by Sam Dave 29 Jun '23

29 Jun '23

While I write to an LMDB database, while it gets bigger and bigger, I can see %MEM in top rising steadily. This is because %MEM is composed of three things, including "RSfd". From the top manpage: RSfd -- Resident File-Backed Memory Size (KiB) A subset of resident memory (RES) representing the implicitly shared pages supporting program images and shared libraries. It also includes explicit file mappings, both private and shared. Is it memory mapping that's resulting in the higher RSfd? RSfd increases do not seem to have an effect on "buff/cache" or "avail Mem", i.e. what most people think as "RAM" is not being used up. I still want to ask, could too high RSfd use result in less efficient use of memory for other programs? I'm essentially wondering how efficient common OSes (e.g. MacOS, Linux) are in this area. - Sam

2 1

Proposal to strengthen slapd EXTERNAL authentication
by Sean Gallagher 29 Jun '23

29 Jun '23

I'd like to propose a new feature to substantially strengthen the existing access controls in slapd. This follows on from comments made in the discussion around Issue 10065. In particular Comment 17 and Comment 19. The objective here is to validate the credentials supplied by external security mechanisms BEFORE the main server loop starts, and terminate the connection if the client is not "known". It was noted that the olcAuthzRegexp configuration option already deals with externally supplied Authentication ID. My idea is to build on that. I propose a new flag for "olcDisallows" that is "unmatched_external_authid". Setting this flag would instruct slapd to drop the connection if the externally supplied authid did not match any of the olcAuthzRegexp rules. Currently the olcAuthzRegexp rules are only applied after a command arrives. My proposal does not change that, instead I propose that olcAuthzRegexp be evaluated at "connection time" as well as at "execution time". This would reduce the chance of any unexpected side effects. The only real issue I can think of is - is it possible for olcAuthzRegexp to match an AuthID without changing it. Is there any recursion in the application of these rules? Any thoughts? -- This email has been checked for viruses by AVG antivirus software. www.avg.com

3 5

Re: Proposal to strengthen slapd EXTERNAL authentication
by Howard Chu 28 Jun '23

28 Jun '23

Sean Gallagher wrote: > On 26/06/2023 7:40 pm, Howard Chu wrote: >> That feature is already available using TLSVerifyClient in the slapd config. > > Not really. Using the TLSVerifyClient mechanism could be made to work and would be a nice solution but it isn't there yet. To make this this work, you would > need to pass to libldap, some type of specification of the names of legitimate clients. Then in the tls_o.c:tlso_verify_cb() function, compare the name on the > client cert with the specification and return the pass/fail status back to the TLS layer. Then it would all "just work". > > The average user might be surprised to learn that TLSVerifyClient does not currently involve checking the client's name. You would intuitively think that was > pretty important. The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user. An LDAP server should only trust certificates issued by a single CA; that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is what slapo-autoca is designed for. An LDAP server is not a web server or a client. There is no reason for it to trust certs from multiple CAs. > >> Pure nonsense. > > Pure hubris. > > It's sad when it takes a disaster to affect real change. Pure ignorance. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 12

Re: observation on serverID / URI match
by cYuSeDfZfb cYuSeDfZfb 28 Jun '23

28 Jun '23

Hi, Thanks Quanah. Just to follow-up: Yes, with an ldap listener on 0.0.0.0, openldap is *still* able to determine it's own serverID when multiple are configured, based on the above-mentioned code. In my config I do: serverID 1 ldaps://my.ldapserver1.com serverID 2 ldaps://my.ldapserver2.com (nota bene FQDN) and the local hostname is obviously NOT a FQDN but just a (short) hostname. But it is still matched correctly, which is phenomenal, and not something I could read / understand from the docs! :-) I also tested, by changing the config to a non-existing "serverID 2 ldaps:// my.ldapserver5.com <http://my.ldapserver2.com>", and then we do get the "read_config: no serverID / URL match found. Check slapd -h arguments." Impressed by openldap's cleverness. :-) Regards! On Tue, 27 Jun 2023 at 17:40, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, June 26, 2023 10:18 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Now we wonder if the serverID is determined and set correctly or > > not.... and even with loglevel -1 the auto-determined "local serverID" > > is not logged on start. > > > > > > Does anyone know? > > > > > > Can the serverID also be determined from the local hostname? Or is there > > any other magic going on? > > > This is determined in the following code block in servers/slapd/config.c: > > < > https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/conf… > > > > So that's the magic you are looking for. > > Regards, > Quanah >

1 0

observation on serverID / URI match
by cYuSeDfZfb cYuSeDfZfb 27 Jun '23

27 Jun '23

Hi, In an attempt to standardize our config as much as possible, we included in our slapd.conf: serverID 1 ldaps://my.ldapserver1.com serverID 2 ldaps://my.ldapserver2.com serverID 3 ldaps://my.ldapserver3.com serverID 4 ldaps://my.ldapserver4.com The hostname of the RHEL9 servers is set to ldapserver1 & ldapserver2, but on the hosts slapd is configured to run like: /opt/symas/lib/slapd -d 0 -h ldap:/// ldaps:/// ldapi:/// -u ldap -g ldap (so... NO uri specified, also not in /etc/default/symas-openldap) We expected to receive an error like: no match between serverID and URI found, but much to our surprise we don't. :-) Now we wonder if the serverID is determined and set correctly or not.... and even with loglevel -1 the auto-determined "local serverID" is not logged on start. Does anyone know? Can the serverID also be determined from the local hostname? Or is there any other magic going on? And otherwise... why is everything starting regularly, and are we not getting the error message? (we are running a 4 server multi-master replication setup, and replication with the above setting in place is still working normally)

2 1

What drives CPU usage spikes?
by Quanah Gibson-Mount 27 Jun '23

27 Jun '23

In our 2.6.4 deployment, we had a significant spike in CPU usage one day last week that lasted approximately 2 hours (8 AM UTC to 10 AM UTC). During this time, some clients started timing out when talking to the LDAP service, and search response times spiked as well, up to 9.5 seconds on searches that normally take < 3 seconds (they do have large result sets). This happened on all 6 of the read nodes that we have in our load balance pool, so whatever the issue was hit all of them at the same time. It did not happen to 2 specialized read nodes that only serve one specific service, so it was something about the traffic going to those 6 nodes. The number of ops/second during that time frame was actually lower than usual across the cluster, with a peak of 200 ops/second. We often have higher peaks than that without this type of CPU usage spiking. I'm curious what with modern slapd + LMDB should be looked for that would drive such a spike. I thought perhaps there were a significant number of write operations at the same time, but this was not the case, there was no unusual level of write activity. There were also much lower than usual number of concurrent connections across the cluster during this time (~800), we usually have closer to 2k-3k concurrent connections. The total number of initiated operations during the time frame was also within normal range. There was also nothing unusual about amount of network traffic, it fit right in with normal traffic levels. One thing that I did see is that there was an unusually high number of 'deferring operation: binding' messages. We normally average about 400/day, but on this specific day we hit > 1500 such messages. Thanks, Quanah

3 4

Re: problem, and solution | database monitor
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

I created https://bugs.openldap.org/show_bug.cgi?id=10073 Thanks for making available a great product. On Mon, 26 Jun 2023 at 18:41, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, June 22, 2023 10:46 AM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > I'm posting this mostly for the archives, so that a search for the error > > below will help a next person. > > Hi, > > Please open a bug on this issue at https://bugs.openldap.org > > Thanks! > > Regards, > Quanah > > > >

1 0

RE25 testing call (2.5.15) #1
by Quanah Gibson-Mount 26 Jun '23

26 Jun '23

This is the first testing call for OpenLDAP 2.5.15. Depending on the results, this may be the only testing call. NOTE: This release adds support for OpenSSL 3.0 to the 2.5 release series. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.15 Engineering Added libldap openssl3 support (ITS#9436, ITS#10030) Fixed libldap handling of TCP KEEPALIVE options (ITS#10015) Fixed libldap with async connections (ITS#10023) Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035) Fixed slapd callback handling with overlays that do extended operations (ITS#9990) Fixed slapd conversion of pcache configurations (ITS#10031) Fixed slapd cn=config modification handling with abandon (ITS#10045) Fixed slapo-constraint handling of push replication (ITS#9953) Fixed slapo-dynlist filter evaluation efficiency (ITS#10041) Fixed slapo-pcache handling of invalid schema (ITS#10032) Fixed slapo-ppolicy handling of push replication (ITS#9953) Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028) Fixed slapo-syncprov abandon handling (ITS#10016) Fixed slapo-translucent handling of invalid schema (ITS#10032) Fixed slapo-unique handling of push replication (ITS#9953) Fixed slapo-variant to improve regex handling (ITS#10048) Build Environment Fixed compatibility with stricter C99 compilers (ITS#10011) Keep .pc files during make clean (ITS#9989) Contrib Fixed slapo-variant handling of push replication (ITS#9953) Minor Cleanup ITS#9855 ITS#9995 ITS#9996 ITS#9997 ITS#9998 ITS#9999 ITS#10000 ITS#10003 ITS#10004 ITS#10033 ITS#10037 ITS#10039 ITS#10046 Regards, Quanah

2 1

RE26 testing call (2.6.5) #1
by Quanah Gibson-Mount 26 Jun '23

26 Jun '23

This is the first testing call for OpenLDAP 2.6.5. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.5 Engineering Fixed libldap handling of TCP KEEPALIVE options (ITS#10015) Fixed libldap with async connections (ITS#10023) Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035) Fixed slapd callback handling with overlays that do extended operations (ITS#9990) Fixed slapd conversion of pcache configurations (ITS#10031) Fixed slapd cn=config modification handling with abandon (ITS#10045) Fixed slapd-mdb online indexer termination and cleanup (ITS#9993) Fixed slapd-mdb online indexer when interrupted (ITS#10047) Fixed slapd-monitor connection cleanup (ITS#10042) Fixed slapo-constraint handling of push replication (ITS#9953) Fixed slapo-dynlist filter evaluation efficiency (ITS#10041) Fixed slapo-pcache handling of invalid schema (ITS#10032) Fixed slapo-ppolicy handling of push replication (ITS#9953) Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028) Fixed slapo-syncprov abandon handling (ITS#10016) Fixed slapo-translucent handling of invalid schema (ITS#10032) Fixed slapo-unique handling of push replication (ITS#9953) Fixed slapo-variant to improve regex handling (ITS#10048) Build Environment Fixed compatibility with stricter C99 compilers (ITS#10011) Keep .pc files during make clean (ITS#9989) Contrib Fixed slapo-variant handling of push replication (ITS#9953) Minor Cleanup ITS#9855 ITS#9995 ITS#9996 ITS#9997 ITS#9998 ITS#9999 ITS#10000 ITS#10003 ITS#10004 ITS#10033 ITS#10037 ITS#10039 ITS#10046 Regards, Quanah

2 1

problem, and solution | database monitor
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi, I'm posting this mostly for the archives, so that a search for the error below will help a next person. Today I wanted to setup the cn=Monitor backend, and after doing so, openldap failed to start with: backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1) The reason turned out to be: we had configured one of our databases ("database ldap") without a suffix. After I added a suffix, openldap started, and cn=Monitor worked as expected. I added a simple placeholder suffix (o=ldap,c=com) and now I need to find out what the database ldap was actually used for in our setup, and what the proper suffix should be. (does anyone perhaps know what openldap used as a default, if a "database ldap" suffix is omitted from the config?) Anyway: Hopefully this post will help a future someone with the same error message, as the error message had little to do the the cause.

2 1

slapacl issue
by Carsten Jäckel 26 Jun '23

26 Jun '23

Dear experts, in a testing environment (SLES 15 SP5, OpenLDAP 2.5.14) I use the following ACLs in olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break If I run ldapmodify -xWD "cn=test,ou=users,dc=foo,dc=bar" to change the account cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 everything works as expected. LDAP-Log: 2023-06-16T12:53:12.024030+02:00 tst1 slapd[1333]: conn=1016 fd=28 ACCEPT from IP=10.10.10.10:53558 (IP=0.0.0.0:636) 2023-06-16T12:53:12.039643+02:00 tst1 slapd[1333]: conn=1016 fd=28 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.3 tls_cipher=TLS_AES_128_GCM_SHA256 2023-06-16T12:53:12.039773+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" method=128 2023-06-16T12:53:12.039841+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" mech=SIMPLE bind_ssf=0 ssf=128 2023-06-16T12:53:12.041918+02:00 tst1 slapd[1333]: conn=1016 op=0 RESULT tag=97 err=0 qtime=0.000014 etime=0.002242 text= 2023-06-16T12:53:30.488074+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD dn="cn=test,ou=users,dc=foo,dc=bar" 2023-06-16T12:53:30.488474+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD attr=description 2023-06-16T12:53:30.557458+02:00 tst1 slapd[1333]: conn=1016 op=1 RESULT tag=103 err=0 qtime=0.000022 etime=0.069664 text= 2023-06-16T12:53:33.035486+02:00 tst1 slapd[1333]: conn=1016 fd=28 closed (connection lost) Running the above command from another machine results in a Insufficient access (50) error as also expected. So I assume the ACLs to be working correctly. If I run slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 I get the following output: PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: none(=0) children: none(=0) description=test: none(=0) cn=test: none(=0) sn=test: none(=0) objectClass=person: none(=0) objectClass=top: none(=0) structuralObjectClass=person: none(=0) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: none(=0) creatorsName=cn=manager,dc=foo,dc=bar: none(=0) createTimestamp=20230227131940Z: none(=0) userPassword=****: none(=0) pwdChangedTime=20230227131959Z: none(=0) authTimestamp=20230616065542Z: none(=0) pwdLastSuccess=20230616103806Z: none(=0) entryCSN=20230616103806.257186Z#000000#000#000000: none(=0) modifiersName=cn=test,ou=users,dc=foo,dc=bar: none(=0) modifyTimestamp=20230616103806Z: none(=0) I expected to see write access in slapacl's output. If I remove the 'peername.ip="10.10.10.10"' part from olcAccess {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none the above slapacl command outputs write access correctly no matter if the parameter '-o peername=10.10.10.10' is set or not. olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: write(=wrscxd) children: write(=wrscxd) description=first test cn=test: write(=wrscxd) sn=test: write(=wrscxd) objectClass=person: write(=wrscxd) objectClass=top: write(=wrscxd) structuralObjectClass=person: write(=wrscxd) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: write(=wrscxd) creatorsName=cn=manager,dc=foo,dc=bar: write(=wrscxd) createTimestamp=20230227131940Z: write(=wrscxd) userPassword=****: write(=wrscxd) pwdChangedTime=20230227131959Z: write(=wrscxd) authTimestamp=20230616065542Z: write(=wrscxd) pwdLastSuccess=20230616105312Z: write(=wrscxd) entryCSN=20230616105330.487886Z#000000#000#000000: write(=wrscxd) modifiersName=cn=test,ou=users,dc=foo,dc=bar: write(=wrscxd) modifyTimestamp=20230616105330Z: write(=wrscxd) Am I doing something wrong? Any help is appreciated. Thanks, Carsten

2 1

Re: What drives CPU usage spikes?
by Erik de Waard 26 Jun '23

26 Jun '23

I see this on our consumers when waiting on writes to be accepted by the provider/ or when it's unreachable.

2 1

Re: unable to authenticate, ldaps
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi, I was preparing some more logging to show. You were *really* quick in your reply! :-) Below more logging, and I will reply to your ACL question next. Replication after setting the password: Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP= 192.168.16.36:45316 (IP=0.0.0.0:636) Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed (connection lost) Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234 cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry: rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID: a8ccf30a-88d0-103d-8b70-5f35ddf1cc44 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20230626143609.891703Z#000000#0dd#000000 tid 0x7f68a6afd640 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 be_search (0) Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 uid=testuser,ou=Users,o=ldap,c=com Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on opc=0x7f689c008f90 Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_matchops: skipping original sid 0dd Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_matchops: skipping original sid 0dd Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 be_modify uid=testuser,ou=Users,o=ldap,c=com (0) Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000 Failed authentication using the correct password: Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP= 192.168.16.36:46196 (IP=0.0.0.0:636) Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND dn="uid=testuser,ou=Users,o=ldap,c=com" method=128 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on opc=0x7f689c008ed0 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0 generated new csn=20230626143627.270437Z#000000#0de#000000 manage=1 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c110220 20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp: set up a new syncres mode=2 csn=20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c110220 20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_sendresp: to=0dd, cookie=rid=243,sid=0de,csn=20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_sendresp: sending LDAP_SYNC_MODIFY, dn=uid=testuser,ou=Users,o=ldap,c=com Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 RESULT tag=97 err=49 qtime=0.000015 etime=0.001002 text= Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=1 UNBIND Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 closed On Mon, 26 Jun 2023 at 16:36, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, June 26, 2023 5:28 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi all! > > > > > > We have this in place:olcAccess: {1}to attrs=userpassword by anonymous > > auth by * none break > > It's impossible to answer this question without knowing the rest of your > ACLs. For example the acl in slot {0} could mean that the acl in slot {1} > is never evaluated. > > --Quanah > > > >

2 2

unable to authenticate, ldaps
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi all! We have this in place: olcAccess: {1}to attrs=userpassword by anonymous auth by * none break Using the RootDN to set a user password: # ldappasswd -H ldaps://my.ldapserver1.com -D "cn=admin,o=ldap,c=com" -W -S "uid=testuser,ou=Users,o=ldap,c=com" -v New password: <newpassword> Re-enter new password: <newpassword> Enter LDAP Password: <very_secret_and_difficult> ldap_initialize( ldaps://my.ldapserver1.com:636/??base ) Enter LDAP Password: Result: Success (0) We observe the password change replicate (master-master) to our other server. Then to test access: # ldapsearch -H ldaps://my.ldapserver1.com -s base -b o=ldap,c=com -D "uid=testuser,ou=Users,o=ldap,c=com" -w <newpassword> -v ldap_initialize( ldaps://my.ldapserver1.com:636/??base ) ldap_bind: Invalid credentials (49) More background: this is fresh a master-master setup, replication works with the root DN, and all other user authentications fails with the same Invalid credentials (49) The server ldaps://my.ldapserver1.com is an actual single (master) server, no load balancers, no firewalling. Configured an with actual (and valid) certificate, ldapsearch uses the correct CA, and ldapsearch with the root DN works fine. This is latest symas openldap 2.5 on RHEL9. Anyone with an idea why we can only authenticate as the RootDN, and all other authentications give Invalid credentials (49)? We have double checked whatever we can think of, and are *really* unsure what is going on.... Hoping for some clues from the experts here :-)

2 1

RE: Queries regarding Openldap migration from 2.6.2 to 2.6.4
by Quanah Gibson-Mount 23 Jun '23

23 Jun '23

--On Friday, June 23, 2023 2:19 PM +0000 "Sudarshan Sutar (EXT-NSB)" <sudarshan.sutar.ext(a)nokia-sbell.com> wrote: > > > Hi Team > > > Currently we are using openldap 2.6.2 and we want to upgrade it to latest > openldap i.e 2.6.4. So, is there any patch file available that can be > applied directly on to openldap 2.6.2 code base on our build machine ? > Or do I have to take the changes manually from below link ? Hello, a) Stop emailing openldap-technical-owner(a)openldap.org b) stop CCing people at your work This is not how you do proper software deployments/management. I would again *strongly* advise that if you are unable to generate properly packaged software that you use any of the freely available options I already listed. The correct way to get the source for a given release for building a new version is to download the source for the current release from: https://www.openldap.org/ Regards, Quanah

1 0

architectural question on master-slave vs multi-master
by cYuSeDfZfb cYuSeDfZfb 22 Jun '23

22 Jun '23

Hi, As you have already may have discovered by my many posts lately, we're busy with our ldap environment, and migrating from openldap 2.4 (bdb/RHEL7) to 2.5 on mbd/RHEL9. We've always had a duo of masters, replicating to a (READ ONLY) duo of slaves. All clients are configured to talk to the slaves, through a load balancer, and the masters pretty much only receive updates to the DIT from IdM. Our problem is: how to handle failed authentications (ppolicy) considering that the slaves are read-only and the slaves is where the failed authentications take place. Hence, my request for feedback: is master-slave still considered "the best way" of doing this? And then, is there a "standard way" to handle failed authentications on read-only slaves? Or perhaps... is it nowadays better to chose for a simpler multi-master (4 hosts) LDAP setup: four identical servers, where we choose to send clients to two specific servers (firewalled differently to handle client access) and two others to receive updates from IdM, but use multi-master replication so that all changes (either from IdM, or from failed authentications) are replicated equally between all four servers. Seems that new approach is much simpler. Any feedback? What is wise?

2 1

Re: migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
by cYuSeDfZfb cYuSeDfZfb 22 Jun '23

22 Jun '23

Hi Quanah, Thanks for your answer and kind suggestions! We will implement them. And anyone here using zabbix, and has some scripting for monitoring laying around..? Thanks! On Fri, 16 Jun 2023 at 16:42, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, June 15, 2023 10:51 PM +0200 sacawulu <cyusedfzfb(a)gmail.com> > > wrote: > > > > Most of these things can be done similarly in 2.4/bdb and 2.5/mbd but not > > the db_verify, which is bdb specific. > > > > I don't find a lot of info on the maintenance / integrity checks that can > > be done on mdb databases. In fact: Mostly what I can find is: "MDB uses > > no caching and requires no tuning to deliver maximum search performance" > > There's very little necessary to be done when using back-mdb as you've > already discovered > > > That is very good. :-) We have already discovered that we need to > > increase maxsize, as our database is (much) larger than 10MB. > > The rule of thumb for maxsize is to set it to something larger than you > ever expect to hit. For example, with a database I'm using that's ~3.4GB > in size, I have a 20GB maxsize set. You may want to monitor the size of > your database vs the configured maxsize. This can be done with data > available in the back-monitor database (at least with 2.6, not sure with > 2.5) or via the mdb_stat utility. > > python-ldap3 snippet using back-monitor: > > try: > tls = Tls(validate=ssl.CERT_NONE, version=ssl.PROTOCOL_TLSv1_2) > conn = Connection(Server(ldap_url, tls=tls, use_ssl=True), > auto_bind=True) > conn.search( > "cn=monitor", > "(&(objectClass=olmMDBDatabase))", > attributes=["olmMDBPagesMax", "olmMDBPagesUsed", > "namingContexts"], > ) > > for db in conn.entries: > suffix = db.namingContexts.value > # 4096 is the page size in use > # can be found with mdb_stat -e /path/to/database > max_size = int(db.olmMDBPagesMax.value) * 4096 > current_size = int(db.olmMDBPagesUsed.value) * 4096 > pct_used = float(current_size / max_size * 100) > > > > > Anyone else with tips and tricks on daily maintenance or monitoring? > > Scripts to share..? Perhaps zabbix templates..? > > The only other bits I would recommend is if you have object in the > directory that have very large multi-valued attribute data. For example, > if you use groups extensively, and the 'member' attribute has hundreds of > entries, you would probably want to do something like: > > a) Add member as an attribute to be handled by olcSortvals > > b) Add a multival configuration to back-mdb if the attribute is indexed. > For example, if you indexed member "eq". I usually do 100,10. This will > put the index databse into its own subdb, which helps keep fragmentation > from being an issue. > > For example, I had a ~5.5GB DB that was swelling to over 11GB in size due > to fragmentation before implementing those two configuration options. > > > Regards, > Quanah > > > >

2 2

Data migration
by Jean-Luc Chandezon 16 Jun '23

16 Jun '23

Hello dear community, I have to migrate our ldap database from OpenLDAP (from 2019 version hosted on Debian, to Symas OpenLDAP 2.4.59 on ). I need to change our DN from "dc=lexp,dc=fr" to "dc=directory,dc=lan-explore,dc=fr". I installed OpenLDAP and configure directory with new DN. For data migration, I exported data: slapcat -b dc=lexp,dc=fr > /tmp/20230616_save_data.ldif .. and for recovery, I changed all dn mentions from old to new dn. 1. Is the correct way? When import, you can see error message: slapadd: slap_init invalid suffix ("dc=directory,dc=lan-explore,dc=fr ") 2. When searching, I discovered that each line can contains 77 columns. Next, line is truncated, and it's difficult to replace all dn. Thanks, Jean-Luc

4 4

migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
by sacawulu 16 Jun '23

16 Jun '23

Hi, We are in the middle of a move from 2.4/bdb to 2.5/mdb, and I am working on implementing monitoring for the new systems. In the 2.4/bdb environment, we run several scripts to check sanity of the servers: * checks of the contextCSN value across the masters/slaves * regular db_verify on the actual bdb files * compare all DN & entryCSN in the DB across all the masters/slaves * do a write on a master, and verify that it is replicated everywhere Most of these things can be done similarly in 2.4/bdb and 2.5/mbd but not the db_verify, which is bdb specific. I don't find a lot of info on the maintenance / integrity checks that can be done on mdb databases. In fact: Mostly what I can find is: "MDB uses no caching and requires no tuning to deliver maximum search performance" That is very good. :-) We have already discovered that we need to increase maxsize, as our database is (much) larger than 10MB. Two questions: - Is there really nothing else to tune or adjust? - Is there really no way to verify the internal structures within the MDB file, to make sure everything is valid and healthy? Perhaps things I have missed with our four checks above? Anyone else with tips and tricks on daily maintenance or monitoring? Scripts to share..? Perhaps zabbix templates..? If anyone would be interested in (for example) my script to verify the complete directory contents based on DN&entryCSN across a (multi)master/(multi)slave setup, I'd be happy to share too, of course. Thanks!

2 1

Vulnerability CVE-2023-2953 found in latest version
by Sahil Sharma D 16 Jun '23

16 Jun '23

Hi Team, We are currently using OpenLDAP version 2.4.57 in which vulnerability CVE-2023-2953 was not there. We are planning to upgrade to OpenLDAP-2.6.4 however in this version we found CVE-2023-2953 in our scanning, can you please help in understanding why this vulnerability is opened in latest release. In which release we can expect this vulnerability to get resolved? Appreciate your earliest response. Regards, Sahil

2 2

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 15 Jun '23

15 Jun '23

Hi! I am using the cn=admin,o=infra,c=com with correct password to connect. I will further check ACLs! Thank you for that suggestion. Just to make things more concrete, below are two samples. One on the MASTER with contextCSN, and one from the SLAVE without contextCSN. EXAMPLE SLAVE: ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b "o=infra,c=com" -s base contextCSN # extended LDIF # # LDAPv3 # base <o=infra,c=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN # # search result search: 2 result: 0 Success # numResponses: 1 EXAMPLE MASTER: ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b "o=infra,c=com" -s base contextCSN # extended LDIF # # LDAPv3 # base <o=infra,c=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN # # infra, com dn: o=infra,c=com contextCSN: 20180917142109.765066Z#000000#000#000000 contextCSN: 20230612144901.796553Z#000000#001#000000 contextCSN: 20230612144904.899482Z#000000#002#000000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Hi Quanah, > > > > Thanks for the swift reponse! I think I do, yes, see, from consumer one: > > > > olcSyncrepl: {0}rid=202 > > provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple > > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory > > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" > > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" > > starttls=critical tls_reqcert=demand > > olcSyncrepl: {1}rid=201 > > provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple > > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory > > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" > > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" > > starttls=critical tls_reqcert=demand > > olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389 > > olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389 > > That's syncrepl, not syncprov. > > However, the issue could be ACLs. If you use the rootdn for your database > to run the query, can you see the contextCSN value stored in your database > root? > > --Quanah > > > >

3 4

Problem with restoring using ldif, OpenLDAP 2.6.3
by awsome jang 14 Jun '23

14 Jun '23

Hello, I am running openldap 2.6.3 configured as provider-consumer and I would like to do backup/restore of the database on the provider. I create a backup on working sladp using command(ends with success, file created): slapd.exe –T cat –f slapd.conf –l backup.ldif And then trying to load it using slapd command into a new database(restore): slapd.exe -T add -f slapd.conf -l backup.ldif -d -1 Command ends with: . creatorsName: uid=root,ou=invalid,dc=vmbox,dc=int createTimestamp: 20230410111050Z entryCSN: 20230410111051.368528Z#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int modifyTimestamp: 20230410111050Z contextCSN: 20230410125515.-401856Z#000000#000#000000 " >>> dnPrettyNormal: <dc=vmbox,dc=int> <<< dnPrettyNormal: <dc=vmbox,dc=int>, <dc=vmbox,dc=int> >>> dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> <<< dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> >>> dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> <<< dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> <= str2entry NULL (smr_normalize contextCSN 21) slapadd: could not parse entry (line=1) slapadd shutdown: initiated slapadd destroy: freeing system resources. When I look into backup.ldif files I see that there is an '-' in contextCSN timestamp which cause this behaviour: entryCSN: 20230410111051.368528Z#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int modifyTimestamp: 20230410111050Z contextCSN: 20230410125515.-401856Z#000000#000#000000 ^^^^^^ contextCSN: 20230412130738.035155Z#000000#002#000000 I also see that entryCSN also can be negative which also causes similar problems when loading files. I would like to ask if there is any way to restore backup in this scenario in a proper way? for instance removing the "-" sign? Thank in advance for your response, Best regards, Peter

2 1

Re: troubleshooting replication issues
by Abby Guenther 14 Jun '23

14 Jun '23

2.4.59 Postgres backend Slapd doesn't always crash. Sometimes it just stops replicating for seemingly no reason. Thanks On Tue, Jun 13, 2023, 1:38 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, May 31, 2023 3:54 AM +0000 abby.knows.it(a)gmail.com wrote: > > > We have three nodes and want to replicate between them. This setup > > worked fine for over a year. Recently replication fails and the slapd > > process crashes. > > OpenLDAP version? What database backend? Does the process actually crash > or does it shut down? > > --Quanah > > >

2 1

troubleshooting replication issues
by abby.knows.it＠gmail.com 13 Jun '23

13 Jun '23

We have three nodes and want to replicate between them. This setup worked fine for over a year. Recently replication fails and the slapd process crashes. In a general sense I'm looking for a FAQ on troubleshooting replication, the common issues and solutions. Also how to turn on logging for replication specifically would help. Thanks. Abby

4 3

Re: RE26 testing call (2.6.5) #1
by Simon Pichugin 12 Jun '23

12 Jun '23

Hi folks, OpenLDAP 2.6.5 was built and tested cleanly on Fedora 38 (Rawhide). Regards, Simon On Thu, May 25, 2023 at 1:39 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > This is the first testing call for OpenLDAP 2.6.5. Depending on the > results, this may be the only testing call. > > Generally, get the code for RE26: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.6.5 Engineering > Fixed libldap handling of TCP KEEPALIVE options (ITS#10015) > Fixed libldap with async connections (ITS#10023) > Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035) > Fixed slapd callback handling with overlays that do extended > operations > (ITS#9990) > Fixed slapd conversion of pcache configurations (ITS#10031) > Fixed slapd cn=config modification handling with abandon (ITS#10045) > Fixed slapd-mdb online indexer termination and cleanup (ITS#9993) > Fixed slapd-mdb online indexer when interrupted (ITS#10047) > Fixed slapd-monitor connection cleanup (ITS#10042) > Fixed slapo-constraint handling of push replication (ITS#9953) > Fixed slapo-dynlist filter evaluation efficiency (ITS#10041) > Fixed slapo-pcache handling of invalid schema (ITS#10032) > Fixed slapo-ppolicy handling of push replication (ITS#9953) > Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028) > Fixed slapo-syncprov abandon handling (ITS#10016) > Fixed slapo-translucent handling of invalid schema (ITS#10032) > Fixed slapo-unique handling of push replication (ITS#9953) > Fixed slapo-variant to improve regex handling (ITS#10048) > Build Environment > Fixed compatibility with stricter C99 compilers (ITS#10011) > Keep .pc files during make clean (ITS#9989) > Contrib > Fixed slapo-variant handling of push replication (ITS#9953) > Minor Cleanup > ITS#9855 > ITS#9995 > ITS#9996 > ITS#9997 > ITS#9998 > ITS#9999 > ITS#10000 > ITS#10003 > ITS#10004 > ITS#10033 > ITS#10037 > ITS#10039 > ITS#10046 > > Regards, > Quanah > >

1 0

olcAccess rule with groupOfURLs
by Souji Thenria 12 Jun '23

12 Jun '23

Hello, I am trying to use a group of the type "groupOfURLs" within an olcAccess rule. However, I am having trouble getting this to work. For testing, I use a simple rule like: by set="[cn=test,ou=System,dc=example,dc=local]/member & user" write where "test" consists of the objectClass "grouOfURLs", with the following query in the "memberURL" attribute: ldap:///ou=Users,dc=example,dc=local??one?(uid=*) In my understanding, the query is executed when the group's content is requested. And it works; if I use "ldapsearch", I get the expected result. However, if I use this group in the olcAccess rule, it won't work. I tried to use a static group with the objectClass "groupOfMembers", which works. All I found suggested that I could use a dynamic list within a rule. Am I missing something, or does it simply not work with dynamic lists? Regards, Souji Thenria

4 9

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Op 12-06-2023 om 17:29 schreef Quanah Gibson-Mount: > It appears you are using the historic back-hdb or back-bdb backend to > OpenLDAP. These backends are particularly susceptible to corruption. > You should migrate to using the supported backend (back-mdb). You > should also upgrade to a supported release series (2.5 or 2.6) as 2.4 > hasn't been supported for a few years. Yes we are in the middle of migrating. :-) The old structure still uses bdb, yes. While working on new (RHEL9) servers with symas-repo 2.5 openldap, things started happening with the 'old' (but still production) ldap. Thank you very much for your insights! Kind regards!

1 0

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Hi Quanah, Thanks for the swift reponse! I think I do, yes, see, from consumer one: olcSyncrepl: {0}rid=202 provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcSyncrepl: {1}rid=201 provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389 olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389 And the second consumer looks similar. Thanks again! On Mon, 12 Jun 2023 at 15:56, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Monday, June 12, 2023 3:23 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Is there any explanation, why I would be unable to obtain these > > contextCSN attributes through an ldapsearch? > > Do you have the syncprov overlay instantiated on the database on the > consumers? > > --Quanah > > > >

2 1

no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Hi, We have a 4-machine setup with two providers (replicating between each other) and two consumers (for client access) that both replicate from both providers, type=refreshAndPersist I'm trying to write a script to monitor replication, using the contextCSN attribute. ldapsearch on the providers gives the expected the contextCSN attributes: contextCSN: 20230612115901.693614Z#000000#001#000000 contextCSN: 20230612115904.937471Z#000000#002#000000 However, the same ldapsearch on the consumers gives *no* contextCSN attributes *at all*. But when using slapcat to check directly on the consumers databases, we *can* see the attributes, and they are also up-to-date: contextCSN: 20230612115801.572594Z#000000#001#000000 contextCSN: 20230612115804.594419Z#000000#002#000000 Is there any explanation, why I would be unable to obtain these contextCSN attributes through an ldapsearch? This is RHEL7.9, with openldap 2.4.44 Thanks!

2 1

back-ldap proxy doesn't forward response from upstream server
by Sven Feyerabend 12 Jun '23

12 Jun '23

Hello everyone, I have set up two slapd instances in mirror mode. As described in the documentation I used another slapd instance with ldap backend to proxy the requests and provide failover capabilities in case one of the upstream servers becomes unavailable. Now I have the curious situation, that the proxy correctly forwards the search request from a client to the upstream server but doesn't return the result. I can see in the log that the upstream server responds with one entry: SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.001134 nentries=1 The proxy however does not forward this result to the client: SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.001730 nentries=0 The client (ldapsearch for test purposes) then gives me the following result: # search result search: 2 result: 0 Success I don't understand what I did wrong. I imported the correct schema into the proxy instance, my config of the ldap backend on the proxy is as follows: # {2}ldap, config dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLdapConfig olcDatabase: {2}ldap olcSuffix: ROOT_SUFFIX_OF_UPSTREAM_DIRECTORY olcDbURI: ldap://openldap-test-0.ldap-test:1389,ldap://openldap-test-1.ldap-test:1389 Does anyone know how to solve this? Some help would be appreciated greatly. Thanks in advance and kind regards Sven

2 1

"pwdHistory" Attribute Is Not Getting Deleted
by Nagesh Nikavade (EXT-NSB) 12 Jun '23

12 Jun '23

Hello Team, We have upgraded from openldap2.4.52 to openldap2.6.2 in our system. With new openldap2.6.2 version, "pwdHistory" attribute isn't being deleted. I have executed the below command: ldapmodify -x -y /opt/Nokia_BP/etc/ldapfiles/fssecldap.ldaproot -D uid=fsLDAPRoot,ou=People,fsFragmentId=Security,fsClusterId=ClusterRoot >/dev/null<<EOF dn: uid=Nemuadmin,ou=People,fsFragmentId=Security,fsClusterId=ClusterRoot changetype: modify delete: pwdHistory EOF I was able to delete "pwdHistory" in old openldap2.4.52 with the same command. Anything got changed regarding this(pwdHistory) in new openldap2.6.2 ? Or is there any other way to delete the "pwdHistory". Thanks in advance. Best Regards, Nagesh

2 1

mdb_txn_abort() thread
by Sam Dave 08 Jun '23

08 Jun '23

Hi, The documentation for mdb_txn_begin() says "A transaction and its cursors must only be used by a single thread, and a thread may only have a single transaction at a time.". Does this also hold for mdb_txn_abort() for read-write transactions? I.e. does the abort also have to happen on the same OS thread as all the previous things (begin, put, etc.)? - Samuel

2 9

argon2 as builtin module?
by Geert Hendrickx 02 Jun '23

02 Jun '23

Hi I was wondering why the argon2 password module can only be built as a dynamic module, and not statically into the slapd binary, like other backends and overlays can be. That would for example make it easier to use slappasswd -h {ARGON2} without having to specify -o module-load=argon2 and module-path etc. Is it because you want to avoid link dependencies on 3rd party libsodium or libargon2 directly in slapd (and slappasswd) itself? Or just because it was previously a contrib module, and just copied over like that? By the way, while looking at the code, I noticed a typo in configure.ac: > if test "$ol_enable_argon2" = "yes" ; then > SLAPD_DYNAMIC_PWMODS="$SLAPD_DYNAMIC_PWDMODS argon2.la" > fi ^^ ^^^ It's referencing two different variables there, which is harmless today, but will be a build bug once multiple password modules become available. SLAPD_DYNAMIC_PWMODS is the correct one. Geert

2 1

Only view exact match on ACL
by Lukas Adrian Kron 24 May '23

24 May '23

Hello, I would like to restrict bind users in the search. I've already managed that they only see groups for which you have been activated. Now I have the problem that bind users should only see users in the people branch if they know the exact user name in the search. So far I have solved the whole thing using the following two ACL sets. You can now also search for people. Since I had to include objectClass for the search to work, you can search for all people or for other values. However, I want all the data I specify to be displayed, but only if the username returns an exact result. I am at the end of my knowledge with the ACL sets. All the Info on ACL cannot help me further here. {5} to dn.exact="ou=Personen,dc=SERVER" by group.exact="GROUP" search by * break {6} to dn.one="ou=Personen,dc=SERVER" attrs=entry,cn,objectClass,givenname,uid,mail,sn,userPassword by group.exact="GROUP" read by * break Thanks a lot. Kindly Lukas Adrian

1 0

SSL timeout
by Robert T Dunn 23 May '23

23 May '23

We are experiencing a problem with SSL timeout as reported with issue 8047: https://bugs.openldap.org/show_bug.cgi?id=8047 Our issue is when the LDAP client does an SSL connect to establish the TLS session with the remote server. If the SERVER_HELLO returned from the remote server takes a significant amount of time or does not come back from the server at all (for example, someone unplugged the server), the LDAP client connection DOES NOT timeout, and there are no LDAP configuration options to force the session to timeout. So, the LDAP client connection is effectively hung forever. Issue 8047 reported the SSL timeout issue, but the issue's status is still UNCONFIRMED. Are there any plans to correct this problem in future versions of LDAP Client? Thanks, Rob Dunn IBM z/TPFDF development email: strmbrgr(a)us.ibm.com<mailto:strmbrgr@us.ibm.com> phone: (845) 433-1312

3 3

DIT changes approval
by sysadm+ldap-technical＠rolep.work 23 May '23

23 May '23

Hello, Is there any way to approve (past or future) DIT changes by more than one people? OpeLDAP has ACL sets, I know. But I don't understand, how (or even can I) to use it forr approve changes in (part of) DIT by two or more people (must not singly, but whole set of people).

3 2

SASL EXTERNAL
by thomaswilliampritchard＠gmail.com 23 May '23

23 May '23

I understand SASL is a framework defined outside of OpenLDAP and the EXTERNAL mechanism of SASL implies authentication is established outside of the SASL mechanism using context around the client connection. It sounds like that could be something like the Client IP, the DN in the client certificate if using mutual TLS, or the gid / uid of the client when connecting over unix sockets. I am looking for a way to audit that my SASL EXTERNAL configuration does not allow any sort of authentication through anything other than the unix socket option. I have not come across a way that I can configure the external mechanism with only uid / gid methodology. Is it sufficient to simply audit the ACLs and see that there is only an ACL for the unix socket mechanism to be confident the server is not entertaining IP / TLS / or some other EXTERNAL methodology?

1 0

OpenLDAP: slapd 2.4.59 | Too Many Open files
by chauhan.ramraj＠gmail.com 19 May '23

19 May '23

Hi All Requesting some sort of help with "Too Many open files". .I have seen several post and even in these archives about too many open files..Details about openldap installation. Version - 2.4.59 OS- RockyLinux 8 Ldap is used by the coldfusion application for authentication. During normal operation things are ok..but after some time or when a load of like 30 concurrent users for a period of 5 mins are added, I get "Too Many Open files" after the file descriptors reach 1024. What I have observed that post the search result log. , the UNBIND and CLOSE on the connection at times takes over 3 mins..and have see that there are over 1000 connections in ESTABLISHED mode based on the lsof -i :ldap ...I have tried to set below limits but to no avail..it still thows error post 1023 open FDs.. * hard nofile 65535 * soft nofile 65535 * hard memlock 3000000 * soft memlock 3000000 * hard nproc 16000 * soft nproc 16000 * hard stack 512000 * soft stack 512000 Have been able to increase the FDs as well by modifiying the slapd startup script(changed the settings to 4096..it did reflect in monitor)..but after some time the connection unbind and close calls are invoke more than 3 mins...as compared to when the load is low..when it happens within few secs.. Any help to make changes to ldap configuration or pointers how to go ahead troubleshooting this would be really appreciated.

3 5

Two mdb_env_open() on same file/dir? Etc.
by Sam Dave 18 May '23

18 May '23

Can two or more mdb_env_open() be called on the same file/directory (in same program or multiple programs)? Can two or more mdb_dbi_open() be called to open ultimately the same database? What are some ramifications of doing so (and of course working with various readonly/readwrite transactions, etc.) I don't see much written about this in documentation. - Samuel

2 1

OpenLDAP - CLDAP and SASL
by Simon Pichugin 16 May '23

16 May '23

Hi folks, I am currently experiencing an issue with IPA Server set up on Fedora 36, using ipa-adtrust-install, and I'm unsure if this is due to a bug or misconfiguration on my part. Here's what I've done: I ran the following ldapsearch command: ldapsearch -LL -H cldap://server.example.com -b '' -s base 'dc=example,dc=com' "(&(DnsDomain='dc=example,dc=com')(NtVer=\x06\x00\x00\x00)(AAC=\x00\x00\x00\x00))" On OpenLDAP 2.4.46, it was working fine, and it gave an output. But OpenLDAP 2.6.2 and 2.6.4 fails with No such object (32) error. I used gdb to investigate and found that the error occurred here: https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… It executes ldap_sasl_interactive_bind, but it exits right in the beginning: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/… So back at: https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… It exists the do-while loop right away and leaves with no result. I'm wondering if I missed something or if there was an oversight in the implementation of this RFC, specifically regarding the CLDAP case: https://git.openldap.org/openldap/openldap/-/commit/2ae62e86bc8ffab713fc489… Looking forward to your thoughts! Best Regards, Simon

2 2

iNetOrgPerson doesn't exist?
by Luca Stancapiano 16 May '23

16 May '23

Hi all, I'm triing to create a user with openldap 2.4 dn: uid=rrrrrr,ou=users,dc=my-domain,dc=com objectClass: iNetOrgPerson uid: iiiiii but it doesn't seem recognize the objectClass producing this error: adding new entry "uid=rrrrrr,ou=users,dc=my-domain,dc=com" ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax Using other object classes is ok. What's the problem?

5 11

Debugging TLS negotiation failure
by terry.lemons＠dell.com 16 May '23

16 May '23

Hi I've followed the instructions in https://www.openldap.org/doc/admin26/quickstart.html to deploy openldap 2.6.4 on a SLES 15 SP4 system. Once I confirmed that this was working correctly, I moved on to configure TLS, following the instructions in https://www.openldap.org/doc/admin26/tls.html. When I try a connection to the LDAPS port (636), I see the following: ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 CONNECTED(00000003) 139702302594704:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 293 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1683823897 Timeout : 300 (sec) Verify return code: 0 (ok) --- ldpdd040:~ # I'm using this command to start slapd: /usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 3 -h "ldap:/// ldaps:///" When I execute the openssl command above, I look in /var/log/messages and see: 2023-05-11T12:51:55.213884-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 ACCEPT from IP=10.247.229.40:56844 (IP=0.0.0.0:636) 2023-05-11T12:51:55.213944-04:00 ldpdd042 slapd[20101]: connection_get(12): got connid=1000 2023-05-11T12:51:55.214004-04:00 ldpdd042 slapd[20101]: connection_read(12): checking for input on id=1000 2023-05-11T12:51:55.214065-04:00 ldpdd042 slapd[20101]: connection_read(12): TLS accept failure error=-1 id=1000, closing 2023-05-11T12:51:55.214138-04:00 ldpdd042 slapd[20101]: connection_close: conn=1000 sd=12 2023-05-11T12:51:55.214207-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 closed (TLS negotiation failure) ldpdd0 I've appended these lines to /usr/local/etc/openldap/slapd.conf: # Added TLS directives # TLSCACertificateFile /var/lib/ca-certificates/ca-bundle.pem TLSCertificateFile /etc/ssl/private/server.cert TLSCertificateKeyFile /etc/ssl/private/server.key #TLSCipherSuite ALL I can't find any log information that helps me understand what the problem is. I'm using a self-signed server certificate that has the cn using the FQDN of the server. How can I debug this? Thanks! tl

12 31

Overly variant
by Stefan Kania 14 May '23

14 May '23

Hi to all, today I tried to set up the new overlay variant with OpenLDAP 2.6 (symas-packages) on a Debian 11 system First step I loaded the module: I added the Attribute "postaladdress" to an OU (ou=firma,dc=example,dc=net) and the "mobile" attribute to (ou=firma,dc=example,dc=net) Then I added the module ------------ dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: variant.la ------------ Then I created the following configuration: ------------ dn: olcOverlay={5}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantConfig olcVariantPassReplication: TRUE dn: name=example,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantVariant olcVariantEntry: dc=example,dc=net dn: olcVariantVariantAttribute=postaladdress,name={0}example,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantAttribute olcVariantVariantAttribute: postaladdress olcVariantAlternativeAttribute: postaladdress olcVariantAlternativeEntry: ou=firma,dc=example,dc=net dn: name=firma telefon,name={0}example,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantAttribute olcVariantVariantAttribute: telephonenumber olcVariantAlternativeAttribute: mobile olcVariantAlternativeEntry: cn=Verw-al,ou=users,ou=Verwaltung,ou=firma,dc=example,dc=net ------------ That works fine. dc=example,dc=net has the "postaladdress" from ou=firma and dc=example,dc=net has the "mobile" as "telephonenumber" from "cn=verw-al" But now I like to set the attribute "telephonenumber" for all users in ou=users,ou=verwaltung,ou=firma,dc=example,dc=net" to the "telephonenumber" of "ou=firma,dc=example,dc=net". So I have to deal with RegEx here. I took a look at the example in the manpage and I'm even more confused. I tried the following: -------------------------- dn: name=verw-tel,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantRegex olcVariantEntryRegex: cn=.+,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net dn: olcVariantVariantAttribute=telephonNumber,name={1}verw-tel,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantAttributePattern olcVariantVariantAttribute: telephoneNumber olcVariantAlternativeAttribute: telephoneNumber olcVariantAlternativeEntryPattern: ou=Verwaltung,ou=firma,dc=example,dc=net -------------------------- The first entry: dn: name=verw-tel,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config Is telling me who should get the value from the shared attribute. Right? That's the way it works without RegEx. The second entry should point to the object and it's attribute to share. Right? So in "ou=verwaltung,...." I have the attribute "telephoneNumber" set and this should be shared. But If I try to add the entries. The first entry works. But the second entry gives the following error message: --------------- adding new entry "olcVariantVariantAttribute=telephonNumber,name={1}verw-tel,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config" ldapadd: update failed: olcVariantVariantAttribute=telephonNumber,name={1}verw-tel,olcOverlay={5}variant,olcDatabase={2}mdb,cn=config ldap_add: Can't contact LDAP server (-1) --------------- And as you can see, adding the entry crashes the slapd. Can someone tell me the right way to use variant with regex?

3 6

Mapping the groupOfNames' owner attribute to members' Manager attribute
by sysadm+ldap-technical＠rolep.work 14 May '23

14 May '23

Hello, Is there any way to map the groupOfNames' owner attribute to members' Manager attribute without external scripts?

2 2

[About lmdb's write performance] mdb_txn_commit blocking for a long time
by Wang Zhiyong 06 May '23

06 May '23

Hello all. We are using lmdb in our own storage service and recently found a write performance issue. The phenomenon is that lmdb batch write is very slow, and a write transaction operation takes several minutes. For example, if a transaction writes 100,000 kv, the average value size is 100 bytes, and it takes 5 minutes. The size of lmdb data file is 460G. The analysis using perf is as follows: 53.14% liblgraph.so [.] mdb_page_alloc.isra.21 46.81% liblgraph.so [.] mdb_midl_xmerge 0.01% [kernel] [k] __check_object_size 0.01% [kernel] [k] __do_page_fault 0.01% [kernel] [k] __fput 0.01% [kernel] [k] get_futex_value_locked 0.01% [kernel] [k] radix_tree_descend 0.01% libpthread-2.17.so [.] __errno_location The cpu are consumed on the two functions mdb_page_alloc and mdb_midl_xmerge. By adding time statistics, I found that the blocking is in the mdb_freelist_save function in mdb_txn_commit. I'm not familiar with lmdb source code, can anyone explain why mdb_freelist_save consumes so much time? is this the expected result when lmdb data gets bigger? Is there any way to restore the write performance after the write becomes worse? What is the suggestion to improve the write performance of lmdb?

3 5

RE: Issues deploying openldap 2.6.4 Proxy on RHEL 8.7
by Vikram Sharma 04 May '23

04 May '23

Hello Support, Please see the screenshot for more information. [cid:image001.png@01D97E87.92DA8720] Warm Regards, Vikram Sharma Vikram.Sharma(a)investec.co.in<mailto:Vikram.Sharma@investec.co.in> Investec Global Services (India) Pvt. Ltd. Tel: +91 22 68497512 Mob: +91 9930600995 From: Vikram Sharma Sent: 04 May 2023 11:22 To: openldap-technical(a)openldap.org Cc: Amit Kulkarni <Amit.Kulkarni(a)investec.co.in>; Wyvern Bozec-Pearce <Wyvern.Bozec-Pearce(a)investec.co.uk> Subject: Issues deploying openldap 2.6.4 Proxy on RHEL 8.7 Hello Support, We are trying to deploy Openldap proxy from the available package from the openldap site version 2.6.4 on the Red Hat Enterprise Linux version 8.7 ootpa. We are aware that Red Hat enterprise 8.7 support openldap clients however, installing openldap-server is not supported. We are referring to the support tech link https://computingforgeeks.com/install-configure-openldap-server-centos/ to deploy openldap 2.6.4 however, when the deployment installation is completed following steps we are unable to start slapd service as slapd.d file is missing can we get some guidance on this please? Download site - https://www.openldap.org/software/download/OpenLDAP/openldap-release/ Install Procedure ------------------------------------------------------------------------------------------- #login as root user sudo su - #update required as pre-requisite sudo dnf update -y #restart once update is completed. sudo reboot #install the required dependencies sudo dnf install wget vim cyrus-sasl-devel libtool-ltdl-devel openssl-devel libdb-devel make libtool autoconf tar gcc perl perl-devel -y #create a non-privileged system user for OpenLDAP. sudo useradd -r -M -d /var/lib/openldap -u 55 -s /usr/sbin/nologin svcldapusr #Download the openldap tgz file from site https://www.openldap.org/software/download/OpenLDAP/openldap-release/ Transfer the file via Winscp and extract tar xzf openldap-$VER.tgz #Install OpenLDAP on RHEL 8 sudo mv openldap-$VER /opt # Change your working directory to OpenLDAP source. cd /opt/openldap-$VER #Install Development Tools: sudo dnf groupinstall "Development Tools" -y #Compile the source files sudo ./configure --prefix=/usr --sysconfdir=/etc --enable-debug --with-tls=openssl --with-cyrus-sasl --enable-dynamic --enable-crypt --enable-spasswd --enable-slapd --enable-modules --enable-rlookups #Upon successful compilation, you should see an output that says: "Please run "make depend" to build dependencies" #Run make depend to build OpenLDAP dependencies. sudo make depend #Compile OpenLDAP. sudo make #Install OpenLDAP on RHEL 8: sudo make install #A successful installation creates configuration files at /etc/openldap. The following files are available after installation: $ ls /etc/openldap certs ldap.conf ldap.conf.default schema slapd.conf slapd.conf.defaul Warm Regards, Vikram Sharma Vikram.Sharma(a)investec.co.in<mailto:Vikram.Sharma@investec.co.in> Investec Global Services (India) Pvt. Ltd. Tel: +91 22 68497512 Mob: +91 9930600995 Investec Bank plc is authorised and regulated by the UK Financial Services Authority. Registered in England and Wales (No. 489604). Registered office at 30 Gresham St, London EC2V 7QP. Investec Asset Finance Plc is a subsidiary of Investec Bank plc. Registered in England and Wales (No. 2179313). Registered office at Reading International Business Park, Reading RG2 6AA. We may monitor e-mail traffic data and the content of email. Calls may be monitored and recorded. If we collect personal information, the personal information we have collected from you will be shared with fraud prevention agencies who will use it to prevent fraud and money-laundering and to verify your identity. If fraud is detected, you could be refused certain services, finance or employment. For further details on how your information will be used by Investec and these fraud prevention agencies, and your data protection rights, please refer to our Fraud Prevention Notice https://www.investec.com/en_gb/legal/UK/fraud-prevention-notice.html This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This e-mail is subject to terms available at the following link: www.investec.co.uk/emaildisclaimer. By communicating electronically with us, you consent to these terms.

2 1

Unable to filter only group name
by BANDANI MAHARANA 03 May '23

03 May '23

Hi team, I am facing problem with filtering the group names in Ad server using openldap libraries. I am using ldap search api to get the list of group. My requirement is, with the provided input, i need to display all the available group similar to the entered group name. For example, if user types dev, it should display all the group names starting with dev. Like develop, development Kindly suggest how to achieve this. Thank you Bandani

2 1

olcPPolicyForwardUpdates not working
by Benjamin Renard 03 May '23

03 May '23

Hello, I have problem with the olcPPolicyForwardUpdates option that seem not working : On master and slave, I configured Ppolicy with pwdLockout. When I try to connect on master with a bad password, the pwdFailureTime attribute of the entry is successfully updated, but not if I do the same on the slave. On slave, my ppolicy configuration is exactly the same as on master but I add olcPPolicyForwardUpdates=TRUE. I also configured the chain overlay and the updateref parameter on the database. Extract of my slave configuration : olcDatabase={1}mdb,cn=config [...] olcSyncrepl: [...] olcUpdateRef: ldaps://ldap-master olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig objectClass: top olcOverlay: {0}chain olcChainReturnError: TRUE olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase objectClass: top olcDatabase: {0}ldap olcDbURI: ldaps://ldap-master olcDbIDAssertBind: bindmethod=simple binddn="[same user used in olcSyncrepl of the database]" credentials="secret" mode=self olcDbRebindAsUser: TRUE olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: TRUE Do you have any idea of what I doing wrong ? Thanks, -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

3 17

idea for possible RFE: universally unique connection IDs
by Christopher Paul 29 Apr '23

29 Apr '23

Hello OpenLDAP-Technical, I would like to seek comments on an idea I have had for a while. Does anyone agree with me that it would be nice if connection IDs were uuids? Because when your slapd restarts, your monitoring system has no good way to track one "conn=1000" from another one (or from one server to another), and so forth. Would there be any downsides to this? Are there any upsides to re-using integers starting at 1000? I can think of one: with incrementing integers, you can tell the order of the connections with them. Thanks, Chris Paul | Rex Consulting | https://www.rexconsulting.net

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical