[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Kerberos/GSSAPI issues



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.