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 [email protected] would have the associated DN: uid=kurt,cn=example.com,cn=gssapi,cn=auth and the principal ursula/[email protected] 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/[email protected],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/[email protected], 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 [email protected]: 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="[email protected]" authzid="[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,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56 When a client presents a ticket for [email protected]: do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="[email protected]" slap_sasl_getdn: conn 1000 [email protected] [len=26] => ldap_dn2bv(16) <= ldap_dn2bv([email protected],cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to [email protected],cn=EXAMPLE.COM,cn=GSSAPI,cn=auth >>> dnNormalize: <[email protected],cn=EXAMPLE.COM,cn=GSSAPI,cn=auth> => ldap_bv2dn([email protected],cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn([email protected],cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv([email protected],cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <[email protected],cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name [email protected],cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="[email protected],cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="[email protected]" authzid="[email protected]" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="[email protected],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)
