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:
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 22.214.171.124~git0.5ac5a8aad. The problem was the same with 126.96.36.199.
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
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/188.8.131.52 B2018.107.1745 on Ubuntu 18.04.5 LTS \n \l
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:
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
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:
> 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>
>>> 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
>>> > 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:
>> And here's how you can install it on CentOS 8:
>>> 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:
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
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>
> 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: