> On 3 Oct 2019, at 07:27, Jonathan Aquilina <jaquilina(a)eagleeyet.net> wrote:
> Hi guys,
> How do I add users to 389?
It depends on your setup and needs.
If you have version 1.4.x (centos 8.x or recent fedora, opensuse 15.2/tumbleweed) you can use the dsidm command, which has features for simple user management.
If you don't have this, there are tools like ldapvi which is vim for ldap, apache directory studio, or simply ldapmodify with ldif.
I can give more advice on these if you need,
> 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://firstname.lastname@example.org...
Senior Software Engineer, 389 Directory Server
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 18.104.22.168~git0.5ac5a8aad. The problem was the same with 22.214.171.124.