[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Kerberos/GSSAPI issues
- To: openldap-technical@openldap.org
- Subject: Re: Kerberos/GSSAPI issues
- From: Brian Candler <B.Candler@pobox.com>
- Date: Tue, 28 Dec 2010 10:02:38 +0000
- Content-disposition: inline
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=rQ+Sc1W7fsj3HTpqgEKzhL4eMiE=; b=fGkhAKY vZYKP+Bl+43BmJCpuCoC3uhCiJyl166oeq/S2FOmi1kZ1tq+SaGg6RYVrzWjrwND eDGKclluiKk5z/DniBf67LjM9Z5HgmtdblgYK3fsjzbyvhIUtFxlV7jpxsdTph6p jCkDbDiQ2fvcaBzUZbDE4UBXrIkn8Da0opHI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sasl; b=q4A/1TsN0SnfiQXAq94IRP9o3SZMcIEDj HT/3uYj0RDq3v9J3rALiZFzbnvU3G+kyoOXXXSgCtlBuwejO9MybxQ1h7RKxXB5e VWEJvY+fTBBuUSONAjI65cTyKzXV5sYVWpvWuoFbp5oSQ5ZTUoY28NliJUEFX3Bc IuZaAplXBc=
- In-reply-to: <20101228092656.GA4437@talktalkplc.com>
- References: <20101228092656.GA4437@talktalkplc.com>
- User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Dec 28, 2010 at 09:26:56AM +0000, Brian Candler wrote:
> (1) According to the documentation at
> http://www.openldap.org/doc/admin24/sasl.html#GSSAPI
> then the authentication DN should be
> uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth
>
> However, running slapd in debug mode I see the cn=<realm> is missing. Here
> I have a ticket for inst/admin@WS.NSRC.ORG and run slapd -d 255:
Even more strangely, if I set olcSaslRealm to some junk, e.g.
ldapmodify -Y EXTERNAL -H ldapi:/// <<EOS
dn: cn=config
replace: olcSaslRealm
olcSaslRealm: WS.NSRC.ORGZ
EOS
Then the junk is passed through into the authentication DN, even though
the Kerberos ticket is from a different realm (WS.NSRC.ORG)
do_bind: dn () SASL mech GSSAPI
==> sasl_bind: dn="" mech=<continuing> datalen=32
SASL Canonicalize [conn=1000]: authcid="inst/admin"
slap_sasl_getdn: conn 1000 id=inst/admin [len=10]
=> ldap_dn2bv(16)
<= ldap_dn2bv(uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth)=0
slap_sasl_getdn: u:id converted to uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth
>>> dnNormalize: <uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth>
=> ldap_bv2dn(uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth,0)
<= ldap_bv2dn(uid=inst/admin,cn=WS.NSRC.ORGZ,cn=GSSAPI,cn=auth)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth)=0
<<< dnNormalize: <uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth>
==>slap_sasl2dn: converting SASL name uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth to a DN
<==slap_sasl2dn: Converted SASL name to <nothing>
SASL Canonicalize [conn=1000]: slapAuthcDN="uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth"
SASL proxy authorize [conn=1000]: authcid="inst/admin@WS.NSRC.ORGZ" authzid="inst/admin@WS.NSRC.ORGZ"
SASL Authorize [conn=1000]: proxy authorization allowed authzDN=""
send_ldap_sasl: err=0 len=-1
do_bind: SASL/GSSAPI bind: dn="uid=inst/admin,cn=ws.nsrc.orgz,cn=gssapi,cn=auth" sasl_ssf=56
It's as if the realm from the client is being ignored completely, and
replaced by that from olcSaslRealm. Is that correct??
I notice some potential Kerberos fixes in ITS:
ITS#6091 \
ITS#6092 | merged in 2.4.17 according to http://www.openldap.org/software/release/changes.html
ITS#6093 /
ITS#6225 -- outstanding
but I don't see any specific reference to what I'm seeing.
Regards,
Brian.