[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;
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 ...?
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
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):
======================================================
"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
line:
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
that?
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)
> 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
clients.
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.
-Kevin