Hi, I'm trying to setup multi-supplier replication with certificate-based authentication. The only documentation I have found on the subject is: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht... however it doesn't seems to be complete.
I have been doing my test with openSUSE 15.3 and RHEL/CentOS 8 with SELinux disabled.
Attached there are a couple of scripts (dmtest-init and dmtest-agmt) that will help you reproduce my setup so you can tell me what I'm missing or doing wrong.
For testing you need two (virtual) machines and their ip addresses. A minimum text/server installation will do.
Run on the first machine: ./dmtest-init <IP1> <IP2>
The script will configure /etc/hosts so that the machine with IP1 can be reached as host1.example.com and the other as host2.example.com. 389-ds will be installed if not present. A new ds instance will be created, started (password is: password) and configured. /etc/openldap/ldap.conf is configured appropriately. group1 and user1 are created.
Now run on the second machine the same command: ./dmtest-init <IP1> <IP2> the script will setup the second machine in the same way but with the following differences: The CA database is imported with rsync from host1. A new Server-Cert is created using the CA certificate from host1. group1 and user1 are not created. They should appear on host2 after host1 will replicate his database. A temporary replication manager account is created.
At this point the following commands should work on both machines:
ldapsearch -H ldaps://host1.example.com -D "cn=Directory Manager" -w password ldapsearch -H ldaps://host2.example.com -D "cn=Directory Manager" -w password
Binding with a user certificate should also work: openssl req -subj "/DC=com/DC=example/OU=people/UID=user1" -newkey rsa:2048 -nodes -keyout cert.key -new -out cert.csr certutil -C -d /etc/dirsrv/ssca -f /etc/dirsrv/ssca/pwdfile.txt -a -i cert.csr -o cert.crt -c Self-Signed-CA LDAPTLS_CERT=$PWD/cert.crt LDAPTLS_KEY=$PWD/cert.key ldapsearch -H ldaps://host1.example.com -D "uid=user1,ou=people,dc=example,dc=com"
The next step is the replication setup. Run on host1: ./dstest-agmt this script will: - create the group repl_server for nsds5ReplicaBindDNGroup - create accounts for both hosts - add the client certificates to the corresponding accounts - add both accounts to the group repl_server - create the replica entry - create the replication agreement (with bootstrapt parameters)
These are essentially the steps described in the RedHat Directory Server 11 documentation: 15.6
Now a look at /var/log/dirsrv/slapd-ldaptest/errors shows that the replication bind with the bootstrap parameters works (group1 and user1 are now present on host2) but the replication bind with EXTERNAL auth fails.
- ERR - slapi_ldap_bind - Error: could not bind id [(anon)] authentication mechanism [EXTERNAL]: error 49 (Invalid credentials) - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials) () - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636): Replication bind with SIMPLE auth resumed
Clearly there is something wrong with the client certificate setup, but I could not figure out what. Any help is appreciated.
Giacomo Comes
Hello Giacomo,
Per the error log, it appears that the certificate is not mapping to the desired user entry. Make sure your certmap.conf file is properly configured per Section 9.9.1 found here: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...
Restart the directory after modifying the certmap.conf file.
Also, it is helpful to look at the access log and follow the conn=xxxx for the connection.
Here is a certificate-based authentication failure example (RHEL 7): # grep $(grep "SSL connection from" access|tail -1|cut -f3 -d' ') access [04/Mar/2022:09:00:02.932646113 -0500] conn=21 fd=4098 slot=4098 SSL connection from 192.168.150.189 to 192.168.150.187 [04/Mar/2022:09:00:02.986129181 -0500] conn=21 TLS1.2 256-bit AES; client CN=mfed-rh7ds1.martinfederal.local,DC=martinfed,DC=local; issuer CN=dev-IntermediateCA1.martinfederal.local,OU=pki-tomcat,O=MartinFederalLab [04/Mar/2022:09:00:02.986149974 -0500] conn=21 TLS1.2 failed to map client certificate to LDAP DN (Cert mapping function failed) [04/Mar/2022:09:00:02.986643636 -0500] conn=21 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [04/Mar/2022:09:00:02.986749253 -0500] conn=21 op=0 RESULT err=49 tag=97 nentries=0 wtime=0.053972758 optime=0.000109274 etime=0.054077979 - Client certificate mapping failed [04/Mar/2022:09:00:02.987740508 -0500] conn=21 op=1 UNBIND [04/Mar/2022:09:00:02.987760181 -0500] conn=21 op=1 fd=4098 closed - U1
Here is a successful certificate-based authentication connection (RHEL 7) with properly configured certmap.conf: # grep $(grep "SSL connection from" access|tail -1|cut -f3 -d' ') access [04/Mar/2022:09:13:14.980664619 -0500] conn=3 fd=4098 slot=4098 SSL connection from 192.168.150.189 to 192.168.150.187 [04/Mar/2022:09:13:15.021509726 -0500] conn=3 TLS1.2 256-bit AES; client CN=mfed-rh7ds1.martinfederal.local,DC=martinfed,DC=local; issuer CN=dev-IntermediateCA1.martinfederal.local,OU=pki-tomcat,O=MartinFederalLab [04/Mar/2022:09:13:15.022228628 -0500] conn=3 TLS1.2 client bound as cn=repman_mfed-rh7ds4-doe.martinfederal.local,cn=config [04/Mar/2022:09:13:15.022313670 -0500] conn=3 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [04/Mar/2022:09:13:15.022446873 -0500] conn=3 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.041625548 optime=0.000136346 etime=0.041760960 dn="cn=repman_mfed-rh7ds4-doe.martinfederal.local,cn=config"
Good luck.
David Ritenour Senior Directory Engineer 513 Madison Street SE Huntsville, AL 35801
-----Original Message----- From: Giacomo Comes comes@naic.edu Sent: Friday, March 4, 2022 12:47 AM To: 389-users@lists.fedoraproject.org Subject: [389-users] multi-supplier replication with certificate-based authentication
** WARNING: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi, I'm trying to setup multi-supplier replication with certificate-based authentication. The only documentation I have found on the subject is: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht... however it doesn't seems to be complete.
I have been doing my test with openSUSE 15.3 and RHEL/CentOS 8 with SELinux disabled.
Attached there are a couple of scripts (dmtest-init and dmtest-agmt) that will help you reproduce my setup so you can tell me what I'm missing or doing wrong.
For testing you need two (virtual) machines and their ip addresses. A minimum text/server installation will do.
Run on the first machine: ./dmtest-init <IP1> <IP2>
The script will configure /etc/hosts so that the machine with IP1 can be reached as host1.example.com and the other as host2.example.com. 389-ds will be installed if not present. A new ds instance will be created, started (password is: password) and configured. /etc/openldap/ldap.conf is configured appropriately. group1 and user1 are created.
Now run on the second machine the same command: ./dmtest-init <IP1> <IP2> the script will setup the second machine in the same way but with the following differences: The CA database is imported with rsync from host1. A new Server-Cert is created using the CA certificate from host1. group1 and user1 are not created. They should appear on host2 after host1 will replicate his database. A temporary replication manager account is created.
At this point the following commands should work on both machines:
ldapsearch -H ldaps://host1.example.com -D "cn=Directory Manager" -w password ldapsearch -H ldaps://host2.example.com -D "cn=Directory Manager" -w password
Binding with a user certificate should also work: openssl req -subj "/DC=com/DC=example/OU=people/UID=user1" -newkey rsa:2048 -nodes -keyout cert.key -new -out cert.csr certutil -C -d /etc/dirsrv/ssca -f /etc/dirsrv/ssca/pwdfile.txt -a -i cert.csr -o cert.crt -c Self-Signed-CA LDAPTLS_CERT=$PWD/cert.crt LDAPTLS_KEY=$PWD/cert.key ldapsearch -H ldaps://host1.example.com -D "uid=user1,ou=people,dc=example,dc=com"
The next step is the replication setup. Run on host1: ./dstest-agmt this script will: - create the group repl_server for nsds5ReplicaBindDNGroup - create accounts for both hosts - add the client certificates to the corresponding accounts - add both accounts to the group repl_server - create the replica entry - create the replication agreement (with bootstrapt parameters)
These are essentially the steps described in the RedHat Directory Server 11 documentation: 15.6
Now a look at /var/log/dirsrv/slapd-ldaptest/errors shows that the replication bind with the bootstrap parameters works (group1 and user1 are now present on host2) but the replication bind with EXTERNAL auth fails.
- ERR - slapi_ldap_bind - Error: could not bind id [(anon)] authentication mechanism [EXTERNAL]: error 49 (Invalid credentials) - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636) - Replication bind with EXTERNAL auth failed: LDAP error 49 (Invalid credentials) () - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=agreement" (host2:636): Replication bind with SIMPLE auth resumed
Clearly there is something wrong with the client certificate setup, but I could not figure out what. Any help is appreciated.
Giacomo Comes
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email and any such files in error and that any use, dissemination, forwarding, printing or copying of this email and/or any such files is strictly prohibited. If you have received this email in error please immediately notify hr@martinfed.com - (855) 212-1810 , and destroy the original message and any such files.
389-users@lists.fedoraproject.org
-
David Ritenour -
Giacomo Comes