4:21 p.m.
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
Server Administrator & Programmer Analyst
McHenry Library
Computing & Network Services
Information and Technology Services
459-5208
9:11 p.m.
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%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?
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:32 p.m.
Howard Chu <hyc(a)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.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).
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 (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
11:24 p.m.
Russ Allbery wrote:
Howard Chu<hyc(a)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.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).
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:27 a.m.
--On Tuesday, February 19, 2008 10:32 PM -0800 Russ Allbery
<rra(a)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
9:30 a.m.
Quanah Gibson-Mount <quanah(a)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 (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
9:34 a.m.
Howard Chu <hyc(a)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(a)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(a)stanford.edu) <http://www.eyrie.org/~eagle/>
11:39 a.m.
Russ Allbery <rra(a)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(a)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.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
2:51 a.m.
Russ Allbery wrote:
Quanah Gibson-Mount<quanah(a)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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5:29 p.m.
Howard Chu <hyc(a)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.
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
12:26 p.m.
New subject: OpenLDAP to Kerberos, Take 2
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
4:32 a.m.
New subject: OpenLDAP to Kerberos, Take 2
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.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
5758
days inactive
5768
days old
openldap-technical@openldap.org
11 comments
5 participants
participants (5)
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Russ Allbery -
Wes Modes