[Date Prev][Date Next]
Re: Help with SASL/GSSAPI to remote Kerberos server
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
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
OpenLDAP 2.2 Administrator's Guide - Using SASL
In 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)
* 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,
Server Administrator & Programmer Analyst
Computing & Network Services
Information and Technology Services
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/