Hi, folks,
I have a slave running syncrepl (just fine) which is getting hit with update requests, which are, of course, failing. I'd like to have them succeed. I could not find anything in the docs that would allow the slave to issue a referral. That seems to be limited to slurpd, if I understand correctly.
So I tried to implement chained updates. I put the following into my slaves slapd.conf:
overlay chain chain-rebind-as-user FALSE
chain-uri "ldap://master.mydomain.com" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=mydomain,dc=com" credentials="secret" mode="self"
This does not seem to be sufficient, but I can't figure out from the slapo manpage what else is required.
I get error 0x35, that the slave refuses to perform the operation. (I tried whipping and otherwise punishing the slave, but it did not improve it's attitude. :)
There does not seem to be a good howto for this.
Can somebody send me a pointer or an answer?
Thanks, </edg> Ed Greenberg West Hollywood, CA
<quote who="Ed Greenberg">
Hi, folks,
I have a slave running syncrepl (just fine) which is getting hit with update requests, which are, of course, failing. I'd like to have them succeed. I could not find anything in the docs that would allow the slave to issue a referral. That seems to be limited to slurpd, if I understand correctly.
So I tried to implement chained updates. I put the following into my slaves slapd.conf:
overlay chain chain-rebind-as-user FALSE
chain-uri "ldap://master.mydomain.com" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=mydomain,dc=com" credentials="secret" mode="self"
This does not seem to be sufficient, but I can't figure out from the slapo manpage what else is required.
I get error 0x35, that the slave refuses to perform the operation. (I tried whipping and otherwise punishing the slave, but it did not improve it's attitude. :)
There does not seem to be a good howto for this.
Did you read http://www.openldap.org/doc/admin24/overlays.html#Chaining
Can somebody send me a pointer or an answer?
Thanks,
</edg> Ed Greenberg West Hollywood, CA
Ed Greenberg edg@greenberg.org wrote:
overlay chain chain-rebind-as-user FALSE
chain-uri "ldap://master.mydomain.com" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=Manager,dc=mydomain,dc=com" credentials="secret" mode="self"
I have this on the slave. The cn=foo is a bug workaround for getting it working with certificates
overlay chain chain-uri ldaps://ldapmaster.example.net chain-idassert-bind bindmethod=sasl saslmech=EXTERNAL binddn="cn=foo" mode=self chain-idassert-authzFrom "*" chain-return-error TRUE
On the master. The autz-regexp maps the CN from the certificate to a DN in the tree authz-policy to authz-regexp cn=ldapslave1.example.net cn=ldapslave1.example.net,o=example (...) access to attrs=authzTo by * read stop
And finally, in the LDAP tree: dn: cn=ldapslave1.example.net,o=example authzTo: *
It did work with 2.3 but seems broken in 2.4. The slave accepts the client's connexion, but when it attempts to do the modification:
modifying entry "uid=foo,o=example" ldap_modify: Authentication method not supported (7)
Any hint appreciated
Emmanuel Dreyfus manu@netbsd.org wrote:
modifying entry "uid=foo,o=example" ldap_modify: Authentication method not supported (7)
Any hint appreciated
Trying with debug output: The replica slapd sends its certificate to the master, which accepts it. But the master slapd just grants an anonymous bind for that. It suggets something gors wrong with authz-regexp clauses, but I fail to understand why they stopped working after 2.4 upgrade.
On the master (edited to retain only relevant parts) TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write certificate request A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS certificate verification: depth: 1, err: 0, subject: <CA cert> TLS certificate verification: depth: 0, err: 0, subject: <replica cert> TLS trace: SSL_accept:SSLv3 read client certificate A TLS trace: SSL_accept:SSLv3 read client key exchange A TLS trace: SSL_accept:SSLv3 read certificate verify A TLS trace: SSL_accept:SSLv3 read finished A TLS trace: SSL_accept:SSLv3 write change cipher spec A TLS trace: SSL_accept:SSLv3 write finished A TLS trace: SSL_accept:SSLv3 flush data conn=8 op=0 BIND dn="" method=128 conn=8 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind
So, what is the culprit? replica's settings? overlay chain chain-uri ldaps://ldapmaster.exemple.net:636 chain-idassert-bind bindmethod=sasl saslmech=EXTERNAL binddn="cn=foo" mode=self chain-idassert-authzFrom "*" chain-return-error TRUE
Or the master' settings? authz-policy to authz-regexp cn=ldapreplica1.example.net cn=ldapreplica1.example.net,o=example
Emmanuel Dreyfus manu@netbsd.org wrote:
I fail to understand why they stopped working after 2.4 upgrade.
I made some progress:
- The replica's chain overlay perform the bind to the master using its certificate, that works.
- The authz-regex on the master correctly maps the certificate CN to an LDAP DN.
- But the authzTo attribute for that DN seems ignored. I have this message: Jul 31 05:46:31 botin slapd[27603]: SASL Authorize [conn=5]: proxy authorization allowed authzDN=""
Any hint on how to debug that?
Emmanuel Dreyfus manu@netbsd.org wrote:
overlay chain chain-uri ldaps://ldapmaster.example.net chain-idassert-bind bindmethod=sasl saslmech=EXTERNAL binddn="cn=foo" mode=self chain-idassert-authzFrom "*" chain-return-error TRUE
It did work with 2.3 but seems broken in 2.4. The slave accepts the client's connexion, but when it attempts to do the modification:
modifying entry "uid=foo,o=example" ldap_modify: Authentication method not supported (7)
Any hint appreciated
Here is the answer: since 2.4, when slapd acts as a client, certificate information (key, cert and CA) must be explicitely provided: the server side settings from TLSCertificateFile, TLSCertificateKeyFile and TLSCACertificateFile are never used.
So here is the overlay chain configuration that works using x509 certificates for authentication to the LDAP master (binddn is still both mandatory and ignored)
overlay chain chain-uri ldaps://ldapmaster.example.net chain-idassert-bind bindmethod=sasl saslmech=EXTERNAL binddn="cn=dontcare" tls_cert=/etc/openssl/certs/ldapslave1.crt tls_key=/etc/openssl/private/ldapslave1.key tls_cacert=/etc/openssl/certs/ca.crt tls_reqcert=demand mode=self chain-idassert-authzFrom "*" chain-return-error TRUE
----- "Emmanuel Dreyfus" manu@netbsd.org wrote:
So here is the overlay chain configuration that works using x509 certificates for authentication to the LDAP master (binddn is still both mandatory and ignored)
overlay chain chain-uri ldaps://ldapmaster.example.net chain-idassert-bind bindmethod=sasl saslmech=EXTERNAL binddn="cn=dontcare" tls_cert=/etc/openssl/certs/ldapslave1.crt tls_key=/etc/openssl/private/ldapslave1.key tls_cacert=/etc/openssl/certs/ca.crt tls_reqcert=demand mode=self chain-idassert-authzFrom "*" chain-return-error TRUE
Did you chalk this up on the FAQ?
Thanks.
Gavin Henry ghenry@OpenLDAP.org wrote:
Did you chalk this up on the FAQ?
Not yet, but anyone is welcome for beating me at this race.
openldap-software@openldap.org
-
Ed Greenberg -
Gavin Henry -
manu＠netbsd.org