hyc@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.
Am Dienstag 08 Dezember 2009 13:50:21 schrieb Hallvard B Furuseth:
hyc@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.
--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
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
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
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 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
-Dieter
Dieter Kluenter wrote:
Howard Chuhyc@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 hyc@symas.com writes:
Dieter Kluenter wrote:
Howard Chuhyc@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 Kluenter -
Hallvard B Furuseth -
Howard Chu -
Quanah Gibson-Mount -
Ralf Haferkamp