389-users January 2021

389-users@lists.fedoraproject.org

17 participants
18 discussions

ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett 11 Dec '23

11 Dec '23

Hi all, We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this: [12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”) Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”. Has anyone seen this kind of thing before? This is 389ds running on CentOS7 as follows: 389-ds-base-1.3.9.1-10.el7.x86_64 Regards, Graham —

3 9

Plugin development licensing
by DUVERT Vincent 09 May '23

09 May '23

Hello, I have a question regarding the licensing of developed 389-ds plugins. The FAQ (https://directory.fedoraproject.org/docs/389ds/FAQ/licensing.html#directory…) indicates that the Directory Server core code is licensed under a GPL + Exception license that allows non-GPL 389-ds plugins to link to 389-ds and to use specific header files. However, the LICENSE file in the current 389-ds-base source does not contain this exception. It was apparently removed by the following commit, when the license was changed to GPLv3+: https://pagure.io/389-ds-base/c/88cae401aee39a19ac6b07c3c36ee8daa07192e7 Does that means that the license exception does not apply to the current version of 389-ds? Regards, Vincent Duvert

2 2

Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers 01 Feb '21

01 Feb '21

I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag. The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object: objectclass: nsds5ReplicationAgreement nsds5replicahost: <consumer-hostname> nsds5replicaport: 389 nsds5replicatransportinfo: TLS nsds5replicabindmethod: SSLCLIENTAUTH Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request): Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate) The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't. The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available. Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know? The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3. Thanks, Eugen

3 11

lib389 question
by Marco Favero 31 Jan '21

31 Jan '21

Hello, I'm new in this list, thank you for developing 389ds! I would like some hints about lib389. dscreate allows to set some parameters only when you create an instance. So it' very difficult to maintain all configuration parameters among db and instances and replicated instances. I'm writing my tool to manage all configuration parameters in one place (a yaml file). Just a wrapper for dsconf. See at https://github.com/falon/ds-easyconf I would like to call dsconf from an external host only, different from hosts where the 389ds run. So I have installed the python3-lib389 rpm in that different host. Let suppose I have tst1.example.com tst2.example.com tst3.example.com where 389ds Directory Server run after dscreate process. I have another host: manage.example.com where I have installed lib389 rpm only, and from that remote host I configure the tst*.example.com servers through dsconf. The problem is that dsconf exit with the error "defaults.inf not found in any well known location!". So I have taken the defaults.inf from a 389ds host (one of tst*.example.com) and I have placed it in the new path /usr/share/dirsrv/inf of manage.example.com. Now dsconf works fine. I would like to know if there are some reason to avoid to do that. Or, if simply the python3-lib389 forgot to install the defaults.inf in the proper path. Thank you very much Warm Regards Marco

2 4

plugin names and debian packages
by Angel Bosch Mora 28 Jan '21

28 Jan '21

hi! I'm testing my install recipes on debian and I've found two little problems. on CentOS I execute dsconf myinstance plugin retro-changelog enable but today I tried in debian and it says is an invalid choice: dsconf instance plugin: error: invalid choice: 'retro-changelog' (choose from 'memberof', 'automember', 'referint', 'rootdn', 'usn', 'accountpolicy', 'attruniq', 'dna', 'linkedattr', 'managedentries', 'passthroughauth', 'retrochangelog', 'whoami', 'list', 'get', 'edit') So retro-changelog is called now retrochangelog. Is that a Debian thing or it changed it's name on a recent version? In addition I executed the command with the new name and it gives me a message without a correct variable. dsconf myinstance plugin retrochangelog enable Enabled plugin '%s' Retro Changelog Plugin dsconf myinstance plugin retrochangelog status Plugin '%s' is enabled Retro Changelog Plugin it seems a cosmetic error but I just want to be sure if I need to open a bug. here are the version of the packages: dpkg -l | grep 389 ii 389-ds-base 1.4.0.21-1 amd64 389 Directory Server suite - server ii 389-ds-base-legacy-tools 1.4.0.21-1 amd64 Legacy utilities for 389 Directory Server ii 389-ds-base-libs:amd64 1.4.0.21-1 amd64 389 Directory Server suite - libraries ii python3-lib389 1.4.0.21-1 all Python3 module for accessing and configuring the 389 Directory Server thanks in advance, abosch -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent. Abans d'imprimir aquest missatge, pensau si es realment necessari.

