openldap-technical

openldap-technical@openldap.org

2 participants
9915 discussions

pwdMaxIdle does not work as described in OpenLDAP 2.5
by Windl, Ulrich 01 Aug '25

01 Aug '25

Hi! I was playing with olcLastBind and pwdMaxIdle, setting up a test user and a test policy. However when the account should have been expired, nothing happened, i.e.: the user still could log in and change the password. Here are some details from the sample (variables have a different name, but you should be able to correlate them): ACCT_CHANGED = "20250728081545Z" ACCT_MAX_IDLE = "250000" AUTH_TIMESTAMP = "20250728081545Z" CURRENT_TIME_T = "1754049116" POLICY_CHANGED = "20250716131620Z" POLICY_NAME = "PP-Testing" SOURCE_NAME = "LDAP Password Policy" USER_ID = "testuser" I'm using the lastbind overlay and these settings: olcLastBindPrecision: 432000 olcLastBindForwardUpdates: TRUE My program calculated that the account had expired 1.256 days ago. Am I missing something, or is it a bug? Should there be an index on the authTimestamp attribute? Do I have to set olcLastbind to TRUE also? (I avoided that, because in 2.5 I cannot delay updates to the attribute, and some periodic automated logins flood the syncrepl changelog that way.) Kind regards, Ulrich Windl

2 1

Use lmdb for lookup of dentries?
by stefbon＠gmail.com 30 Jul '25

30 Jul '25

Hi, I'm writing FUSE fs's, and need a method for doing lookups for of dentries and inodes. To start with dentries, a FUSE lookup uses the parent inode ino (an uint64_t) and the name. Now I've expirmented a lttle creating a key like: - first 8 bytes used by parent inode ino, left padded with zeros. - rest the name of the entry like 00000001dexample which is the directory dexample in directory with ino 1. (to make this work custom locking is required) It works, but is it a good idea to do? Or are there other methods better? S.Bon

2 3

Transform glue object to organizationalUnit
by cyril＠stoll.info 29 Jul '25

29 Jul '25

Hi For some reason (probably after update to openldap-ltb 2.6.10, or after reload due to renewed certificate) we lost one organizationalUnit object on one of our two provider servers. However there are still two user objects that belong to this lost organzationalUnit. Therefore openldap created a glue object for the lost organizationalUnit. On the second provider server (setup as multiprovider with the first one) the organzationalUnit object is still present and all looks like it should. I have no idea why one of the providers is still ok and the other is not since they are otherwise in sync as far as I can tell. Unfortunately I did not find clear instructions on how to handle this situation. The best instructions I found are 15 years old: http://blog.mycroes.nl/2010/06/recovering-from-glue-objects-in.html I have no experience with dumping everything with slapcat, deleting the whole database directory (scary) and importing everything again and it does sound a bit brutish. So I asked some AI and it suggested to use ldapmodify to replace the glue object with an ldif like this: dn: ou=serviceusers,dc=example,dc=com changetype: modify add: objectClass objectClass: organizationalUnit - add: ou ou: serviceusers However that did not work as I got the following error message: modifying entry "ou=serviceusers,dc=example,dc=com" ldap_modify: No such object (32) matched DN: ou=serviceusers,dc=example,dc=com So my question is do I have to use the method of dumping everything with slapcat and then changeing the ldif (rewrite glue to organziationalUnit, etc.) and importing it all again? Or is there a more elegant solution to get the organizationalUnit back? Thanks already in advance for every helping suggestion/link/explanation! Best regards, Cyril

4 7

Q: Using sssd authTimestamp isn't updated with lastbind enabled on some clients
by Windl, Ulrich 28 Jul '25

28 Jul '25

Hi! I discovered an odd problem: If a user logs in on some clients, the OpenLDAP 2.5 server does not update authTimestamp, while on other clients the timestamp is updated (and synchronized across all servers). All clients use the same OS (SLES15) and sssd. The only difference I could find was the order of modules: services = pam,nss vs. services = nss, pam Sections for [pam] and [nss] are both empty. Caching credentials is disabled ("false") also. I thought if sssd authenticates using the OpenLDAP server, the server itself would update the authTimestamp. Can anybody enlighten me (e.g. how to debug)? Kind regards, Ulrich Windl

2 1

Use lmdb for lookup of dentries?
by stefbon＠gmail.com 28 Jul '25

28 Jul '25

Hi, I'm writing a fuse fs, and need a method to do a lookup of a direntry. I want to know lmdb is an option here. (much reads, not a lot of writes). A lookup of a dentry is using the parent inode id and the name of the dentry. So you can create the key like: key = (parentino padded left with zeros to 8 positions) | dentry->name (note: a custom locking method is required to not lock the whole db) Now does anybod know this is a good method or are there better methods available? S. Bon

1 0

Question about lmdb.
by Stef Bon 27 Jul '25

27 Jul '25

Hi, can I ask a question about lmdb here? I've got a question about it and I cannot find another place. S. Bon

1 0

Re: Queries on openLDAP deployment on multi region on Kubernetes cluster
by Akunuri, Vithal 25 Jul '25

25 Jul '25

Hi Team, Can you please share your inputs on Queries on openLDAP deployment on multi region on Kubernetes cluster - openldap-technical - openldap.org<https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…> ? Vithal Akunuri

1 0

