> On 27 Sep 2019, at 17:42, Eugen Lamers <eugen.lam...@br-automation.com> wrote:
>
> Hi William,
>
>> Can you send in your certmap.conf and any of the relevant parts of dse.ldif
>> so I can have
>> a look at what you configured?
>
> dn: cn=encryption,cn=config
> objectClass: top
> objectClass: nsEncryptionConfig
> cn: encryption
> nsSSLSessionTimeout: 0
> nsSSLClientAuth: allowed
> CACertExtractFile: /etc/dirsrv/slapd-hostname1_local/ca.pem
> numSubordinates: 1
>
> dn: cn=RSA,cn=encryption,cn=config
> objectClass: top
> objectClass: nsEncryptionModule
> cn: RSA
> nsSSLPersonalitySSL: hostname1.domain.com
> nsSSLActivation: on
> nsSSLToken: internal (software)
>
> dn: cn=replica,cn=dc\3Ddomain\2Cdc\3Dcom,cn=mapping tree,cn=config
> objectClass: top
> objectClass: nsds5replica
> objectClass: extensibleObject
> cn: replica
> nsDS5ReplicaRoot: dc=domain,dc=com
> nsDS5ReplicaId: 12
> nsDS5ReplicaType: 3
> nsDS5Flags: 1
> nsds5ReplicaPurgeDelay: 604800
> nsDS5ReplicaName: b38325b1-e0f011e9-9cdcc130-abdc2534
> numSubordinates: 1
>
> dn: cn=hostname1,cn=replica,cn=dc\3Ddomain\2Cdc\3Dcom,cn=mapping
> tree,cn=config
> objectClass: top
> objectClass: nsds5ReplicationAgreement
> nsDS5ReplicaHost: hostname2.domain.com
> nsDS5ReplicaPort: 389
> nsDS5ReplicaTransportInfo: TLS
> nsDS5ReplicaBindMethod: SSLCLIENTAUTH
> nsDS5ReplicaRoot: dc=domain,dc=com
> description: Agreement between hostname2 and hostname1
> cn: hostname1
>
> Don't know if this extract contains what you need to know...
>
>> Also 1.4.1 *should* have lib389, so I'm curious what distro and platform you
>> are
>> using? It should be present ....
>
> Problem is, we currently use a 389ds version that is higher than the one
> "included" in our distro, which is SLE 12 SP3. We need to clarify on our side
> if the mix of packages (389ds, console, etc.) is consistent...
That shouldn't be a problem I think ....
>
> Would you recommend, as I understood Mark Reynolds, to use a "replication
> manager" entry on both servers and put the very same certificate to it with a
> appropriate subjectDN like "cn=replication manager"? Currently I use, as
> stated in my other mail, a setup as recommended in the admin guide of redhat
> ds 10, which is a supplier DN with the "cn=<fq-serverhostname>" on the
> consumer, and to which the certificate of the supplier server is put. But the
> supplier does not send any certificate to the consumer in the TLS handshake.
> So I don't this the certmap is involved, since it is used on the receiver of
> the certificate to decide to which entry the certificate should be bound, but
> the problem occurs already on the sender side.
>
> Anyway, the certmap:
>
> certmap default default
> default:DNComps
> default:FilterComps cn
> default:verifycert off
>
> Adding "default:CmapLdapAttr nsCertSubjectDN" didn't change anything.
I think you need the replication manager entries. So to explain. When the TLS
connection is made by hostname1 to hostname2, on hostname2 the SASL mech of
EXTERNAL is provided, so the bind code looks at other possible authentication
factors. The client certificate provided is then inspected.
The hostname1 client certificate must be signed by a CA that is accepted and
trusted for client auth in the nssdb on hostname2. You can check this with
certutil
{root@ldapkdc 9:48} /data/config I0> certutil -L -d .
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Self-Signed-CA CT,,
Server-Cert u,u,u
Notice the "CT,,". That means it's trusted as a server and client CA. You can
see the trust flags from -A:
{root@ldapkdc 9:49} /data/config I0> certutil -A --help
...
-t trustargs Set the certificate trust attributes:
trustargs is of the form x,y,z where x is for SSL, y
is for S/MIME,
and z is for code signing. Use ,, for no explicit
trust.
p prohibited (explicitly distrusted)
P trusted peer
c valid CA
T trusted CA to issue client certs (implies c)
C trusted CA to issue server certs (implies c)
u user cert
w send warning
g make step-up cert
And then modify them with -M:
{root@ldapkdc 9:48} /data/config I0> certutil -M --help
-M Modify trust attributes of certificate
-n cert-name The nickname of the cert to modify
-t trustargs Set the certificate trust attributes (see -A above)
-d certdir Cert database directory (default is ~/.netscape)
-P dbprefix Cert & Key database prefix
So back to TLS processing - now the server has validated the client cert, we
head into the certmap code - we *only* have the certificate so we need to be
able to look up that certificate to a user somehow. Certmap.conf is processed
in a specific order (that I can't remember right now :) ). One of the simplest
methods is "DNComp", where the DN of the cert must match and be in order of the
DN in the directory.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/configuration_file_reference#certmap_conf
But if you set certmap to look like:
certmap default default
default:CmapLdapAttr nsCertSubjectDN
So this means: when an incomming SASL external is found, and you have TLS, take
the certificate subjectDN and do an ldapsearch for it in each available backend.
This has a specific implication though. You need an entry that looks like:
dn: cn=hostname1,cn=config
cn: hostname1
nsCertSubjectDN: <subject of hostname1 cert>
Each server will need these entries for all possible incoming servers.
You can also make these entries in your main database such as:
cn=hostname1,ou=replicationmanagers,dc=example,dc=com
cn: hostname1
nsCertSubjectDN: <subject of hostname1 cert>
The benefit of this is you have the replication managers in "one place" and
they are literally replicated, so you don't need so much per-server
configuration. The issue is a chicken-and-egg bootstrap where you can't start
replication until ... you start replication. So youcan bootstrap either with PW
auth on the repl manager, or you can do a db2ldif -r on the first master, and
import that on the second so the replication metadata is available.
I hope this helps: in general I think TLS auth on replication is really hard to
setup and do properly. I did it as part of lib389 to automate the tests and it
was a challenging process to setup, and that's coming from someone who is
literally a developer on the project. It's also super dense/hard to debug when
it goes wrong.
I prefer to either have the simple replication manager + pw setup, or have the
per-host replication manager in the maindb but with pw again.
Anyway, hope that helps give you advice on what you may be missing :)
>
> Regards,
> Eugen
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@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
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@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
