389-users April 2020

389-users@lists.fedoraproject.org

16 participants
31 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

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

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 2

MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser 06 Aug '20

06 Aug '20

Hi, I'm new to 389-ds and last week downloaded and installed the software. I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query the server using TLS/SSL, and all appears working. I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client can see the unix users and groups using the "getent password" or "getent group" commands. Now, here's where I'm getting tripped up.......... I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations. I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-groups…) which is close enough to CentOS that the initial commands worked. I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system. I created a test group (that I didn't enable a posix GID) and tried to add a single user via: Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add. When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error: "Cannot save to directory server. netscape.ldap.LDAPException: error resiult(65): Object class violation" And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors: "Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed [17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)" So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before I even try to filter login access via groups on my client system. I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I should set the "value" to be. I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute on individual users, only groups. This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions. Any suggestions would be appreciated.

6 19

Change TLS protocol
by Alberto Viana 21 May '20

21 May '20

Hi Guys, My packages: 389-ds-base1.4.2.8-20200414gitfae920fc8.el8.x86_64 openssl-1.1.1c-2.el8.x86_64 I'm trying to set tls-protocol-min to TLS 1.0 but it's not working, I used dsconf and ldapmodify like this: dn: cn=encryption,cn=config changetype: modify replace: sslVersionMin sslVersionMin: TLS1.1 - replace: sslVersionMax sslVersionMax: TLS1.2 Also tried to set on variables like this: nsTLS11: on nsTLS10: on dsconf RNP security set --tls-protocol-min="TLS1.0" Set Allow Weak Ciphers to on, but seems to be related to ssl3 and not TLS. Change cipher suite to all All commands seems to works, also modify my dse.ldif but When I start my 389: [28/Apr/2020:23:10:58.855549735 -0300] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.1, max: TLS1.2 [28/Apr/2020:23:10:58.858132149 -0300] - INFO - Security Initialization - slapd_ssl_init2 - NSS adjusted SSL version range: min: TLS1.2, max: TLS1.2 This last try was setting to --tls-protocol-min="TLS1.1" Thanks Alberto Viana

3 3

replication problems
by Alberto Viana 12 May '20

12 May '20

Hey Guys, 389-Directory/1.4.2.8 389 (master) <=> 389 (master) In a master to master replication, start to see this error : [31/Mar/2020:17:30:52.610637150 +0000] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica dc=rnp,dc=local. Check if DB RUV needs to be updated Even after restart the service the problem persists, I have to disable and re-enable replication (and replication agr) on both sides, it works for some time, and the problem comes back. Any tips? Thanks Alberto Viana

4 24

Re: anonymous queries on second suffix subtrees
by Mark Reynolds 05 May '20

05 May '20

