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/[email protected] 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/[email protected]" authzid="inst/[email protected]" 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.
