On 5 Mar 2022, at 00:34, David Ritenour
<d.ritenour(a)martinfed.com> wrote:
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...
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(a)naic.edu>
Sent: Friday, March 4, 2022 12:47 AM
To: 389-users(a)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...
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(a)martinfed.com- (855) 212-1810 , and destroy the original message and any such
files.
_______________________________________________
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://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia