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.