4 8

Announcing 389 Directory Server 1.4.4.11
by Mark Reynolds 25 Jan '21

25 Jan '21

389 Directory Server 1.4.4.11 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.4.11 Fedora packages are available on Fedora 33. Fedora 33: https://koji.fedoraproject.org/koji/taskinfo?taskID=60484248 <https://koji.fedoraproject.org/koji/taskinfo?taskID=60484248> - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2021-5258e9cb11 <https://bodhi.fedoraproject.org/updates/FEDORA-2021-5258e9cb11> - Bohdi The new packages and versions are: * 389-ds-base-1.4.4.11-1 Source tarballs are available for download at Download 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-1.4.4.11.tar.gz> Highlights in 1.4.4.11 * Bug fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install the server use *dnf install 389-ds-base* To install the Cockpit UI plugin use *dnf install cockpit-389-ds* After rpm install completes, run *dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… <https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o…> 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 <https://github.com/389ds/389-ds-base> * Bump version to 1.4.4.11 * Issue 4548 - CLI - dsconf needs better root DN access control plugin validation * Issue 4513 - Fix schema test and lib389 task module (#4514) * Issue 4535 - lib389 - Fix log function in backends.py * Issue 4534 - libasan read buffer overflow in filtercmp (#4541) -- 389 Directory Server Development Team

1 0

one way windows sync exclude attributes
by Andry Michaelidou 19 Jan '21

19 Jan '21

Hi all, I am trying to have one way windows sync (from windows AD to LDAP) but i need to exclude some attributes. Is this possible? I cannot find any documentation on this. I already try this with 389ds running on CentOS7 and CentOS8 with no result. I am using nsDS5ReplicatedAttributeListTotal and nsDS5ReplicatedAttributeList attributes but i am still getting replicated values of the excluded attributes. I found this but i am not sure if this is the case: https://bugzilla.redhat.com/show_bug.cgi?id=800101 Can you please provide guidelines on this? Anyone try this before? Regards, -- Andry Michaelidou Papa | IT Systems Administrator|Department of Computer Science| University of Cyprus Tel: +357.22.892734 | Fax: +357.22.8927201 | http://www.cs.ucy.ac.cy/~andrim <http://www.cs.ucy.ac.cy/%7Eandrim>

2 3

Newbie question: What does NS stand for?
by Tom 19 Jan '21

19 Jan '21

A lot of config options, for example nsslapd-sizelimit, start with NS. What does NS stand for? Thanks in advance for tolerating a newbie with OCD!

3 2

Re: [EXT]Re: Restrict read/search permission on attribute with certain value?
by William Brown 18 Jan '21

18 Jan '21

