Dieter Kluenter wrote:
Howard Chu<h...@symas.com> writes:
Quanah Gibson-Mount wrote:
--On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp
<rha...@suse.de> wrote:
Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
h...@openldap.org writes:
ITS#6419 also init for ldaps:// URIs
[...]
[zim...@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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