On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote: > > Hi, Mark. > > > I did not expect a reply so soon! > > > When I query as "Directory Manager", I get the expected result. > > > I used the setup-ds.pl script to create the o=ethz,c=ch root suffx. > You should be using dscreate to create your instance, not setup-ds.pl > > I used "dsconf backend create" to add the second suffix (o=psi,c=ch). > Did you add any entries to o=psi,c=ch ? > > The subtrees are not properly connected to their respective root suffixes. > > Could this problem be caused by missing entries in the two "root > suffix" databases? > > > [root@el-dap ~]# > [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x > -b 'o=psi,c=ch' '(ou=*)' > No such object (32) So you did not initialize this suffix. It is empty. When creating the backend you could have created the top database node entry by adding the "--create-suffix" option: # dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch --create-suffix Note - dscreate or dsconf do not add any aci's by default. You have to add the aci's after initializing the database with some data. > [root@el-dap ~]# > > > Anonymous queries on the two subtrees (ou=staff & ou=student) on root > suffix (o=ethz,c=ch) > > return the expected result. > So searches on "ou=staff,o=ethz,c=ch" work? But just searching on "o=ethz,c=ch" does not? I'm getting confused because you keep changing which suffixes work or don't work. First it was subtree's under o=psi,c=ch that didn't return any results, now it's different subtrees under o=ethz,c=ch So if you are having issues with anything under "o=ethz,c=ch" then can you please run this search, and also clarify which subtrees work and don't work for anonymous searches under this suffix "o=ethz,c=ch": # ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci Thanks, Mark > > However, anonymous queries on the o=ethz,c=ch root suffix also return > no records. > > > with best regards, > > David > > > e-mail: david.mclaughlin(a)id.ethz.ch <mailto:david.mclaughlin@id.ethz.ch> > > > ------------------------------------------------------------------------ > *From:* Mark Reynolds <mreynolds(a)redhat.com> > *Sent:* 30 April 2020 3:10 PM > *To:* General discussion list for the 389 Directory server project.; > Mc Laughlin David Bruce (ID BD) > *Subject:* Re: [389-users] anonymous queries on second suffix subtrees > > > On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote: >> Hello, 389ers. >> >> I am migrating a whitepages server from OpenLDAP to 389-DS. >> >> My instance has a root suffix with two subtrees (for staff and students). >> Anonymous queries of the two root suffix subtrees return the expected >> results. >> >> The instance also has a second suffix of "o=psi,c=ch" with three >> subtrees: >> ou=contacts,o=psi,c=ch >> ou=groups,o=psi,c=ch >> ou=users,o=psi,c=ch >> >> Anonymous queries of the three "o=psi,c=ch" subtrees return NO records. >> >> I have added ACIs for the three "o=psi,c=ch" subtrees and restarted >> the instance, but >> anonymous queries of any of the three "o=psi,c=ch" subtrees STILL >> return no records. >> >> Does anyone know how to allow anonymous queries? > > First you don't need to restart the server when you add or change > ACI's. If you run the search as "cn=directory manager" does it return > the results you expect? > > Can you share all the ACI's you added to o=psi,c=ch subtrees? Maybe > gather all of them by using this search: > > # ldapsearch -D "cn=directory manager" -W -b "o=psi,c=ch" aci=* aci > > Thanks, > Mark > > >> >> Thanks, >> David >> >> [root@el-dap ~]# >> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -D >> "cn=Directory Manager" -W -x -b "ou=users,o=psi,c=ch" -s sub >> '(aci=*)' aci >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base <ou=users,o=psi,c=ch> with scope subtree >> # filter: (aci=*) >> # requesting: aci >> # >> # users, psi, ch >> dn: ou=users,o=psi,c=ch >> aci: (target = "ldap:///ou=users,o=psi,c=ch")(version 3.0; acl >> "Anonymous read >> , search for users";allow (read, search) userdn = "ldap:///anyone";) >> # search result >> search: 2 >> result: 0 Success >> # numResponses: 2 >> # numEntries: 1 >> [root@el-dap ~]# >> >> >> [root@el-dap ~]# >> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL >> -x -b 'ou=users,o=psi,c=ch' '(cn=*kohler*)' >> [root@el-dap ~]# >> >> >> [root@el-dap ~]# >> [root@el-dap ~]# tail /var/log/dirsrv/slapd-el-dap/access >> [30/Apr/2020:10:23:02.362530519 +0200] conn=5 fd=64 slot=64 >> connection from 129.132.65.9 to 129.132.65.9 >> [30/Apr/2020:10:23:02.362748318 +0200] conn=5 op=0 BIND dn="" >> method=128 version=3 >> [30/Apr/2020:10:23:02.362795436 +0200] conn=5 op=0 RESULT err=0 >> tag=97 nentries=0 etime=0.0000179605 dn="" >> [30/Apr/2020:10:23:02.363025956 +0200] conn=5 op=1 SRCH >> base="ou=users,o=psi,c=ch" scope=2 filter="(cn=*kohler*)" attrs=ALL >> [30/Apr/2020:10:23:02.363471926 +0200] conn=5 op=1 RESULT err=0 >> tag=101 nentries=0 etime=0.0000606595 >> [30/Apr/2020:10:23:02.363649360 +0200] conn=5 op=2 UNBIND >> [30/Apr/2020:10:23:02.363680129 +0200] conn=5 op=2 fd=64 closed - U1 >> [root@el-dap ~]# >> >> ___________________________________________________ >> >> David McLaughlin >> >> ETH Zürich / Swiss Federal Institute of Technology >> >> Informatikdienste >> >> Basisdienste >> >> Mail, Archive & Directories group >> >> CH-8092 Zürich >> >> Tel.: +41 44 632 3531 >> >> e-mail: david.mclaughlin(a)id.ethz.ch <mailto:david.mclaughlin@id.ethz.ch> >> >> >> _______________________________________________ >> 389-users mailing list --389-users(a)lists.fedoraproject.org >> To unsubscribe send an email to389-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.fedo… > -- > > 389 Directory Server Development Team -- 389 Directory Server Development Team

