(ITS#6757) SASL canonicalize doesn't work as documented

[b.candler@pobox.com]

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)