Ok... after a bit of a struggle, I have gotten OpenLDAP 2.4.6 going with MIT kerberos 1.6.3 with some small caveats...
1: (and you know this already), the documentation for the slapd.d format is.. uhm.. bad. For example the "slapd.ldif" in the source isn't even valid, the "module" section (commented out, but there) is missing the "cn:" specifier.
2: The documentation throughout for specifying entries like the RootDN tells you (via example) to double quote it.. this generates errors.
2: There is something awry with the kerberos 5/gssapi setup for using a krb5 credential as a RootDN; according to your documentation it should be of the form:
uid=user/instance,cn=realm.com,cn=gssapi,cn=auth
This isn't working for me. After enabling Auth logging I found that it authenticated me as:
uid=user/instance,cn=gssapi,cn=auth
(note the lack of realm...) "why?" have I botched something (which I may have), or is there an error with the documentation?
David E. Cross wrote:
Ok... after a bit of a struggle, I have gotten OpenLDAP 2.4.6 going with MIT kerberos 1.6.3 with some small caveats...
1: (and you know this already), the documentation for the slapd.d format is.. uhm.. bad. For example the "slapd.ldif" in the source isn't even valid, the "module" section (commented out, but there) is missing the "cn:" specifier.
Specific defects should be submitted to the ITS (and you should know this already).
2: The documentation throughout for specifying entries like the RootDN tells you (via example) to double quote it.. this generates errors.
2:
Usually one would expect "3:" to come after "2:" ...
There is something awry with the kerberos 5/gssapi setup for using a krb5 credential as a RootDN; according to your documentation it should be of the form:
uid=user/instance,cn=realm.com,cn=gssapi,cn=auth
This isn't working for me. After enabling Auth logging I found that it authenticated me as:
uid=user/instance,cn=gssapi,cn=auth
(note the lack of realm...) "why?" have I botched something (which I may have), or is there an error with the documentation?
You haven't read the documentation. Section 13.2.4: Note also that the realm part will be omitted if the default realm was used in the authentication.
The SASL library always omits the realm if it matches the default realm. This is also documented in the FAQ and the Cyrus SASL docs.
2:
Usually one would expect "3:" to come after "2:" ...
Heh, fair enough.
You haven't read the documentation. Section 13.2.4: Note also that the realm part will be omitted if the default realm was used in the authentication.
The SASL library always omits the realm if it matches the default realm. This is also documented in the FAQ and the Cyrus SASL docs.
Ok, fair enough and its what I was intuitively guessing, I just wanted to make sure that I wasn't opening myself up in the advent that I enabled cross-realm keys and the realm was ignored. This is amazingly unclear in section 13.2.1 where its discussed "your realm" 'EXAMPLE.COM' and setting the cn to be that explicitly. Especially given that the mapping section is referenced with the note that you don't have to do this.
I'll write a request off to the documentation people to fix these, or to at least make it more obvious.
openldap-software@openldap.org
-
David E. Cross -
Howard Chu