openldap-technical return-exact-case is set to "on"
by JM Lacombe 17 Jul '25

17 Jul '25

openldap to the "openldap-technical" mailing list openldap-technical(a)openldap.org hello like on SUN (odsee) : set config nsslapd-return-exact-case is set to "on" or off with openldap v2.6.6.3, how to get same feature ? and force return entryDN to lower case. best regards JM Lacombe email: jmlacombe(a)hotmail.com

3 6

Queries on openLDAP deployment on multi region on Kubernetes cluster
by vithal.akunuri＠tdsynnex.com 17 Jul '25

17 Jul '25

Hi, openldap-stack-ha was deployed as stateful set of 4 on multi region Kubernetes ( micro K8s ) cluster with 2 nodes in each region with multi master configuration. Application connections to LDAP are managed through kubernetes service. Multiple issues are noticed with this setup and would like to seek some guidance and feedback. 1. Frequent replication issues : For monitoring, script is being executed every 1 hour to check the replication status using check_syncrepl_extended command between all the providers and consumers. Is there any better to monitor the replication lag ? To recover from this issue, the pods are being recycled on the provider host which is out of sync. Is there any guidance of deploying LDAP in multi region ? Is multi master recommended in production environment for resiliency and performance? 2. Bulk upload : Is there any guidance on doing bulk upload into LDAP in this current setup? Thanks, Vithal

1 0

Two questions understanding delta-syncrepl
by Windl, Ulrich 17 Jul '25

17 Jul '25

Hi! I'm getting more experience with delta-syncrepl, but I still have two questions I'm unsure about: 1. In contrast to plan syncrepl, is it true that plain syncrepl will sync contents "from the past" (i.e. content changed before syncrepl had been activated), whereas delta-syncrepl will nor sync changes that were made before delta-syncrepl had been activated (i.e. sync only "new changes"" mad after the delta-syncrepl configuration? (see below, also) 2. Is it expected that the entryCSNs are identical for a synced entry on each server? I use a check that compare the UUID and the CSN for each entry to verify synchronization, but I see small differences (example below) For question #1: Specifically I have these messages (from today when establishing a new RID) in mind: slapd[22664]: conn=35370 op=2 syncprov_findbase: searching slapd[22664]: conn=35370 op=2 syncprov_op_search: registered persistent search slapd[22664]: conn=35370 op=2 syncprov_play_accesslog: accesslog information inadequate for log replay on csn=20250707100648.450369Z#000000#001#000000 slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_CSN csn=20250707100648.450369Z#000000#001#000000 slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn==20250707100648.450369Z#000000#001#000000 not found slapd[22664]: conn=35370 op=2 syncprov_findcsn: csn<=20250707100648.450369Z#000000#001#000000 found slapd[22664]: conn=35370 op=2 syncprov_findcsn: mode=FIND_PRESENT csn= slapd[22664]: conn=35370 op=2 syncprov_sendinfo: present syncIdSet cookie= (and actually some changes made on that server recently were not synced to the other servers that should "pull" from this one) For question #2: On example I found (comparing server #2 with server #3) was: -uid=... (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.785857Z#000000#002#000000 +uid=... (c3e62200-55af-1038-9b76-9916ef1a4822): 20250716105944.780532Z#000000#002#000000 So there's a difference in the 5ms area, and (AFAIK) both changes originate from server #2. The corresponding changelog looks like this: dn: reqStart=20250716105944.000001Z,cn=changelog-1 objectClass: auditModify structuralObjectClass: auditModify reqStart: 20250716105944.000001Z reqEnd: 20250716105944.000003Z ... entryCSN: 20250716105944.780532Z#000000#002#000000 ... And that change is the only change made that second. Server #2 logged for sending the change to server #3: slapd[1811445]: conn=1020 op=2 syncprov_sendresp: to=003, cookie=rid=112,sid=002,csn=20250716105944.780532Z#000000#002#000000 Server #3 logged for receiving the change: slapd[2528537]: conn=-1 op=0 syncprov_add_slog: adding csn=20250716105944.780532Z#000000#002#000000 to sessionlog, uuid=c3e62200-55af-1038-9b76-9916ef1a4822 slapd[2528537]: slap_queue_csn: queueing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000 slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4816df90 20250716105944.780532Z#000000#002#000000 slapd[2528537]: slap_queue_csn: queueing 0x7f2d4818bf70 20250716105944.780532Z#000000#002#000000 slapd[2528537]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=reqStart=20250716105944.000001Z,cn=changelog-1 on opc=0x7f2d48002be0 slapd[2528537]: conn=1008 op=2 syncprov_qresp: set up a new syncres mode=1 csn=20250716105944.780532Z#000000#002#000000 ... slapd[2528537]: do_syncrep2: rid=113 cookie=rid=113,sid=003,csn=20250716105944.780532Z#000000#002#000000 slapd[2528537]: do_syncrep2: rid=113 CSN too old, ignoring 20250716105944.780532Z#000000#002#000000 (reqStart=20250716105944.000001Z,cn=changelog-1) slapd[2528537]: slap_graduate_commit_csn: removing 0x7f2d4814fd10 20250716105944.780532Z#000000#002#000000 (next change was several minutes later; rid113 would mean server #3 (sid 3) would try sync to itself (MMR on cn=config artefact)) Kind regards, Ulrich Windl

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical