Dieter Kluenter wrote:
Howard Chuhyc@symas.com writes:
Quanah Gibson-Mount wrote:
--On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp rhafer@suse.de wrote:
Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
hyc@OpenLDAP.org writes:
ITS#6419 also init for ldaps:// URIs
[...]
[zimbra@freelancer ~]$ ldapsearch -x -ZZ -H ldapi:/// # extended LDIF
Of course it works. The more interesting question is what would ldapwhoami report, if you did a SASL/EXTERNAL Bind, and what ssf does slapd use as a result...
:~> ldapwhoami -Y external -ZZ -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de
:~> ldapwhoami -Y external -ZZ -H ldap://localhost SASL/EXTERNAL authentication started SASL username: cn=Dieter Kluenter,ou=Partner,o=AVCI,c=DE SASL SSF: 0 dn:cn=dieter kluenter,ou=partner,o=avci,c=de
Very good.
Seems like it's using your client cert DN directly, no authz-regexp involved.
Note that the SASL SSF will always be zero here since SASL/EXTERNAL means the SASL library doesn't provide any security layer. To really see something meaningful you'd have to look at the slapd debug output. In the ldapi case there should be a transport_ssf of 71, and tls_ssf of (128, 256, whatever the cipher provided) while in the ldap case there would only be the tls_ssf.
In the ldapi case the connection would originally have the gidNumber=xxx SASL authcid, and then when the TLS handshake was completed it would have the certificateDN instead.