Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers
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
2 years, 10 months
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
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 years
Problem browsing LDAP with Outlook
by Chris Bryant
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 years, 3 months
MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser
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-grou...)
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.
3 years, 4 months
Change TLS protocol
by Alberto Viana
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 years, 6 months
replication problems
by Alberto Viana
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
3 years, 6 months
Re: anonymous queries on second suffix subtrees
by Mark Reynolds
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.fe...
> --
>
> 389 Directory Server Development Team
--
389 Directory Server Development Team
3 years, 7 months
DNA plugin not working
by CHAMBERLAIN James
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
3 years, 7 months
setup-ds-admin fails to install admin server
by Crocker, Deborah
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.fedoraproje...
3 years, 7 months
Notice of Legacy Tool removal for 389 Directory Server
by Mark Reynolds
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
3 years, 7 months
