[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: commit: ldap/servers/slapd config.c syncrepl.c
Howard Chu <hyc@symas.com> writes:
> 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.
This is quite interesting, in the ldapi case, the connection initiates
a tls session first, reads the client certificate and applies tls_ssf=
256, after this the authz-regexp is parsed and the result applied, the
over all ssf=256 remains.
-Dieter
>>> slap_listener(ldapi:///)
daemon: listen=9, new connection on 16
daemon: added 16r (active) listener=(nil)
conn=0 fd=16 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
[...]
conn=0 op=0 EXT oid=1.3.6.1.4.1.1466.20037
do_extended: oid=1.3.6.1.4.1.1466.20037
conn=0 op=0 STARTTLS
[...]
TLS trace: SSL_accept:before/accept initialization
tls_read: want=11, got=11
[...]
TLS certificate verification: depth: 1, err: 0, subject: /C=DE/L=Hamburg/O=AVCI/CN=Certificate Authority/emailAddress=hdk@dkluenter.de, issuer: /C=DE/L=Hamburg/O=AVCI/CN=Certificate Authority/emailAddress=hdk@dkluenter.de
TLS certificate verification: depth: 0, err: 0, subject: /C=DE/O=AVCI/OU=Partner/CN=Dieter Kluenter, issuer: /C=DE/L=Hamburg/O=AVCI/CN=Certificate Authority/emailAddress=hdk@dkluenter.de
TLS trace: SSL_accept:SSLv3 read client certificate A
[...]
TLS trace: SSL_accept:SSLv3 flush data
=> ldap_dn2bv(16)
<= ldap_dn2bv(cn=dieter kluenter,ou=partner,o=avci,c=de)=0
conn=0 fd=16 TLS established tls_ssf=256 ssf=256
[...]
onn=0 op=1 BIND dn="" method=163
do_bind: dn () SASL mech EXTERNAL
==> sasl_bind: dn="" mech=EXTERNAL datalen=0
SASL Canonicalize [conn=0]: authcid="cn=dieter kluenter,ou=partner,o=avci,c=de"
slap_sasl_getdn: conn 0 id=cn=dieter kluenter,ou=partner,o=avci,c=de [len=41]
==>slap_sasl2dn: converting SASL name cn=dieter kluenter,ou=partner,o=avci,c=de to a DN
==> rewrite_context_apply [depth=1] string='cn=dieter kluenter,ou=partner,o=avci,c=de'
==> rewrite_rule_apply rule='uid=(.*),cn=.*,cn=auth' string='cn=dieter kluenter,ou=partner,o=avci,c=de' [1 pass(es)]
==> rewrite_rule_apply rule='gidNumber=(.*)\+uidNumber=(.*),cn=peercred,cn=external,cn=auth' string='cn=dieter kluenter,ou=partner,o=avci,c=de' [1 pass(es)]
==> rewrite_context_apply [depth=1] res={0,'cn=dieter kluenter,ou=partner,o=avci,c=de'}
[rw] authid: "cn=dieter kluenter,ou=partner,o=avci,c=de" -> "cn=dieter kluenter,ou=partner,o=avci,c=de"
slap_parseURI: parsing cn=dieter kluenter,ou=partner,o=avci,c=de
ldap_url_parse_ext(cn=dieter kluenter,ou=partner,o=avci,c=de)
>>> dnNormalize: <cn=dieter kluenter,ou=partner,o=avci,c=de>
=> ldap_bv2dn(cn=dieter kluenter,ou=partner,o=avci,c=de,0)
<= ldap_bv2dn(cn=dieter kluenter,ou=partner,o=avci,c=de)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=dieter kluenter,ou=partner,o=avci,c=de)=0
<<< dnNormalize: <cn=dieter kluenter,ou=partner,o=avci,c=de>
<==slap_sasl2dn: Converted SASL name to cn=dieter kluenter,ou=partner,o=avci,c=de
[...]
conn=0 op=1 BIND dn="cn=dieter kluenter,ou=partner,o=avci,c=de" mech=EXTERNAL sasl_ssf=0 ssf=256
do_bind: SASL/EXTERNAL bind: dn="cn=dieter kluenter,ou=partner,o=avci,c=de" sasl_ssf=0
[...]
conn=0 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.3
do_extended: oid=1.3.6.1.4.1.4203.1.11.3
conn=0 op=2 WHOAMI
[...]
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E