[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Integration: MIT Kerberos V and OpenLDAP with SASL/GSSAPI

Thanks for your reply Dieter.

On Saturday 06 March 2004 09:35, Dieter Kluenter wrote:
> Kevin <openldap@gnosys.biz> writes:
> > Hi All-
> >
> > I'm trying to integrate the subject software and
> > having difficulty with the part that seems most
> > mysterious to me: getting slapd to say, "Oh, a
> > user is trying to do initial kerberos
> > authentication through me...
> [...]
> > For any of you that might already be doing this,
> > how do you establish the connection between LDAP
> > and the authentication server?
> Your main source of information should be
> http://www.openldap.org/doc/admin21/ or
> http://www.openldap.org/doc/admin22/
> http://www.openldap.org/faq/data/cache/1.html

Well, I've read these.  I've also read the relevant 
portions of "LDAP System Administration" (ORA 2003) by 
Gerald Carter; the SuSE 9 Administration Guide (this 
is a SuSE 9 distro); RFC 2849; man 5 ldif;
(OpenLDAP, OpenSSL, SASL and KerberosV HOWTO); and 
maybe some others as well.

But since you've pointed me at them, I've gone back to 
them and I now see an important sentence that I'd like 
to try to get clarified here.

The sentence is from Section 10.2.2. (GSSAPI) of 
http://www.openldap.org/doc/admin21/guide.html and it 

"To use the GSSAPI mechanism to authenticate to the 
directory, the user obtains a Ticket Granting Ticket 
(TGT) prior to running the LDAP client."

Emphasis on the word, "prior" is of course mine.

So, does this imply that the OpenLDAP clients do not
have the ability to obtain the TGT themselves?

In other words, must I run "kinit username" from the 
command line (or obtain the TGT by some other means 
such as a kerby-enabled login or xdm program) before 
attempting to run ldapsearch -Y GSSAPI
-H ldap://my.host ...?

If that is the case, then I've been suffering from a 
major conceptual error in thinking that my whole 
authentication system could have a front-end of LDAP 
(front-end meaning that client programs such as login 
and xdm would go to the LDAP server _initially_ (thus 
"front-end") to request authentication), and that the 
LDAP server would see the client's attempted 
authentication and then, acting as a relay or proxy I 
guess, go to the Kerberos KDC for determining whether 
or not the credentials supplied were correct, then go 
back to the client with a "yes, you're allowed" or 
"no, get lost" message or something.

And if that is the case, then how do I get the other 
pieces of data that a user needs to log in to a system 
from an LDAP server (things that might otherwise be 
kept in /etc/passwd such as GECOS, home directory, 
login shell, etc.)?  Does the act of logging in to the 
system involve a direct check by the client program 
(login/xdm) of both the KDC for authentication and the 
LDAP server for these other pieces of data?  If so, 
then I guess the pam configuration needs to first have 
the check with the KDC and then, if successful, get 
the other needed data (home dir, login shell, etc.) 
from LDAP?

Please pardon me if I seem to be obtuse in these 
questions, but I'm just not sure of my understanding 
after many days of struggling with this and reading 

And if it _is_ the case that I've been suffering from 
this major conceptual error, then what's going on with 
Turbo's HOWTO where he says in the section entitled 
_Testing OpenLDAP, simple user bind, with SSL/TLS_ 

"Now, if all the changes to the database (see how to 
populate the database and/or modify the LDAP database) 
have been done and all the above tests work, let's try 
to search the database as yourself again, but this 
time doing it with a simple bind (-x to ldapsearch). 
To make absolutely sure that it doesn't try to use the 
Kerberos ticket you got with kinit above [previously], 
execute kdestroy.  Just to be on the safe side when 
testing here, mind you :). Here we go, all in one 

ldapsearch -x -D 'uid=turbo,ou=People,<MY BASEDN>' -W \
-b "" -s base -LLL -H \
ldaps://<FQDN OF LDAP SERVER>/ supportedSASLMechanisms

Enter the password when prompted. This command should 
return the same thing as the previous commands.
Remember, you should enter the password for your 
KerberosV principal.
If it didn't take the Kerberos password, you would get 
this back:

Enter LDAP Password: 
ldap_bind: Invalid credentials

I worked for quite some time (about 4-5 days) to get 
this part to work. I had no luck. Then, all of a 
sudden it worked, and I'm not quite sure why. I am 
however quite sure that it have something to do with 
the order the ACL's for userPassword is arranged. 
OpenLDAP v2.0 is a LOT more picky about the order of 
the ACL's than the 1.3 version(s) where (where my 
config/access file originates from). See my OpenLDAP 
access file of how it looks when it works."

I've highlighted the key sentence with //// marks.  Is 
he wrong?  Turbo, are you on this list?

Admittedly, I'm not doing the SSL/TLS part of this, but 
I'm thinking it shouldn't be necessary to get this to 
work as a test in a trusted network.  Am I wrong on 

For what it's worth, I've included the details of my 

OpenLDAP version: 2.1.22-73 (from SuSE rpm)
 (properly configured to do authentication of rootdn
  against KDC via SASL/GSSAPI)
Running MIT Kerberos 5, v1.3.1 (built from source)
Running OpenAFS 1.2.11 (built from source)
Running Cyrus SASL 2.1.15-65 and associated plugins
 (from SuSE rpm)

> why don't you just use a sasl mechanism like gssapi
> and write apropriate sasl-regexp  in your
> slapd.conf?

What does yours look like?

And could someone help me out a little with the concept 
of a SASL ID?  My ORA book mentions it, but doesn't 
really explain it.  The OpenLDAP Admin Guide mentions 
it, but doesn't really explain it (at least, it's not 
clear to me---perhaps I'm being thick-headed... 
wouldn't be the first time).

> ldapsearch -Y GSSAPI -H ldap://my.host ... works
> fine for me.

This works for me once I have obtained a TGT with 
kinit, but not after I kdestroy that ticket cache.

Are you saying that it works for you with an initially 
empty ticket cache and after execution, you have a 
TGT?  If so, then I guess Turbo's right and the 
OpenLDAP 2.1 Admin Guide is wrong about needing to 
first obtain the TGT before running the OpenLDAP 

Please, someone either confirm or dispell my suspected 
misconceptions here.  I feel like I've tried 
everything to no avail.

As I've said once before, my ultimate goal is to get 
OpenLDAP to be the integration glue between Kerberos 
and OpenAFS.  My alternative to that seems to be 
keeping a central /afs/.../common/etc/passwd and group 
file and merging it with local /etc/passwd and group 
files and pushing the resulting merged files out to 
every client machine on the network whenever the 
common files change.  This alternative seems very 
clunky to me, but that's what is recommended by the 
OpenAFS docs.

Thanks for reading.