Full_Name: Brian Candler Version: 2.4.21 OS: Ubuntu 10.04.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.114.104.19)

DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two example authorization DNs built from SASL/GSSAPI:

"a user with the Kerberos principal kurt@EXAMPLE.COM would have the associated DN: uid=kurt,cn=example.com,cn=gssapi,cn=auth and the principal ursula/admin@FOREIGN.REALM would have the associated DN: uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth"

Experimentation shows that the actual behaviour is different.

(1) If the realm of the client is the same as the default_realm on the server, then the auth DN is uid=kurt,cn=<olcSaslRealm>,cn=gssapi,cn=auth

(2) If the realm of the client is different to the default_realm on the server, then the auth DN is uid=ursula/admin@foreign.realm,cn=<olcSaslRealm>,cn=gssapi,cn=auth

(If olcSaslRealm is unset in the config then cn=<olcSaslRealm> is omitted entirely)

Some real examples are shown below. I reproduced this in a cross-realm auth setup with two MIT Kerberos 1.8.1 KDCs. The realms are WS.NSRC.ORG and REALM3.WS.NSRC.ORG. The server is host noc.ws.nsrc.org and is in realm WS.NSRC.ORG. It has a keytab for ldap/noc.ws.nsrc.org@WS.NSRC.ORG, and has olcSaslRealm: EXAMPLE.COM (which is just a junk realm, but it makes it clear that this isn't used for authentication)

When a client presents a ticket for inst@WS.NSRC.ORG:

do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="inst" slap_sasl_getdn: conn 1000 id=inst [len=4] => ldap_dn2bv(16) <= ldap_dn2bv(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth

...

...

dnNormalize: <uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth>

=> ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=inst,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=inst,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=inst,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=inst,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="inst@EXAMPLE.COM" authzid="inst@EXAMPLE.COM" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=inst,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56

When a client presents a ticket for student@REALM3.WS.NSRC.ORG:

do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="student@REALM3.WS.NSRC.ORG" slap_sasl_getdn: conn 1000 id=student@REALM3.WS.NSRC.ORG [len=26] => ldap_dn2bv(16) <= ldap_dn2bv(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth

...

...

dnNormalize:

<uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth> => ldap_bv2dn(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=student@REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="student@REALM3.WS.NSRC.ORG" authzid="student@REALM3.WS.NSRC.ORG" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=student@realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56

You can see that the authcid from libsasl omits the realm when it's the same as the server's, and includes the realm when it's different. However openldap does not split out into "uid=ursula/admin,cn=foreign.realm" as the documentation says.

You could treat this either as a behaviour error or a documentation error - if the latter, the olcSaslRealm is pretty useless, because if set it appears in all auth DNs (for both local and foreign realms)