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 [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 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 [email protected], 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/[email protected] (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.
