[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Integration: MIT Kerberos V and OpenLDAP with SASL/GSSAPI
Hi Kevin,
Kevin <openldap@gnosys.biz> writes:
> 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;
> http://www.bayour.com/LDAPv3-HOWTO.html#4.4.2.Installing%20Cyrus%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?
>
> 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 ...?
Yes, but as you mentioned you are running SuSE-9.0, which I'm running
myself, with heimdal-0.6 and pam_krb5, you don't have dot run kinit
prior to an bind to yopur directory server.
> 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.
Well your cenceptual error is, that Turbo is referring to kerberos v4,
which OpenLDAP is not supporting anymore, and sasl mech gssapi is
requiring kerberos v5.
> 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?
Well, that is a PAM question, not an OpenLDAP question :-)
But I can assure you that pam can handle this, it is in the SuSE-9.0
Administrator handbook.
> 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):
As I stated already, your main source of information should be the
OpenLDAP homepage, or if you do speak german, you should know where to
look. :-)
the sasl GSSAPI mechanism is a STRONG BIND, not a simple bind.
[...]
> 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've highlighted the key sentence with //// marks. Is
> he wrong? Turbo, are you on this list?
As I mentioned, Turbo is referring to a SIMPLE BIND with Kerberos v4,
which is not supported in OpenLDAP-2.1.x anymore
And yes, Turbo is 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
> that?
No, TLS is a completely different issue (I'm NOT referring to SSL)
> For what it's worth, I've included the details of my
> setup:
>
> 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)
That is not much difference, although I'm running heimdal, I have been
using MIT Kerberos quite a while.
>> 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?
posted many times, but here it comes again
sasl-regexp
uid=(.*),cn=avci.de,cn=GSSAPI,cn=auth
ldap:///o=avci,c=de??sub?uid=$1
sasl-regexp
uid=(.*),cn=avci.de,cn=GSSAPI,cn=auth
uid=$1,o=avci,c=de
But check with sasl sample-server and sample-client your mechanisms
and sasl-realm (which is not identical to kerberos realm)
> 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).
Unfortunately here Carter is wrong, which he confessed on this list
already.
>>
>> 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.
Either by kinit, krb5_login or by pam_krb5. And after destroying your ticket
cache, you should not be able to grant any ticket anymore, so that is
quite normal.
> 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, Turbo is wrong!
> 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.
I'm not quite sure, but ASFAIK OpenASF only supports kerberos v4, but
somebody may correct me.
If so, you may configure your system with 'saslauthd -a kerberos4' and
the attribute 'userpassword: {SASL} <secret>'
But that is a FAQ.
-Dieter
--
Dieter Kluenter | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: dkluenter(at)dkluenter.de
http://www.avci.de