> On 19 Jan 2021, at 03:40, Gary Windham <windhamg(a)arizona.edu> wrote: > > Thanks for the reply, WIlliam. We are using Internet2's Grouper (which synchronizes group memberships to our 389 DS) to create a "chain" of groups that are being used to implement a COVID-19 testing compliance policy at the University of Arizona. One of these groups contains users who have had a test with a positive result in the last 90 days. Since that is personal health information, we didn't want the "isMemberOf" value containing that group to be visible, except to a particular set of users. You may find it's safer in this case to sync any PHI to either an isolated or seperate directory, or to use a seperate attribute indicating the test positivity that can have strict access controls placed upon it. > > However, since sending my original email, we found a workaround -- fortunately, the end group in this "chain" is the only one we really need to sync to 389 DS, so we were able to omit the other groups (including the PHI one) from the sync process. I'm glad you found a solution still, Hope I was able to help, > > Thanks again, > ---Gary > > -- > Gary Windham > Principal Enterprise Systems Architect > University Information Technology Services > The University of Arizona > > Email: windhamg(a)arizona.edu > Office: +1 520 626 5981 > > > On Sun, Jan 17, 2021 at 5:11 PM William Brown <wbrown(a)suse.de> wrote: > External Email > > > > On 16 Jan 2021, at 05:17, Gary Windham <windhamg(a)email.arizona.edu> wrote: > > > > Hi all, > > > > We're running 389-Directory/1.3.9.0 B2018.304.1940. > > > > Is it possible via ACIs to restrict read/search permission on attributes with a particular value? > > > > My use case is that we have an "isMemberOf" attribute in our directory, and we have some group memberships that are of a sensitive nature. I would like to have all "isMemberOf" attribute values *except* for these sensitive ones readable/searchable to all authenticated user DNs, and the "sensitive" ones only readable/searchable by a particular user DN. > > > > Any ideas? From reading the Red Hat directory server ACI documentation, I can't find a way to do this. > > No, I don't think it's possible. Access controls are based on "which attributes you can/can't see", rather than "you can see these attributes except these values within them". > > I think that in this case, the possible solutions would be to have a isMemberOfSensitive seperate to the isMemberOf, but that may break many other integrations. > > An important question of course, is why are some group memberships sensitive? What is it you are trying to achieve? > > > > > Thanks in advance, > > --Gary > > -- > > Gary Windham > > Principal Enterprise Systems Architect > > University Information Technology Services > > The University of Arizona > > > > Email: windhamg(a)arizona.edu > > Office: +1 520 626 5981 > > > > _______________________________________________ > > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs, Australia > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia

1 0

ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=cesnet,dc=cz) is already in the ,entryrdn file with different ID 10458. Expected ID is 10459.
by Jan Tomasek 18 Jan '21

18 Jan '21

