openldap-technical February 2024

openldap-technical@openldap.org

20 participants
20 discussions

openldap TLSv1.0 is enabled
by Andre Rodier 16 May '25

16 May '25

Hello, I have configured OpenLDAP using SSL certificate, but I have a few issues. Here the TLS configuration, especially "olcTLSProtocolMin: 3.3" > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 c70363a6 > 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: 40ee991a-0efe-103d-855a-11ff3a5638b4 > creatorsName: cn=config > createTimestamp: 20221213065102Z > olcPasswordCryptSaltFormat: $6$%.16s > olcTLSCACertificateFile: /etc/ldap/certs/ldap.homebox.world.issuer.crt > olcTLSCertificateKeyFile: /etc/ldap/certs/ldap.homebox.world.key > olcTLSCertificateFile: /etc/ldap/certs/ldap.homebox.world.crt > olcTLSProtocolMin: 3.3 > entryCSN: 20221214054517.926245Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20221214054517Z But if I try sslscan: I see TLSv1.0, TLSv1.1 and TLSv1.2 enabled. Why ? > root@main:/etc/ldap/changes# sslscan ldap.homebox.world:636 > Version: 2.0.7 > OpenSSL 1.1.1n 15 Mar 2022 > > Connected to 2001:19f0:7402:86e:5400:4ff:fe38:b9b4 > > Testing SSL server ldap.homebox.world on port 636 using SNI name ldap.homebox.world > > SSL/TLS Protocols: > SSLv2 disabled > SSLv3 disabled > TLSv1.0 enabled > TLSv1.1 enabled > TLSv1.2 enabled > TLSv1.3 enabled > > TLS Fallback SCSV: > Server supports TLS Fallback SCSV > > TLS renegotiation: > Secure session renegotiation supported > > TLS Compression: > OpenSSL version does not support compression > Rebuild with zlib1g-dev package for zlib support > > Heartbleed: > TLSv1.3 not vulnerable to heartbleed > TLSv1.2 not vulnerable to heartbleed > TLSv1.1 not vulnerable to heartbleed > TLSv1.0 not vulnerable to heartbleed > > Supported Server Cipher(s): > Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253 > Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253 > Accepted TLSv1.3 128 bits TLS_AES_128_CCM_SHA256 Curve 25519 DHE 253 > Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.2 256 bits AES256-GCM-SHA384 > Accepted TLSv1.2 256 bits AES256-CCM > Accepted TLSv1.2 128 bits AES128-GCM-SHA256 > Accepted TLSv1.2 128 bits AES128-CCM > Accepted TLSv1.2 256 bits AES256-SHA > Accepted TLSv1.2 128 bits AES128-SHA > Preferred TLSv1.1 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.1 256 bits AES256-SHA > Accepted TLSv1.1 128 bits AES128-SHA > Preferred TLSv1.0 256 bits ECDHE-RSA-AES256-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 128 bits ECDHE-RSA-AES128-SHA Curve 25519 DHE 253 > Accepted TLSv1.0 256 bits AES256-SHA > Accepted TLSv1.0 128 bits AES128-SHA > > Server Key Exchange Group(s): > TLSv1.3 128 bits secp256r1 (NIST P-256) > TLSv1.3 192 bits secp384r1 (NIST P-384) > TLSv1.3 260 bits secp521r1 (NIST P-521) > TLSv1.3 128 bits x25519 > TLSv1.3 224 bits x448 > TLSv1.3 112 bits ffdhe2048 > TLSv1.3 128 bits ffdhe3072 > TLSv1.3 150 bits ffdhe4096 > TLSv1.3 175 bits ffdhe6144 > TLSv1.3 192 bits ffdhe8192 > TLSv1.2 128 bits secp256r1 (NIST P-256) > TLSv1.2 192 bits secp384r1 (NIST P-384) > TLSv1.2 260 bits secp521r1 (NIST P-521) > TLSv1.2 128 bits x25519 > TLSv1.2 224 bits x448 > > SSL Certificate: > Signature Algorithm: sha256WithRSAEncryption > RSA Key Strength: 2048 > > Subject: ldap.homebox.world > Altnames: DNS:ldap.homebox.world > Issuer: (STAGING) Artificial Apricot R3 > > Not valid before: Dec 13 05:34:29 2022 GMT > Not valid after: Mar 13 05:34:28 2023 GMT Thanks for your insights. Andre

6 13

Re: Replication issue during performance test with MMR configuration and LastBind enabled
by Falgon 16 Oct '24

16 Oct '24

Hello, I'm working on the same project as Meheni. Thanks for your answer, we'll try version 2.6 OpenLDAP using the lastbind-precision. However we have several questions for the current version we're using. Is this a known problem and referenced somewhere? (we haven't found it) Is it normal to find no replication error logs even in stats + sync mode? We ran some tests in sequential mode (300,000 accounts one after the other) and managed to reproduce the problem. -Denis Le mer. 11 oct. 2023 à 14:11, Quanah Gibson-Mount <quanah(a)fast-mail.org> a écrit : > > > --On Tuesday, October 10, 2023 9:30 PM +0200 Ziani Meheni > <mehani06(a)gmail.com> wrote: > > > > > > > Hello, we are working on a project and we've come across a problem with > > the replication after performance testing : > > You need to use OpenLDAP 2.6 and then set the: > > lastbind-precision > > value. I use 5 minutes. > > --Quanah >

4 8

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 15 Feb '24

15 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 12 Feb '24

12 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2024