Re: Kerberos/GSSAPI issues

[Brian Candler <B.Candler@pobox.com>]

On Tue, Dec 28, 2010 at 02:28:40PM -0800, Howard Chu 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.
> 
> That's normal. The SASL library doesn't provide the realm name when
> it is equal to the default realm. This has been true of Cyrus SASL
> for probably the past dozen years. Read the Cyrus SASL
> documentation.

Perhaps the openldap documentation could put the cn=<realm> section in
square brackets to show it is not always present:

| For the purposes of authentication and authorization, slapd(8) associates an
| authentication request DN of the form:
| 
|         uid=<primary[/instance]>[,cn=<realm>],cn=gssapi,cn=auth

Furthermore, the example which follows this is apparently incorrect:

| Continuing our example, 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

That is, if what you're saying is true and kurt is in the default realm,
there would be no ",cn=example.com"

However I've done some testing, and the interaction between the krb5 default
realm, the olcSaslRealm and the actual realm of the request appears to be
rather bizarre.

The client has a ticket for inst@WS.NSRC.ORG, and here are the variations
I've tried on the server side.

Config 1
--------
oclSaslRealm: WS.NSRC.ORG
krb5.conf default realm: WS.NSRC.ORG
result: auth is successful, DN is uid=inst,cn=ws.nsrc.org,cn=gssapi,cn=auth

This is fine, but it disagrees with your comment that "The SASL library
doesn't provide the realm name when it is equal to the default realm"

Config 2
--------
olcSaslRealm: BAR.NSRC.ORG
krb5.conf default realm: WS.NSRC.ORG
result: auth is successful, DN is uid=inst,cn=bar.nsrc.org,cn=gssapi,cn=auth

Surely this is wrong? The ticket had realm ws.nsrc.org! bar.nsrc.org is
just a value copied from the olcSaslRealm.

Am I being blind, or should I raise this as a bug in ITS?

Config 3
--------
olcSaslRealm: WS.NSRC.ORG
krb5.conf default realm: FOO.NSRC.ORG
result: auth fails!

# ldapsearch
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
	additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Key table entry not found)

Now this seems odd; presumably slapd is only trying to use a keytab entry of
ldap/noc.ws.nsrc.org@FOO.NSRC.ORG (which doesn't exist)

My understanding is that modern kerberos apps should just try all keys in
the keytab until they find one which decrypts the ticket.
http://mailman.mit.edu/pipermail/kerberos/2010-December/016797.html

But in any case, shouldn't it use olcSaslRealm in preference to the krb5.conf
default realm? (I'd expect the default realm to be used if olcSaslRealm
were empty though)

I'm inclined to raise this in ITS too, or am I mistaken?

Config 4
--------
olcSaslRealm: unset
krb5.conf default realm: WS.NSRC.ORG
result: auth is successful, DN is uid=inst,cn=gssapi,cn=auth

So the realm is being omitted from the bind DN only when olcSaslRealm is not
present

Config 5
--------
olcSaslRealm: unset
krb5.conf default realm: FOO.NSRC.ORG
result: as per config 3 (auth fail, "Key table entry not found")

> >(2) I would like to be able to do ldapsearch without specifying -Y GSSAPI
> >explicitly. However if I omit it, the client picks DIGEST-MD5 instead
> >(which isn't much use, since I have no passwords in the database)
> 
> Configure a sasl/slapd.conf with the options you want.
> Read the Cyrus SASL documentation.

OK, I got this in the end, although more thanks to Google than to Cyrus
documentation. For benefit of the archives:

# cat /etc/ldap/sasl2/slapd.conf 
mech_list: gssapi external
# 

Regards,

Brian.