4:50 a.m.
hyc(a)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
6:44 a.m.
New subject: commit: ldap/servers/slapd config.c syncrepl.c
Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
hyc(a)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
8:59 a.m.
New subject: commit: ldap/servers/slapd config.c syncrepl.c
--On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp
<rhafer(a)suse.de> wrote:
Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
> hyc(a)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.
[zimbra@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
5:08 p.m.
New subject: commit: ldap/servers/slapd config.c syncrepl.c
Quanah Gibson-Mount wrote:
--On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp
<rhafer(a)suse.de> wrote:
> Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
>> hyc(a)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.
[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...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:26 p.m.
New subject: commit: ldap/servers/slapd config.c syncrepl.c
Howard Chu <hyc(a)symas.com> writes:
Quanah Gibson-Mount wrote:
> --On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp
> <rhafer(a)suse.de> wrote:
>
>> Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
>>> hyc(a)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
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
10:51 p.m.
New subject: commit: ldap/servers/slapd config.c syncrepl.c
Dieter Kluenter wrote:
Howard Chu<hyc(a)symas.com> writes:
> Quanah Gibson-Mount wrote:
>> --On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp
>> <rhafer(a)suse.de> wrote:
>>
>>> Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
>>>> hyc(a)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/
1:01 a.m.
New subject: commit: ldap/servers/slapd config.c syncrepl.c
Howard Chu <hyc(a)symas.com> writes:
Dieter Kluenter wrote:
> Howard Chu<hyc(a)symas.com> writes:
>
>> Quanah Gibson-Mount wrote:
>>> --On Tuesday, December 08, 2009 3:44 PM +0100 Ralf Haferkamp
>>> <rhafer(a)suse.de> wrote:
>>>
>>>> Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
>>>>> hyc(a)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(a)dkluenter.de, issuer:
/C=DE/L=Hamburg/O=AVCI/CN=Certificate Authority/emailAddress=hdk(a)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(a)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
5035
days inactive
5036
days old
6 comments
5 participants
participants (5)
-
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu -
Quanah Gibson-Mount -
Ralf Haferkamp