openldap-technical February 2024

openldap-technical@openldap.org

20 participants
18 discussions

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2024