Two binds exist: simple and sasl
simple: either tls, plain, or starttls. plain password on either encrypted or insecure tunnel.
sasl got many bind options. We don't wanna use "binddn and plain password": whats next? Maybe, cert.
You got right.
Consumer:
syncrepl rid=042
provider=ldap://hell.yahweh.net
sizelimit=unlimited
bindmethod=sasl
saslmech=external
starttls=yes
tls_cert=/etc/openldap/certs/replicator.pem
tls_key=/etc/openldap/certs/replicator-key.pem
tls_cacert=/etc/openldap/certs/yahwehCA.pem
tls_reqcert=demand
searchbase="o=yahweh"
scope=sub
Note two things: there is NO binddn; instead, you see tls_cert, replicator.pem. This cert replaces the binddn.
On provider:
-----------
authz-regexp cn=replicator
uid=replicator,cn=special,o=yahweh
TLSVerifyclient allow/try/demand
Note one thing here: syncrepl provider needs to find binddn, but using the cert. Since cert's DN can't be found in the ldap store, you need to map what exists in the cert to a user in the ldap store, a user that has read access to everything under the base "o=yahweh", including userPassword, etc. In this case, "uid=replicator,cn=special,o=yahweh" is given all read access.
By default tlsverifyclient is never. In this setup, provider is not gonna ask for the cert, making sasl external bind fail.
No comments:
Post a Comment