I am using *SASL/GSSAPI* to authenticate to* Kerberos* from *OpenLDAP*. I haven't gotten that to work yet.
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.
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.
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%20SASL
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? * Am I getting returned a proper ticket? (klist) * Is the keytab file on my OpenLDAP server being recognized and accepted by the Kerberos server? * Is my machine being authenticated as a principle? Does it need to be? * How do I test SASL2 before getting OpenLDAP involved? * After making changes to my OpenLDAP config, how do I test the Kerberos connection through OpenLDAP?
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.
Thanks in advance, Wes
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
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
Howard Chu hyc@symas.com writes:
Wes Modes wrote:
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.19All of these versions are far outdated, and MIT Kerberos is known to be unsafe in a threaded environment (and yes, OpenLDAP slapd is threaded).
That is definitely true of that version of MIT Kerberos, which if I recall correctly made no attempt at thread safety whatsoever.
The MIT Kerberos team believes that they've fixed all the thread safety correctness bugs, within the thread safety guarantees that the library attempts to provide [1], in the current release (1.6.3) and would welcome bug reports for any remaining problems. I believe that OpenLDAP does meet the prerequisites for using MIT Kerberos safely.
You may still want to use Heimdal for *performance*, however, or disable the replay cache on MIT Kerberos (Heimdal doesn't, or at least didn't, implement one). The replay cache is known to have extremely poor performance in threaded environments and with lots of authentications.
(I'm not an MIT Kerberos developer apart from occasional minor fixes and Debian packaging, but I follow their development closely and Stanford is a Kerberos Consortium member.)
[1] MIT Kerberos only supports thread safety provided that no single krb5_context is used from multiple threads. Each thread needs to have its own krb5_context. In a GSSAPI context, this means that you must ensure that only one thread uses each GSSAPI security context.
Russ Allbery wrote:
Howard Chuhyc@symas.com writes:
Wes Modes wrote:
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.19All of these versions are far outdated, and MIT Kerberos is known to be unsafe in a threaded environment (and yes, OpenLDAP slapd is threaded).
That is definitely true of that version of MIT Kerberos, which if I recall correctly made no attempt at thread safety whatsoever.
The MIT Kerberos team believes that they've fixed all the thread safety correctness bugs, within the thread safety guarantees that the library attempts to provide [1], in the current release (1.6.3) and would welcome bug reports for any remaining problems. I believe that OpenLDAP does meet the prerequisites for using MIT Kerberos safely.
Hmm....
[1] MIT Kerberos only supports thread safety provided that no single krb5_context is used from multiple threads. Each thread needs to have its own krb5_context. In a GSSAPI context, this means that you must ensure that only one thread uses each GSSAPI security context.
Is this condition strictly on the authentication process, or also on the encryption library in general?
There are no such guarantees inside slapd. There is one context per connection, but multiple operations may be active on a single connection at the same time, and each operation executes in a separate thread. But since there can only be one authentication outstanding per connection, it may be OK.
Otherwise, while only one thread at a time can read a connection, and only one thread at a time can write on a connection, both reads and writes can occur simultaneously. This is a very common case for a client that issues a batch of asynchronous operations and streams the replies. From your description above, this case will still break with MIT Kerberos. I gave up on the MIT code back in 1.3.x, so I haven't tested this lately. Someone who cares about MIT's code probably should take a look at it though.
Howard Chu hyc@symas.com writes:
Russ Allbery wrote:
[1] MIT Kerberos only supports thread safety provided that no single krb5_context is used from multiple threads. Each thread needs to have its own krb5_context. In a GSSAPI context, this means that you must ensure that only one thread uses each GSSAPI security context.
Is this condition strictly on the authentication process, or also on the encryption library in general?
That's a really good question and I don't know the answer to that. I can imagine reasons why it would be both ways. This might be a good question to ask on kerberos@mit.edu, and I may go do that for my own curiosity.
Currently, the threading guarantees are not well-documented at all, which unfortunately joins the larger problem that the MIT Kerberos libraries are not well-documented. I know that's actively being worked on.
Otherwise, while only one thread at a time can read a connection, and only one thread at a time can write on a connection, both reads and writes can occur simultaneously. This is a very common case for a client that issues a batch of asynchronous operations and streams the replies. From your description above, this case will still break with MIT Kerberos. I gave up on the MIT code back in 1.3.x, so I haven't tested this lately. Someone who cares about MIT's code probably should take a look at it though.
1.4, for whatever it's worth, was the point at which the libraries were completely redone for thread safety. Various bugs in that support were fixed in 1.5.
Russ Allbery rra@stanford.edu writes:
That's a really good question and I don't know the answer to that. I can imagine reasons why it would be both ways. This might be a good question to ask on kerberos@mit.edu, and I may go do that for my own curiosity.
Ken Raeburn says:
| We currently assume that a security context is used in only one thread | at a time, so you could switch between threads, just not use it | simultaneously in multiple threads. But the person looking into it | earlier concluded that there may not be anything besides the sequence | number that's actually subject to race conditions there (and that | window's probably small enough that it might "work fine in practice" | much of the time, but no promises), so we could look into extending the | concurrency for this case, and just do some internal locking around the | sequence number accesses.
So indeed, don't use MIT Kerberos with OpenLDAP for right now until that additional locking is in place. Once it is, it should be safe.
--On Tuesday, February 19, 2008 10:32 PM -0800 Russ Allbery rra@stanford.edu wrote:
You may still want to use Heimdal for *performance*, however, or disable the replay cache on MIT Kerberos (Heimdal doesn't, or at least didn't, implement one). The replay cache is known to have extremely poor performance in threaded environments and with lots of authentications.
The other major difference between MIT and Heimdal is the behavior when a ticket expires. With MIT, any existing connections will stop working. With Heimdal, existing connections will continue to work, just new connections will fail until the ticket is renewed. I strongly prefer the Heimdal behavior if using something like SASL/GSSAPI for doing replication with persistent connections.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com writes:
The other major difference between MIT and Heimdal is the behavior when a ticket expires. With MIT, any existing connections will stop working. With Heimdal, existing connections will continue to work, just new connections will fail until the ticket is renewed. I strongly prefer the Heimdal behavior if using something like SASL/GSSAPI for doing replication with persistent connections.
True. The problem is that the Heimdal behavior is arguably wrong from a security standpoint. Once the ticket has expired, all products of that ticket should be treated as expired; otherwise, someone who's Kerberos principal has been revoked can continue to access services past the expiration of their ticket, which violates the Kerberos security model.
The right thing to do would be to rekey the persistant connection with a new ticket, but I don't know if the underlying protocols support that.
Russ Allbery wrote:
Quanah Gibson-Mountquanah@zimbra.com writes:
The other major difference between MIT and Heimdal is the behavior when a ticket expires. With MIT, any existing connections will stop working. With Heimdal, existing connections will continue to work, just new connections will fail until the ticket is renewed. I strongly prefer the Heimdal behavior if using something like SASL/GSSAPI for doing replication with persistent connections.
True. The problem is that the Heimdal behavior is arguably wrong from a security standpoint. Once the ticket has expired, all products of that ticket should be treated as expired; otherwise, someone who's Kerberos principal has been revoked can continue to access services past the expiration of their ticket, which violates the Kerberos security model.
Perhaps, but it adheres to the Unix security model - that is, once you have access to a resource, you can use it until you're done with it. Likewise, slapd will not terminate connections for clients that are currently bound but whose credentials have subsequently been disabled, by whatever means. And, the per-connection group ACL caching means that whatever group privileges you had at the start of your session remain yours, even if someone removes you from various groups while your connection is active.
The right thing to do would be to rekey the persistant connection with a new ticket, but I don't know if the underlying protocols support that.
It's possible to establish a new SASL security context on an existing LDAP session, just by starting a new SASL Bind.
Howard Chu hyc@symas.com writes:
Russ Allbery wrote:
True. The problem is that the Heimdal behavior is arguably wrong from a security standpoint. Once the ticket has expired, all products of that ticket should be treated as expired; otherwise, someone who's Kerberos principal has been revoked can continue to access services past the expiration of their ticket, which violates the Kerberos security model.
Perhaps, but it adheres to the Unix security model - that is, once you have access to a resource, you can use it until you're done with it. Likewise, slapd will not terminate connections for clients that are currently bound but whose credentials have subsequently been disabled, by whatever means. And, the per-connection group ACL caching means that whatever group privileges you had at the start of your session remain yours, even if someone removes you from various groups while your connection is active.
Yeah, I understand this perspective.
I've talked to Sam Hartman about the difference between MIT Kerberos's and Heimdal's behavior in the past, and I'm fairly sure that MIT Kerberos will never support continuing to use a GSSAPI context from an expired ticket because he believes it's the wrong thing to do in the Kerberos security model (although someone should double-check my understanding of that position with him before taking this as gospel). Rekeying is what everyone agrees is the Right Thing To Do. (For example, the latest GSSAPI patches for ssh rekey the session when the ticket changes locally, and as a special bonus, reforwards your credentials if delegation is enabled.)
It's possible to establish a new SASL security context on an existing LDAP session, just by starting a new SASL Bind.
The hard part is that the SASL layer itself can't know that the protocol will support that, so I think you need some sort of expiration callback at the SASL library layer that LDAP can hook into and provide the necessary higher-level protocol glue.
The SASL library could only handle this internally if there was something it could do entirely at the GSSAPI layer to rekey the connection without bothering the application, and that doesn't really fit either the GSSAPI or SASL API model where the calling application has control over all network traffic.
It's hard to get the glue to work right without making the application aware of the status of the ticket cache, which ideally it shouldn't have to know about.
Earlier I asked a few questions about OpenLDAP authenticating via Kerberos. I'm going to back up a bit and ask a more general question to ensure I have an adequate understanding to go further into the details of a solution.
On a Kerberos list I was asking for a little bit of help, and the answer I got revealed that maybe I don't understand as much about OpenLDAP's interaction with Kerberos as I'd thought.
In general, I am trying to authenticate a login and password received via an OpenLDAP client (in this case SMB via the smbldap-tools) with the logins and passwords held in a Kerberos server elsewhere. Is this a legitimate use of these services? Am I thinking about this wrong? If so, what else do I need to know?
I thought it was possible that I could have an ldap-bind request referred via SASL/GSSAPI to do a Kerberos authentication.
But on the Kerberos list, here's the response I got.
A KDC does not speak GSSAPI nor SASL. A KDC issues tickets. You use SASL-GSSAPI-KRB5 when you want to establish an authenticated connection to an application service for which a service principal exists within the KDC database. The KDC is not an application service.
As Jeff pointed out, [you can't do that] with GSSAPI. What you might be looking for is slapd code to take a username and password and do in effect a kinit and a verify tgt, or have a sasl plugin do it for your. I don't know of one.
And on this OpenLDAP list I got:
There is an ugly hack: having a userPassword field with "{SASL}<Kerberos principal>" in LDAP you can employ saslauthd's Kerberos backend. We use it as a crutch for a web application which can only authenticate against an LDAP directory
Perhaps you can help me understand or reconcile these responses.
Thanks.
Wes
Wes Modes Server Administrator & Programmer Analyst McHenry Library Computing & Network Services Information and Technology Services 459-5208
Wes Modes wrote:
In general, I am trying to authenticate a login and password received via an OpenLDAP client (in this case SMB via the smbldap-tools)
Strictly speaking smbldap-tools is not an OpenLDAP client. It's a separate software not implemented by the OpenLDAP project.
See also these links found with Google: https://gna.org/projects/smbldap-tools/ http://www.iallanis.info/smbldap-tools/docs/smbldap-tools/
with the logins and passwords held in a Kerberos server elsewhere.
I don't know smbldap-tools. But I'm not sure if the user invoking the tools is really the user who accesses the OpenLDAP server. Could it be that the user accessing the OpenLDAP server is a pre-configured demon user account in the LDAP server which acts on behalf of the user?
I thought it was possible that I could have an ldap-bind request referred via SASL/GSSAPI to do a Kerberos authentication.
Depends on what the smbldap-tools are capable to do.
But on the Kerberos list, here's the response I got.
A KDC does not speak GSSAPI nor SASL. A KDC issues tickets. You use SASL-GSSAPI-KRB5 when you want to establish an authenticated connection to an application service for which a service principal exists within the KDC database. The KDC is not an application service. As Jeff pointed out, [you can't do that] with GSSAPI. What you might be looking for is slapd code to take a username and password and do in effect a kinit and a verify tgt, or have a sasl plugin do it for your. I don't know of one.
You have to check whether the smbldap-tools are capable of authenticating as the user who started the tools with SASL bind with GSSAPI mech using the TGT the user obtained from the KDC before (via kinit).
Glancing over the docs I doubt it works that way: http://www.iallanis.info/smbldap-tools/docs/smbldap-tools/#htoc12
But I don't know the software. Check yourself more thoroughly...
Ciao, Michael.
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Russ Allbery -
Wes Modes