Tuesday, March 8, 2022

[389-users] [SOLVED] multi-supplier replication with certificate-based authentication

Hi,
I finally managed to setup multi-supplier replication with certificate-based authentication.
I now understand why people says it is a complicated stuff and they wish luck
to the guy trying to do it.

It is actually not that much complicated, once you know what to do.
Follow my instructions and see for yourself.

Start with reading the documentation (Red Hat Directory Server 11)
especially:
9. Configuring Secure Connections
15. Managing Replication
and in particular:
9.9.1. Setting up Certificate-based Authentication
15.4. Multi-Supplier Replication
15.6. Configuring Replication Partners to use Certificate-based Authentication

In the following examples I'll assume the two hosts are called
host1.example.com and host2.example.com
you have setup on each host a directory server instance called "ldaptest" with
self-signed CA certificate.
The root suffix stored in the database is: dc=example,dc=com

You have to execute the steps described in 15.6:
- create two accounts for both servers
- add to the accounts the user certificate
- create the replication group
- add both server accounts to such group
- create the replica entry (dsconf ... replication enable ... --bind-group-dn=<replication group>)
- initialize the server using a temporary replication agreement on host1
and a temporary replication manager on host2 (to be more precise on host2 you have to enable
replication for the suffix and create the temporary replication manager account [15.4.1 step 3])
- after initialization remove the temporary replication agreement on host1
and the temporary replication manager on host2
- create a replication agreement on both servers that use certificate-based authentication.

You do everything as described, but when you create the replication agreement on host1
(as showed in 15.6 step 5/a), things do not work.
The error log shows:

ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials)

the cause is that host2 does not know from which account to retrieve the user certificate. To fix this problem
you have to set the parameter CmapLdapAttr in certmap.conf in the following way:
1) Set the parameter CmapLdapAttr to nsCertSubjectDN
nsCertSubjectDN is the attribute that will contain the subject DN required to locate the host account.
2) When you create the account for the server and add to such account the client certificate (15.6 step 2/a)
add also the attribute nsCertSubjectDN with the value I'm going to describe below.
Run the command:
certutil -L -d /etc/dirsrv/slapd-ldaptest -n "Server-Cert" | grep "Subject"
You will see the subject of the server certificate. Something similar to:
CN=host1.example.com,givenName=6562ddf6-4594-4ef7-8b5d-8ae9a32ffa29,O=testing,L=389ds,ST=Queensland,C=AU
for such subject the value to assign to the attribute nsCertSubjectDN is:
cn=host1.example.com,GIVENnAME=6562ddf6-4594-4ef7-8b5d-8ae9a32ffa29,o=testing,l=389ds,st=Queensland,c=AU
That is: you have to flip the case of the attribute type (cn,o,ou,st,c, etc.)
Why it is like that and more important why it is not documented I don't know.

Once nsCertSubjectDN is set correctly and you create the replication agreement on host1
(as described in 15.6 step 5/a) you will now get this error message in the log:

ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=agreement" (host2:636): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later.

This error is due to the fact that on host2 the replication is still enabled
for bind-dn="cn=replication manager,cn=config"
you have to disable such replica entry and create a new replica entry
with --bind-group-dn=<replication group> similar to the one you did on host1.

After you do that the replication should work.

Unless it doesn't.
If you have created a self signed CA certificate and you are
in a timezone with negative offset (GMT-<n>) like in America,
then a bug will not make the replication work.

Here is what happens. Assume you are in the timezone GMT-4.
It's 10:00 and a self signed CA certificate is created while
running the command dscreate.
Check the validity of the certificate with:
certutil -L -d /etc/dirsrv/ssca -n Self-Signed-CA | grep Not
the output is something like:
Not Before: Tue Mar 08 14:00:00 2022
Not After : Fri Mar 08 14:00:00 2024
As you can see the certificate uses UTC time:
14:00 UTC corresponds to 10:00 GMT-4
Now somewhere in the directory server code the time stored
in the CA certificate is assumed to be in local time,
therefore since it is 10:00 and the certificate is not
valid before 14:00, the replication does not work.
In the error log you will see the message:

ERR - NSMMReplicationPlugin - acquire_replica - agmt="cn=agreement" (host2:636): Unable to acquire replica: permission denied. The bind dn "uid=host1.example.com,ou=people,dc=example,dc=com" does not have permission to supply replication updates to the replica. Will retry later.

You can either wait few hours until the certificate becomes valid,
or you can change the system clock just before you are running dscreate:

date -s "$(date +%:::z) hours" #move the clock backwards
dscreate <arguments>
date -s "$(( $(date +%:::z) * -1)) hours" #restore the correct time

Continuing with the previous example, the CA certificate
will be now valid since 10:00 GMT leaving the replication
process unaffected by the bug.


To resume:
add the attribute nsCertSubjectDN with correct value to the host accounts,
update the replica entry on host2 after the temporary agreement has done its job,
consider changing the system clock when you use the command dscreate.


I wish to thank David and William for their help.
I have never used 389-ds before and what they said helped me
investigate the proper cause of my problems.


Cheers.

Giacomo Comes
System Administrator
Arecibo Observatory
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

No comments:

Post a Comment