> On 30 Sep 2019, at 16:48, Eugen Lamers <eugen.lamers@xxxxxxxxxxxxxxxxx> wrote:
>
> Hello William,
>
>> 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.
>
> This obviously is my main problem: The client (supplier in this case) does not provide a certificate. wireshark confirms this. What I wonder is how to tell the supplier which certificate to use or where to find it.
Is your Server-Cert marked with trust flags u? see:
>
>> 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
^ here. Server-Cert needs u,, at least (I think the u,u,u may be incorrect actually).
>>
>> 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
>
> All these conditions are met already.
>
>> 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...
>>
>> 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.
>
> It shouldn't be a problem to create these entries in the db of the consumer, but since the consumer doesn't see a certificate coming from the supplier, there is nothing to be mapped or bound.
Yep. See above.
>
>> 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.
>
> I will take your advice into consideration, even if I'm somehow going to be successful with the challenge. Is there any way to avoid plaintext passwords for the replication manager entries in LDIF files or the setup.inf for the setup-ds(-admin).pl scripts, I mean other than entering the passwords within the 389-console?
Well, they all end up in dse.ldif anyway. Because of the replication manager's nature it well ... has to be reversible to the process. We need to get the plaintext password somehow to initiate the bind. Additionally, any DN listed in a replication agreement as a replication manager has ACI's not evaluated in many cases due to needing a high level of access to perform it's function.
Saying this you need to say what's your threat model - if someone has access to dse.ldif and the content within in they can easily change the ldapi-autobind flag, then change directory content anyway. They may also have access to pin.txt and the nss certdb so they have your private key you're using for auth for replication anyway .... so is cert really more secure than a pw in dse.ldif? The threat is "someone has access to the machine and /etc as root/dirsrv". Once someone has access to one master in a replication topoolgy, they also can add entries which would give you root access/persistence on other hosts, so attacking replication is a low value target. You'd just put another user into the administrators group in the directory so you can ssh to whatever you want.
If you are worried about MITM, TLS already protects you here as does the proper CA verification which replication will already be doing for you.
I think that will give you some more to thing about in you decision making and risk assessment process. Very happy to discuss what your risks and threats are so we can work out what's going to be practical.
>
> Thanx for you effort. Best,
> Eugen
> _______________________________________________
> 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
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
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