3 4

DNA plugin not working
by CHAMBERLAIN James 05 May '20

05 May '20

Hi all, I’m trying to use the DNA plugin to add uidNumbers on posixAccounts. Everything worked fine in testing, but now that it’s in production I’m seeing the following error: ERR - dna-plugin -_dna_pre_op_add - Failed to allocate a new ID!! 2 I’ve followed the advice in the knowledge base (https://access.redhat.com/solutions/875133) about adding an equality index with an nsMatchingRule of integerOrderingMatch, but have not seen any difference in the server’s behavior. Any ideas what I should try next? Thanks, James This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com> For other languages, go to https://www.3ds.com/terms/email-disclaimer

5 19

setup-ds-admin fails to install admin server
by Crocker, Deborah 30 Apr '20

30 Apr '20

Why do I get this error on a setup-ds-admin.pl? This was a fresh install. ----------------------- The suffix 'o=NetscapeRoot' already exists. Config entry DN 'cn=o\3Dnetscaperoot,cn=mapping tree,cn=config'. Failed to create the configuration directory server ----------------------- The setup has Centos 7.8 Epel install 389-ds-base: 1.3.10.1 389-admin: 1.1.46 TIA Deborah Crocker, PhD Systems Engineer III Office of Information Technology The University of Alabama Box 870346 Tuscaloosa, AL 36587 Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu -----Original Message----- From: Mark Reynolds <mreynolds(a)redhat.com> Sent: Thursday, April 30, 2020 2:06 PM To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; CHAMBERLAIN James <James.CHAMBERLAIN(a)3ds.com> Subject: [EXTERNAL] [389-users] Re: [389-announce] Notice of Legacy Tool removal for 389 Directory Server On 4/30/20 2:34 PM, CHAMBERLAIN James wrote: > Hi Mark, > >> On Apr 29, 2020, at 5:10 PM, Mark Reynolds <mreynolds(a)redhat.com> wrote: >> >> On 4/29/20 5:07 PM, Mark Reynolds wrote: >>> We've been talking about this for quite some time... >>> >>> A majority of all the old legacy perl and shell scripts have now been ported to the new CLI tools. Starting sometime in Fedora 33 we will stop shipping the legacy tools sub-package as part of 389 Directory Server. >> To be more specific the 389-ds-base-1.4.4 version is where the removal of the legacy tools subpackage will occur. > Does this includes tools like db2ldif.pl? Correct, all of those scripts will be removed. So all the shell and perl scripts (except for logconv.pl) will no longer be available starting at some point in 1.4.4. The new CLI tools (dscreate, dsctl, and dsconf) can do everything all those other scripts could do plus more. If you need help porting something to the new CLI I'd be glad to help. Mark > Anything that matches anything that matches "rpm -ql 389-ds-base | grep pl$ | grep sbin”, plus any shell scripts? > > Thanks, > > James > > This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. > > If you are not one of the named recipients or have received this email > in error, > > (i) you should not read, disclose, or copy it, > > (ii) please notify sender of your receipt by reply email and delete > this email and all attachments, > > (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. > > > Please be informed that your personal data are processed according to > our data privacy policy as described on our website. Should you have > any questions related to personal data protection, please contact 3DS > Data Protection Officer at > 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com> > > > For other languages, go to https://www.3ds.com/terms/email-disclaimer > _______________________________________________ > 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.fedorapr > oject.org -- 389 Directory Server Development Team _______________________________________________ 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…

1 0

Notice of Legacy Tool removal for 389 Directory Server
by Mark Reynolds 30 Apr '20

30 Apr '20

We've been talking about this for quite some time... A majority of all the old legacy perl and shell scripts have now been ported to the new CLI tools. Starting sometime in Fedora 33 we will stop shipping the legacy tools sub-package as part of 389 Directory Server. If you have any tools or clients that use the old perl/shell scripts you will need to port them to the new python CLI toolset. Sorry for any inconvenience this may impose. Sincerely, 389 Directory Server Development Team

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users April 2020