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, 7 months
dsconf broken for ldaps instances in 1.4.3 but working in 1.4.2
by Ivanov Andrey (M.)
dsconf works fine for instances using ldaps in v1.4.2 (389-directory-server:stable) bit it seems to be broken (not recognizing TLS certificates) in v1.4.3 for the commands like
dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass some_command
In both cases i am using dsconf to manage the same external LDAP server (1.4.3.x), the OS on both is CentOS 8.2 with latest updates:
<With version 1.4.2>
[root@ldap-centos8 ~]# rpm -qa | grep 389
[root@ldap-centos8 ~]# dnf -y module enable 389-directory-server:stable
[root@ldap-centos8 ~]# dnf -y install 389-ds-base
[root@ldap-centos8 ~]# rpm -qa | grep 389
python3-lib389-1.4.2.16-1.module_el8+9435+e6daf39f.noarch
389-ds-base-libs-1.4.2.16-1.module_el8+9435+e6daf39f.x86_64
389-ds-base-1.4.2.16-1.module_el8+9435+e6daf39f.x86_64
[root@ldap-centos8 ~]# dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get
nsslapd-security: on
nsslapd-securelistenhost:
nsslapd-secureport: 636
...
<everything's fine>
<Now the version 1.4.3>
[root@ldap-centos8 ~]# dnf -y remove 389*
[root@ldap-centos8 ~]# dnf -y module disable 389-directory-server:stable
[root@ldap-centos8 ~]# dnf -y module enable 389-directory-server:testing
[root@ldap-centos8 ~]# dnf -y install 389-ds-base
[root@ldap-centos8 ~]# rpm -qa | grep 389
python3-lib389-1.4.3.13-1.module_el8+10475+b74bca99.noarch
389-ds-base-libs-1.4.3.13-1.module_el8+10475+b74bca99.x86_64
389-ds-base-1.4.3.13-1.module_el8+10475+b74bca99.x86_64
[root@ldap-centos8 ~]# dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get
Error: Can't contact LDAP server - error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)
<dsconf does not seem to recongize the server's certificate it recognized in 1.4.2 even if ldapsearch still works ok>
[root@ldap-centos8 ~]# ldapsearch -H ldaps://ldap-model.polytechnique.fr -b 'cn=config' -D "cn=Directory Manager" -W '(cn=config)' nsslapd-security
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: (cn=config)
# requesting: nsslapd-security
#
# config
dn: cn=config
nsslapd-security: on
...
<dsconf -v for both cases>
[root@ldap-centos8 ~]# dsconf -v ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get
DEBUG: The 389 Directory Server Configuration Tool
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: dsrc path: /root/.dsrc
DEBUG: dsrc container path: /data/config/container.inf
DEBUG: dsrc instances: []
DEBUG: dsrc no such section: slapd-ldaps://ldap-model.polytechnique.fr:636
DEBUG: Called with: Namespace(basedn=None, binddn='cn=Directory Manager', bindpw='mypass', func=<function _security_generic_get_parser.<locals>.<lambda> at 0x7fce5a5e7158>, instance='ldaps://ldap-model.polytechnique.fr:636', json=False, prompt=False, pwdfile=None, starttls=False, verbose=True)
DEBUG: Instance details: {'uri': 'ldaps://ldap-model.polytechnique.fr:636', 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': 'ldaps://ldap-model.polytechnique.fr:636', 'root-dn': 'cn=Directory Manager'}}
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: open(): Connecting to uri ldaps://ldap-model.polytechnique.fr:636
DEBUG: open(): bound as cn=Directory Manager
DEBUG: cn=config getVal('nsslapd-security')
DEBUG: cn=config getVal('nsslapd-securelistenhost')
DEBUG: cn=config getVal('nsslapd-securePort')
DEBUG: cn=encryption,cn=config getVal('nsSSLClientAuth')
DEBUG: cn=encryption,cn=config getVal('nsTLSAllowClientRenegotiation')
DEBUG: cn=config getVal('nsslapd-require-secure-binds')
DEBUG: cn=config getVal('nsslapd-ssl-check-hostname')
DEBUG: cn=config getVal('nsslapd-validate-cert')
DEBUG: cn=encryption,cn=config getVal('nsSSLSessionTimeout')
DEBUG: cn=encryption,cn=config getVal('sslVersionMin')
DEBUG: cn=encryption,cn=config getVal('sslVersionMax')
DEBUG: cn=encryption,cn=config getVal('allowWeakCipher')
DEBUG: cn=encryption,cn=config getVal('allowWeakDHParam')
DEBUG: cn=encryption,cn=config getVal('nsSSL3Ciphers')
nsslapd-security: on
nsslapd-securelistenhost:
nsslapd-secureport: 636
[root@ldap-centos8 ~]# dsconf -v ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get
DEBUG: The 389 Directory Server Configuration Tool
DEBUG: Inspired by works of: ITS, The University of Adelaide
DEBUG: dsrc path: /root/.dsrc
DEBUG: dsrc container path: /data/config/container.inf
DEBUG: dsrc instances: []
DEBUG: dsrc no such section: slapd-ldaps://ldap-model.polytechnique.fr:636
DEBUG: Called with: Namespace(basedn=None, binddn='cn=Directory Manager', bindpw='mypass', func=<function _security_generic_get_parser.<locals>.<lambda> at 0x7f8b96a197b8>, instance='ldaps://ldap-model.polytechnique.fr:636', json=False, prompt=False, pwdfile=None, starttls=False, verbose=True)
DEBUG: Instance details: {'uri': 'ldaps://ldap-model.polytechnique.fr:636', 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': 'ldaps://ldap-model.polytechnique.fr:636', 'root-dn': 'cn=Directory manager'}}
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance
DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389
DEBUG: open(): Connecting to uri ldaps://ldap-model.polytechnique.fr:636
DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name}
DEBUG: Using certificate policy 1
DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 1
DEBUG: Cannot connect to 'ldaps://ldap-model.polytechnique.fr:636'
DEBUG: {'desc': "Can't contact LDAP server", 'info': 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)'}
Traceback (most recent call last):
File "/usr/sbin/dsconf", line 133, in <module>
inst = connect_instance(dsrc_inst=dsrc_inst, verbose=args.verbose, args=args)
File "/usr/lib/python3.6/site-packages/lib389/cli_base/__init__.py", line 152, in connect_instance
starttls=dsrc_inst['starttls'], connOnly=True)
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1076, in open
raise e
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1072, in open
self.simple_bind_s(ensure_str(self.binddn), self.bindpw, escapehatch='i am sure')
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 180, in inner
return f(*args, **kwargs)
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 443, in simple_bind_s
msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 180, in inner
return f(*args, **kwargs)
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 437, in simple_bind
return self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 180, in inner
return f(*args, **kwargs)
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 329, in _ldap_call
reraise(exc_type, exc_value, exc_traceback)
File "/usr/lib64/python3.6/site-packages/ldap/compat.py", line 44, in reraise
raise exc_value
File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 313, in _ldap_call
result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server", 'info': 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)'}
ERROR: Error: Can't contact LDAP server - error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)
2 years, 10 months
Object class violation. missing required attribute "objectclass"
by Mark Y. Goh
Hello,
I am running into a perplexing problme while trying to stand up two
replicas. From a fresh ubuntu 18.04 installation, installing, loading
custom schema, and configuring 389-ds and upon a replica initiation certain
entries are throwing this error -
Error adding object 'dn: uid=USER,ou=People,dc=cca,dc=edu'. The error sent
by the server was 'Object class violation. missing required attribute
"objectclass"
I have tried initializing with a ldif file as well but get the same error.
I have not edited the dse.ldif file from what ubuntu installed. I have
installed other replicas with no issues.
389-Directory/1.3.7.10 B2018.107.1745 on Ubuntu 18.04.5 LTS \n \l
thanks
mark
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
—
2 years, 10 months
Re: Fwd: How to manage 389DS on CentOS8 ?
by Viktor Ashirov
On Thu, Nov 19, 2020 at 3:11 PM Alix FALEME <alix.faleme(a)gmail.com> wrote:
> Thank you for your reply.
> I have installed it, but i would like to find a console to manage
> users/groups/etc
>
We don't have user management at the moment, but it is in our plans. This
is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1654238
In the meantime I recommend to use Apache Directory Studio:
https://directory.apache.org/studio/
HTH
>
> CentOS7 have 389console package for exemple.
>
>
>
> Le jeu. 19 nov. 2020 à 10:03, Viktor Ashirov <vashirov(a)redhat.com> a
> écrit :
>
>>
>>
>>
>> On Thu, Nov 19, 2020 at 2:10 PM Mark Reynolds <mreynolds(a)redhat.com>
>> wrote:
>>
>>> Forwarding to the correct list...
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: How to manage 389DS on CentOS8 ?
>>> Date: Thu, 19 Nov 2020 07:04:45 -0400
>>> From: Alix FALEME <alix.faleme(a)gmail.com> <alix.faleme(a)gmail.com>
>>> To: 389-users-owner(a)lists.fedoraproject.org
>>> <389-users-owner(a)lists.fedoraproject.org>
>>> <389-users-owner(a)lists.fedoraproject.org>
>>>
>>> > Hello guys, i’m here for an help.
>>>
>>> > How can i have a web console management for 389DirectoryServer on
>>> CentOS8. All i found are on CentOS7 with his 389-console. That package
>>> doesn’t exist on CentOS8.
>>> > Any help will be much appreciate
>>>
>>>
>>>
>>> Correct, the old java console was deprecated in RHEL/Centos 7, in 8 we
>>> now have a Cockpit plugin for the UI (cockpit-389-ds).
>>>
>>> See the RHDS 11 docs for more info:
>>>
>>>
>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
>>>
>> And here's how you can install it on CentOS 8:
>> https://www.port389.org/docs/389ds/download.html#centos-81-ds-14x
>>
>>
>>>
>>> HTH,
>>> Mark
>>>
>>>
>>>
>>> _______________________________________________
>>> 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...
>>
>>
>>>
>>
>> --
>> Viktor
>>
>
--
Viktor
2 years, 10 months
Fwd: How to manage 389DS on CentOS8 ?
by Mark Reynolds
Forwarding to the correct list...
-------- Forwarded Message --------
Subject: How to manage 389DS on CentOS8 ?
Date: Thu, 19 Nov 2020 07:04:45 -0400
From: Alix FALEME <alix.faleme(a)gmail.com>
To: 389-users-owner(a)lists.fedoraproject.org
<389-users-owner(a)lists.fedoraproject.org>
> Hello guys, i’m here for an help.
> How can i have a web console management for 389DirectoryServer on
CentOS8. All i found are on CentOS7 with his 389-console. That package
doesn’t exist on CentOS8.
> Any help will be much appreciate
Correct, the old java console was deprecated in RHEL/Centos 7, in 8 we
now have a Cockpit plugin for the UI (cockpit-389-ds).
See the RHDS 11 docs for more info:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
HTH,
Mark
2 years, 10 months
