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

["Howard Chu" <hyc@symas.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Kevin

> > 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;
> http://www.bayour.com/LDAPv3-HOWTO.html#4.4.2.Installing%20Cyr
> us%20SASL%7Coutline
> (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 
> reads:
> 
> "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?

Correct.

> 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 ...?

Correct again.

> 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.

That is impossible in Kerberos 4, since tickets have the requester's IP address embedded in them and so can only be used by the requesting machine. Kerberos V supports proxying, but that's still a side-issue. When you authenticate to an LDAP server, that is *all* that you accomplish. The LDAP server does not automatically provide you with credentials to be used somewhere else (like a Kerberos TGT).

> 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?

That would be the most obvious solution.

> 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 
> documentation.
> 
> 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_ 
> (from 
> http://www.bayour.com/LDAPv3-HOWTO.html#4.5.3.3.The%20OpenLDAP
> %20access%20file%7Coutline):

Turbo's document is, simply, wrong. The TGT you may have on your client has no effect on an LDAP Simple Bind, and vice versa. The {KERBEROS} userPassword scheme has no effect on SASL/GSSAPI. All of these things are totally independent. 

> > 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.

Yes. That's the way GSSAPI works.

> 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 
> clients.

No, the OpenLDAP Admin Guide is correct.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support