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.