Hello, I've 389DS 1.4.0.21-1 on Debian/Buster in configuration with one master two consumers and several suffixes. After running dsconf -D "cn=Directory Manager" -w "$pswd" ldap://localhost backend index reindex cesnet_cz and completing indexing, err logfile on supplier server start show: ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=cesnet,dc=cz) is already in the ,entryrdn file with different ID 10458. Expected ID is 10459. Complete log of that indexing: [13/Jan/2021:16:43:10.896747048 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: aci [13/Jan/2021:16:43:10.900306795 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: cesnetemplid [13/Jan/2021:16:43:10.901040884 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: cn [13/Jan/2021:16:43:10.902098982 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: dc [13/Jan/2021:16:43:10.902728398 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: displayname [13/Jan/2021:16:43:10.903230082 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: entityidofidp [13/Jan/2021:16:43:10.903811474 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing entryrdn [13/Jan/2021:16:43:10.906245372 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: entrystatus [13/Jan/2021:16:43:10.906993328 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: entryusn [13/Jan/2021:16:43:10.907625883 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: givenName [13/Jan/2021:16:43:10.909503905 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: iphostnumber [13/Jan/2021:16:43:10.910181673 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: mail [13/Jan/2021:16:43:10.911199555 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: mailAlternateAddress [13/Jan/2021:16:43:10.911712896 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: mailHost [13/Jan/2021:16:43:10.912187870 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: member [13/Jan/2021:16:43:10.912657039 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: memberOf [13/Jan/2021:16:43:10.913311121 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: nsCertSubjectDN [13/Jan/2021:16:43:10.913817035 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: nscpEntryDN [13/Jan/2021:16:43:10.915613931 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: nsds5ReplConflict [13/Jan/2021:16:43:10.916112906 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: nsTombstoneCSN [13/Jan/2021:16:43:10.916587945 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: nsuniqueid [13/Jan/2021:16:43:10.918419748 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: ntUniqueId [13/Jan/2021:16:43:10.918898277 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: ntUserDomainId [13/Jan/2021:16:43:10.919347819 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: numsubordinates [13/Jan/2021:16:43:10.919940562 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: objectclass [13/Jan/2021:16:43:10.921719909 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: owner [13/Jan/2021:16:43:10.922432531 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: parentid [13/Jan/2021:16:43:10.923072797 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: seeAlso [13/Jan/2021:16:43:10.923580070 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: sn [13/Jan/2021:16:43:10.924288238 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: sponsor [13/Jan/2021:16:43:10.924959286 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: taccmd [13/Jan/2021:16:43:10.925596618 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: tacnaspointer [13/Jan/2021:16:43:10.926234600 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: tacprofilepointer [13/Jan/2021:16:43:10.926857374 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: tacuserpointer [13/Jan/2021:16:43:10.927401468 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: targetuniqueid [13/Jan/2021:16:43:10.927833486 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: telephoneNumber [13/Jan/2021:16:43:10.928480717 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: uid [13/Jan/2021:16:43:10.929047096 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexing attribute: uniquemember [13/Jan/2021:16:43:11.845074815 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 1000 entries (9%). [13/Jan/2021:16:43:12.658177768 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 2000 entries (19%). [13/Jan/2021:16:43:13.208182425 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 3000 entries (28%). [13/Jan/2021:16:43:13.960876293 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 4000 entries (38%). [13/Jan/2021:16:43:14.630850682 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 5000 entries (47%). [13/Jan/2021:16:43:15.394532510 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 6000 entries (57%). [13/Jan/2021:16:43:16.170632542 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 7000 entries (66%). [13/Jan/2021:16:43:16.796304684 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 8000 entries (76%). [13/Jan/2021:16:43:17.506801263 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 9000 entries (86%). [13/Jan/2021:16:43:18.067960870 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Indexed 10000 entries (95%). [13/Jan/2021:16:43:18.243288780 +0100] - INFO - ldbm_back_ldbm2index - cesnet_cz: Finished indexing. [13/Jan/2021:16:43:19.246780004 +0100] - ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=cesnet,dc=cz) is already in the entryrdn file with different ID 10458. Expected ID is 10459. [13/Jan/2021:16:43:19.247170757 +0100] - ERR - index_addordel_entry - database index operation failed BAD 1023, err=9999 Unknown error 9999 [13/Jan/2021:16:43:19.247525937 +0100] - ERR - NSMMReplicationPlugin - _replica_configure_ruv - Failed to create replica ruv tombstone entry (dc=cesnet,dc=cz); LDAP error - 1 [13/Jan/2021:16:43:49.252019156 +0100] - ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=cesnet,dc=cz) is already in the entryrdn file with different ID 10458. Expected ID is 10459. [13/Jan/2021:16:43:49.252315849 +0100] - ERR - index_addordel_entry - database index operation failed BAD 1023, err=9999 Unknown error 9999 [13/Jan/2021:16:43:49.252556037 +0100] - ERR - NSMMReplicationPlugin - _replica_configure_ruv - Failed to create replica ruv tombstone entry (dc=cesnet,dc=cz); LDAP error - 1 I tried to do indexes one after one, everyting is working fine untill I try to rebuild index for entryrdn and nsuniqueid. The second one start causing error: [13/Jan/2021:15:25:12.460676505 +0100] - ERR - _entryrdn_insert_key - Same DN (dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=cesnet,dc=cz) is already in the entryrdn file with different ID 10454. Expected ID is 10456. [13/Jan/2021:15:25:12.460870191 +0100] - ERR - index_addordel_entry - database index operation failed BAD 1023, err=9999 Unknown error 9999 [13/Jan/2021:15:25:12.461119957 +0100] - ERR - NSMMReplicationPlugin - _replica_configure_ruv - Failed to create replica ruv tombstone entry (dc=cesnet,dc=cz); LDAP error - 1 Only solution I've discovered is to disable replication, reinitializing all suffixes. This is quite painful.:( How to avoid this error? And how to fix it when it happens? Thanks for any sugestions. -- ----------------------- Jan Tomasek aka Semik http://www.tomasek.cz/

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users January 2021