389-users October 2025

389-users@lists.fedoraproject.org

7 participants
4 discussions

Shadow attributes in search
by Jonathan Buzzard 12 Nov '25

12 Nov '25

Some background, for the last ~20 years we have used NIS in combination with Kerberos against the Universities AD for AAA on our HPC systems. For a variaty of reasons when we get a new user we create an account in NIS with the same username as they have in the AD. For about the last 10 years this has been automated with a Perl script so you just provide the username and the account in NIS is created. With the advent of RHEL9 NIS is gone so we are replacing the NIS servers with a LDAP setup using 389-ds. Pass through authentication to the AD is for another day. I have one more task before the project is finished. There is a Perl script that is run daily which iterates through all the users and for those that are not passed the expiry date in shadow checks against the AD and if they are expired in the AD sets the shadow expiry date to the day before. This needs porting to work against the LDAP servers. We also use the shadow expiry to set an expiry date on the accounts of certain classes of users at account creation time. The problem is when my Perl script is iterating through the users in LDAP using Net::LDAP unless I bind with Directory Manager the shadowExpire attribute is not returned. LDAP is not my thing but I get the feeling I need to use an ACI to allow the account I am using to bind to search the LDAP access to the shadow attributes. Note actually changing of the attributes is a "cheat" system call to dsidm from the Perl script because it runs as root on the LDAP servers themselves but that doesn't provide a nice interface to iterate through the users. I am also setting nsAccountLock to true for good measure. My question is am I correct that an ordinary LDAP user cannot see the shadow attributes of another account? Secondly if I am right in the first question how do I setup an ACI so a particular user can indeed see the shadowExpire of all the users? JAB. -- Jonathan A. Buzzard Tel: +44141-5483420 HPC System Administrator, ARCHIE-WeSt. University of Strathclyde, John Anderson Building, Glasgow. G4 0NG

2 2

Re: How to activate server-side sorting?
by Mark Reynolds 29 Oct '25

29 Oct '25

On 10/29/25 5:19 PM, Johnnie Adams wrote: > Hi, Mark, > > When you say 'there is no way to "tune"' sorting, does that mean > that indexing won't help? Correct, sorting does not use indexes. Not sure how you could index sorted results since there are countless ways you can sort result sets. So sorting takes the resulting entries (which might be gathered by indexes) but then it reorders/sorts them based on the sort control provided. The other option would be to use VLV indexes which are sort of predefined sorted results. VLV searches are a bit more complicated though: https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/m… Mark > > Thanks, > > John A -- Identity Management Development Team

2 1

How to activate server-side sorting?
by Johnnie Adams 29 Oct '25

29 Oct '25

Hi, Is it as simple as indexing the attributes I want to sort on? Thanks, John A

2 1

Replication. MemberOf plugin generating duplicate changes
by vectinx 17 Oct '25

17 Oct '25

Hello, List! I'm using 389-ds as part of a FreeIPA deployment on AlmaLinux 9 and have encountered some unexpected behavior. I have two servers configured for replication. When I delete a user on one server (via ipa user-del), the following entries appear in the replication changelog: dbscan -f /var/lib/dirsrv/slapd-TEST-LOC/db/userRoot/replication_changelog.db dbid: 68edda57000000040000 encrypted: no replgen: 1760418390 Tue Oct 14 08:06:30 2025 csn: 68edda57000000040000 uniqueid: 316c0981-a8bb11f0-b7c78566-a52e6fbb dn: uid=test2,cn=users,cn=accounts,dc=test,dc=loc operation: delete dbid: 68edda57000100040000 encrypted: no replgen: 1760418390 Tue Oct 14 08:06:30 2025 csn: 68edda57000100040000 uniqueid: 316c0983-a8bb11f0-b7c78566-a52e6fbb dn: cn=test,cn=groups,cn=accounts,dc=test,dc=loc operation: modify member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc modifiersname: cn=referential integrity postoperation,cn=plugins,cn=config modifytimestamp: 20251014050630Z entryusn: 2913 dbid: 68edda57000200040000 encrypted: no replgen: 1760418390 Tue Oct 14 08:06:30 2025 csn: 68edda57000200040000 uniqueid: 02ac4fb5-a83711f0-a3868566-a52e6fbb dn: cn=ipausers,cn=groups,cn=accounts,dc=test,dc=loc operation: modify member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc modifiersname: cn=referential integrity postoperation,cn=plugins,cn=config modifytimestamp: 20251014050630Z entryusn: 2914 dbid: 68edda57000300040000 encrypted: no replgen: 1760418390 Tue Oct 14 08:06:30 2025 csn: 68edda57000300040000 uniqueid: 316c0982-a8bb11f0-b7c78566-a52e6fbb dn: cn=test2,cn=groups,cn=accounts,dc=test,dc=loc operation: delete dbid: 68edda59000000030000 encrypted: no replgen: 1760418391 Tue Oct 14 08:06:31 2025 csn: 68edda59000000030000 uniqueid: 02ac4fb5-a83711f0-a3868566-a52e6fbb dn: cn=ipausers,cn=groups,cn=accounts,dc=test,dc=loc operation: modify member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config modifyTimestamp: 20251014050631Z dbid: 68edda59000100030000 encrypted: no replgen: 1760418391 Tue Oct 14 08:06:31 2025 csn: 68edda59000100030000 uniqueid: 316c0983-a8bb11f0-b7c78566-a52e6fbb dn: cn=test,cn=groups,cn=accounts,dc=test,dc=loc operation: modify member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config modifyTimestamp: 20251014050631Z This log shows that first, a user record is deleted on the replica with ID 4, then the referential integrity plugin clears this user's membership from groups, and then deletes the user's primary group. Then something unexpected happens: additional changes appear from the replica with ID 3 — the MemberOf plugin also removes the user from the groups. If I add another replica to the topology, it will also generate these same changes and send them to the others. With 2–3 replicas this isn’t a big deal, but if, for example, there are 20 replicas and a user is a member of 5 groups, then each replica will generate around 100 changes and attempt to replicate them to all others. I’m not sure if this is the expected behavior. It seems like there's excessive replication of changes, which could also impact performance. I haven’t found any documentation describing this behavior. Could anyone explain why the MemberOf plugin behaves this way, and whether this is considered an issue? I tested this with 389-ds 2.3.2 and 2.6.1, and observed the same duplicated MemberOf changes in both. Thanks in advance!

4 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users October 2025