389-users

389-users@lists.fedoraproject.org

5 participants
6627 discussions

memberOf plugin returns far fewer results than expected.
by Bob Green 16 Dec '25

16 Dec '25

I have some groups with as many as 30K+ members. After enabling the memberOf plugin, ldap queries such as "(memberof:=cn=large_group,ou=groups,dc=org,dc=com)", only return a partial list of members. I've increased the following cn=config attributes but am not seeing an increase in records returned: nsslapd-sizelimit nsslapd-lookthroughlimit nsslapd-idlistscanlimit I've been experimenting with various levels of logging to try to understand what might be preventing all of the records being returned, and have the following currently configured: nsslapd-accesslog-level: 514 nsslapd-errorlog-level: 114688 nsslapd-plugin-logging: on nsslapd-securitylog-level: 256 nsslapd-statlog-level: 0 I have yet to tweak any OS or application settings in regards to cache or anything else that might be warranted considering the number of ldap entries I expect to serve, so I expect there's work to be done in that regard. However I've yet to find any debug log to point me in the direction of figuring out why memberOf is only providing a partial list of all matching entries. Any advice on what log levels I might consider or what config attributes I should focus on to see about addressing my issue? Thank you, Bob My test platform: % grep SUSE /etc/*release PRETTY_NAME="SUSE Linux Enterprise Server 15 SP6" % rpm -q 389-ds 389-ds-2.2.10~git146.78a60e3ac-150600.8.23.1.x86_64

2 3

dsconf idempotency
by Marco Favero 07 Dec '25

07 Dec '25

Hello, I like to use [dsconf](https://directory.fedoraproject.org/docs/389ds/design/dsadm-dsconf.… to manage my 389ds instances. I like also Ansible to manage the configuration. From Ansible, if I run dsconf command I see some problems of idempotency. For example, if I run the first time in a new fresh installation ``` dsconf -D cn=Directory Manager -w **** ldap://localhost:389 plugin attr-uniq set attribute uniqueness --subtree=c=en --enabled=on --attr-name=uid --across-all-subtrees=off ``` it returns 0 and the output *Successfully changed the cn=attribute uniqueness,cn=plugins,cn=config*. If I re run the same command I will see: *There is nothing to set in the cn=attribute uniqueness,cn=plugins,cn=config plugin entry* and the exit status is 1. Of course I can manage the output in Ansible in order to reclassify as well the task result. But I have to do that in a lot of cases (best effort). Of course I can use some idempotent ldapmodify module, but I like to trust `dsconf`. So I wonder if you could consider the benefit to make `dsconf` more idempotent. For instance, in the above case the exit status could be 0. The same behavior could be adopted in all results of "already exists" output messages when the value to set is equal to the value already present (ie: `dsconf -D cn=Directory Manager -w *** ldap://localhost:389 backend index add ...` returns "already exists" and the exit status 1 if the idex is already defined) If you have any other hints to address this problem could let me know. Thank you very much Kind Regards Marco

4 4

Extending the schema
by Johnnie Adams 02 Dec '25

02 Dec '25

Hi, folks, I thought this would be as simple as moving *.ldif files from our old directory server's schema directory to the new one, but this appears not to be working. I suspect this is a deep subject, so I'll stop here. Thanks, John A -- John Adams Senior Linux/Middleware Administrator | Information Technology Services +1-501-916-3010 | jxadams(a)ualr.edu | http://ualr.edu/itservices *UA Little Rock* Reminder: IT Services will never ask for your password over the phone or in an email. Always be suspicious of requests for personal information that come via email, even from known contacts. For more information or to report suspicious email, visit IT Security <http://ualr.edu/itservices/security/>.

4 7

slow single user ldif import with DNA plugin enabled
by Antonis Kopsaftis 28 Nov '25

28 Nov '25

Hello, I have a two-node 389ds cluster with Oracle Linux 9.7 x64 servers running 389 version 2.4.6 (compiled following the instructions from the official page of 389ds). Each server is a VM with 4vcpus and 10GB RAM on fast FC SSD storage. The cluster until now is used for testing and is running pretty well with over 150.000 records. The DNA plugin is enabled to each server for the uidnumber attribute (using different range in each server). On our latest tests we discovered that during an import (using ldapmodify with ldif file) of an single user it takes around 8 seconds to complete the import when the DNA plugin is used to auto allocate the uidnumber. 8 seconds is a lot for a single import!! When the same import is done, without using the DNA plugin (the ldif file defines the uidnumber), the import is completed instantly. I tried to found out what maybe caused the delay (for example the replication between the servers) but i havent managed to find anything. I also disabled the replication for testing, but nothing changed. As the 2.4.6 version is not the latest of the 2.x series, i installed another two-node 389ds cluster with Oracle Linux 9.7 x64 servers running 389 version 2.7.0 (compiled also by following the instructions from the official page of 389ds). I did the same import tests, but the time did not change. When using the DNA plugin the import of a single user ldif takes 8 seconds. The funny thing is, that when using our older two-node 389ds cluster with Centos 7 x86 servers running 389 version 1.3.7 the import with the DNA plugin is completed instantly. Any ideas why the DNA plugin is so slow in versions 2.4.6 and 2.7.0?? Antonis Kopsaftis

2 1

lib389 3.1.3 is now available on PyPI
by Simon Pichugin 20 Nov '25

20 Nov '25

lib389 3.1.3 The 389 Directory Server team is proud to announce lib389 version 3.1.3. lib389 is now available on PyPI: https://pypi.org/project/lib389/3.1.3/ Installation To install lib389 from PyPI use: pip install lib389==3.1.3 What is lib389 lib389 is a Python library and CLI toolset for managing and testing 389 Directory Server. It includes dsconf, dsctl, dsidm, dscreate, and more. *Important Note:* Ensure that the lib389 version matches the version of the 389 Directory Server you plan to connect to. Documentation - PyPI Package: https://pypi.org/project/lib389/ - Documentation: https://www.port389.org/docs/389ds/documentation.html - GitHub Repository: https://github.com/389ds/389-ds-base Feedback We are very interested in your feedback! 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… 389ds discussion channel: https://github.com/389ds/389-ds-base/discussions If you find a bug, or would like to see a new feature, file it in our GitHub project: https://github.com/389ds/389-ds-base Best Regards, The 389 Directory Server Team

1 0

ACI Issues After 389-ds Package Upgrade
by Trenc, Mike 20 Nov '25

20 Nov '25

Hi everyone, We recently performed OS patching within our Test LDAP environment consisting of six RHEL 9 servers (2 primaries and 4 replicas) such that it upgraded from Red Hat Enterprise Linux release 9.6 to Red Hat Enterprise Linux release 9.7. During the patching process, the 389-DS packages below were also updated. 389-ds-base-2.6.1-12.el9_6.x86_64 ===> 389-ds-base-2.7.0-7.el9_7.x86_64 389-ds-base-libs-2.6.1-12.el9_6.x86_64 ===> 389-ds-base-libs-2.7.0-7.el9_7.x86_64 Shortly after patching and rebooting, we noticed an issue whereby the service accounts associated with applications in our Test environment were no longer able to search the OU that they were previously able to search successfully prior to patching. To correct the issue, we ended up moving the ACIs associated with application service accounts one level higher in the OU. As an example, below represents the change that we made to an ACI before and after the OS patching event to resolve the issue: Original pre-patching ACI when service account searches were successful: DN: ou=people,dc=university,dc=edu (targetattr = "*") (version 3.0;acl "app-user";allow (read,search,compare)(userdn = "ldap:///uid=app-user,ou=ldap-apps,dc=university,dc=edu");) Post-Patching change made when service account searches no longer worked with the above original ACI configuration: DN: dc=university,dc=edu (targetattr = "*") (version 3.0;acl "app-user";allow (read,search,compare)(userdn = "ldap:///uid=app-user,ou=ldap-apps,dc=university,dc=edu");) Has anyone else experienced any changes in ACI behavior when upgrading to the latest 389-ds-base-2.7.0-7 and 389-ds-base-libs-2.7.0-7 packages? Thanks, Mike — Michael Trenc Senior DevOps Engineer | Technology Partner Services Harvard University Information Technology P:(617) 496-6544 | W:huit.harvard.edu<https://huit.harvard.edu/>

3 2

Shadow attributes in search
by Jonathan Buzzard 15 Nov '25

15 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

3 5

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

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users