[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/servers/slapd config.c syncrepl.c



Dieter Kluenter wrote:
Howard Chu<hyc@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.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/