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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux