389-users November 2025

389-users@lists.fedoraproject.org

5 participants
3 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

SSL error after upgrade
by Michael DiDomenico 06 Nov '25

06 Nov '25

we upgraded from rhel9.5 to 9.6 and now our 389ds server is throwing this error ERR Security Initialization SSL failure: Security Initialization - slapd_ssl_init2 - Failed to set SSL range: min: TLS1.0, max: TLS1.0 - error -8190 (security library: received bad data) as far as i can tell ldap on port 389 is still working, so it's only affecting the TLS side of things, but i can't seem to figure out what's gone wrong. i have a case open with redhat, but maybe someone here might have a suggestion thanks

3 7

Deleting attributes using dsidm
by Jonathan Buzzard 06 Nov '25

06 Nov '25

Is there a reason behind the need to supply the existing value of an attribute for a user when deleting it? For example if I want to enable an account which had a shadowExpire attribute set then the logical thing to do would be dsidm -b <basedn> ldap1 user modify testuser delete:shadowExpire because I really don't care what the existing value is and for that matter I don't actually know what it is. This would be analogous to doing chage -E -1 testuser on a traditional /etc/shadow based system, where using -1 as the date simply removes the expire entry from /etc/shadow. In my mind, in general if I want to delete an attribute from a user it seems bizarre that I need to know what it is. I mean I can modify the value without knowing what it is so why the need to know what it is to delete it? JAB. -- Jonathan A. Buzzard Tel: +44141-5483420 HPC System Administrator, ARCHIE-WeSt. University of Strathclyde, John Anderson Building, Glasgow. G4 0NG

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2025