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/18.104.22.168 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:
Having read all the manuals and snippets I can find, I have come up with the following certmap.conf file:
certmap default default
What I want the above to do is this:
- Look up the subject of the client certificate as the DN in the nsCertSubjectDN attribute.
- Also do an exact match of the certificate in the userCertificate attribute (verifycert on).
- Do the search across all contexts.
Does the certmap above do this?
What is not working for me is the lookup:
[18/Nov/2020:00:10:33.787682853 +0200] conn=1269 TLS1.3 128-bit AES-GCM; client serialNumber=365[snip]a14,CN=host.example.com; issuer CN=X,O=Y,C=UK
[18/Nov/2020:00:10:33.888476161 +0200] conn=1269 TLS1.3 failed to map client certificate to LDAP DN (No such object)
Looking at the source code, the above message is logged if we have a certificate, but we didn’t manage to map a DN:
Something missing from the documentation is the DN format expected by the nsCertSubjectDN attribute.
Is the format CN=X,serialNumber=Y as reported by openssl x509, or is it serialNumber=Y,CN=X as reported by the log message above?