Wes Modes wrote:
I am using *SASL/GSSAPI* to authenticate to* Kerberos* from *OpenLDAP*. I haven't gotten that to work yet.
First things first:
Specifics of my configuration:
* OS: Red Hat Enterprise 4 v2.6.9
* OpenLDAP v2.2.13 * Local MIT Kerberos5 v1.3.4 * KDC: MIT Kerberos5 v? * Cyrus SASL v2.1.19
All of these versions are far outdated, and MIT Kerberos is known to be unsafe in a threaded environment (and yes, OpenLDAP slapd is threaded).
If your machine is running stably with Linux kernel 2.6.9 I guess you can stay with it. Personally I use 2.6.24 because it supports my dual-core and quad-core systems, and it has much more efficient network drivers, among other things.
OpenLDAP 2.4.8 was released today. Your 2.2.13 is ancient and no longer supported by the OpenLDAP Project.
You would get better reliability and performance using the Heimdal kerberos libraries instead of the MIT libraries. Since the KDC is outside your control, you can ignore whatever version they're using. Only the libraries are important to you.
Cyrus SASL 2.1.22 is the latest release, and even that's pretty old.
To separate and modularize some of these services, we have three servers: A file server running Samba; A directory server running OpenLDAP to provide personal and group identities; and an authentication server running Kerberos (administered by another group). Samba connects to OpenLDAP through smbldap-tools. And OpenLDAP connects to the Kerberos server via SASL/GSSAPI.
The OpenLDAP *server* never connects to any Kerberos server; that's not how Kerberos works. An OpenLDAP *client* may connect to a Kerberos KDC once to get a service ticket, but after it gets the ticket it never needs to talk to the KDC again (or at least, until the ticket expires).
When someone requests a Samba logon, Samba requests an LDAP bind, which in turn should use SASL to authenticate via Kerberos.
The connection between Samba and OpenLDAP is working swell. It is the Kerberos connection that has me flummoxed.
*Simply put, OpenLDAP with SASL2 and GSSAPI support will be running on one server, while the Kerberos KDC will be running on another server.* I haven't found any documents that address this not-so-wacky design.
Both LDAP and Kerberos are distributed systems, there's nothing unusual about this layout at all. They are meant to be used this way.
Almost all of the docs I found presume that I am setting up the KDC on the same server at OpenLDAP. In my case, the KDC is administered by another group who is willing to grant me access to Kerberos. However, none of the docs I've found offer help in setting up SASL/GSSAPI here and the Kerberos server elsewhere.
So when a document says, run /kadmin.local/, to generate a principle, that is not available to me. If I can ask specifically for what I want, I might be able to convince the kerberos administrators to do it for me, but I have to be pretty specific about what I want.
The docs I'm referring to are
Cyrus SASL for System Administrators http://www.sendmail.org/~ca/email/cyrus/sysadmin.html <http://www.sendmail.org/%7Eca/email/cyrus/sysadmin.html> OpenLDAP 2.2 Administrator's Guide - Using SASL http://www.openldap.org/doc/admin22/guide.html#Using%20SASLIn several documents, it was suggested that before you try connecting OpenLDAP to Kerberos that you test to make sure your Kerberos configuration is working. That makes a lot of sense to me. So I want to perform a series of checks, but I don't know what those tests might be. Here's what I would like to test:
* Can I connect to the Kerberos server directly? (kinit) * Is direct authentication to the Kerberos server working?
Those two are one and the same.
* Am I getting returned a proper ticket? (klist)
Right.
* Is the keytab file on my OpenLDAP server being recognized and accepted by the Kerberos server?
That's not a valid question, that's not how Kerberos works.
* Is my machine being authenticated as a principle? Does it need to be?
That's typically a valid question in a Samba/Win2K context. Not really here.
Every entity that participates in a Kerberos environment must have a corresponding Kerberos principal. Whoever administers your KDC must create these principals. When creating a server principal, you will generally store the principal name and secret key in a keytab file. So - when your Kerberos administrator creates an ldap/server.fqdn@REALM principal for you, they should give you the corresponding keytab file.
* How do I test SASL2 before getting OpenLDAP involved?
Use the sample client and sample server in the SASL distribution.
* After making changes to my OpenLDAP config, how do I test the Kerberos connection through OpenLDAP?
There is no Kerberos connection through OpenLDAP, that's not how Kerberos works.
Do you have any pointers here?
This project has been delayed weeks and weeks while I climb and climb up Samba, OpenLDAP, and Kerberos' very steep learning curve. So your prompt response will be hugely helpful.
Weeks and weeks is a typical learning time, these are pretty big subject areas.
Thanks in advance, Wes
--
Wes Modes Server Administrator & Programmer Analyst McHenry Library Computing & Network Services Information and Technology Services 459-5208