Re: commit: ldap/servers/slapd config.c syncrepl.c
Howard Chu writes:
> Dieter Kluenter wrote:
>> Howard Chu writes:
>>
>>> Quanah Gibson-Mount wrote:
--On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp
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.
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=...@dkluenter.de,
issuer: /C=DE/L=Hamburg/O=AVCI/CN=Certificate
Authority/emailaddress=...@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=...@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:
=> 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:
<==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
Re: commit: ldap/servers/slapd config.c syncrepl.c
Dieter Kluenter wrote: Howard Chu writes: Quanah Gibson-Mount wrote: --On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp 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/
Re: commit: ldap/servers/slapd config.c syncrepl.c
Howard Chu writes: > Quanah Gibson-Mount wrote: >> --On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp >> 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 -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E
Re: commit: ldap/servers/slapd config.c syncrepl.c
Quanah Gibson-Mount wrote: --On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp wrote: Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth: h...@openldap.org writes: ITS#6419 also init for ldaps:// URIs Does it work for ldapi:// as well? (And should it?) I seem to remember StartTLS does work for ldapi, though I don't know what a sensible host name in the server cert would be in that case. If StartTLS works for ldapi:// (I never tried it). The ITS#6419 should work in the ldapi:// case as a "start_tls=critical|yes" would need to be present in the bindconf. That will trigger tls initialization as well. Have a look at the previous config.c commit (1.509) for details. [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... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: commit: ldap/servers/slapd config.c syncrepl.c
--On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp wrote: Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth: h...@openldap.org writes: > ITS#6419 also init for ldaps:// URIs Does it work for ldapi:// as well? (And should it?) I seem to remember StartTLS does work for ldapi, though I don't know what a sensible host name in the server cert would be in that case. If StartTLS works for ldapi:// (I never tried it). The ITS#6419 should work in the ldapi:// case as a "start_tls=critical|yes" would need to be present in the bindconf. That will trigger tls initialization as well. Have a look at the previous config.c commit (1.509) for details. [zim...@freelancer ~]$ ldapsearch -x -ZZ -H ldapi:/// # extended LDIF # # LDAPv3 # base <> (default) with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 3 result: 0 Success # numResponses: 1 --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: commit: ldap/servers/slapd config.c syncrepl.c
Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth: > h...@openldap.org writes: > > ITS#6419 also init for ldaps:// URIs > > Does it work for ldapi:// as well? (And should it?) I seem to > remember StartTLS does work for ldapi, though I don't know what > a sensible host name in the server cert would be in that case. If StartTLS works for ldapi:// (I never tried it). The ITS#6419 should work in the ldapi:// case as a "start_tls=critical|yes" would need to be present in the bindconf. That will trigger tls initialization as well. Have a look at the previous config.c commit (1.509) for details. -- Ralf
Re: commit: ldap/servers/slapd config.c syncrepl.c
h...@openldap.org writes: > ITS#6419 also init for ldaps:// URIs Does it work for ldapi:// as well? (And should it?) I seem to remember StartTLS does work for ldapi, though I don't know what a sensible host name in the server cert would be in that case. -- Hallvard
