[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Kerberos+LDAP - identity management problems
>> -----Original Message-----
>> From: owner-openldap-software@OpenLDAP.org
>> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Marius Olsthoorn
>
>> > --On Friday, November 28, 2003 4:25 PM +0100 Marius Olsthoorn
>> > <marius@kern.nl> wrote:
>
>> >> Most importently, applications cannot use the same
>> >> identity name for both authentication and querying
>> >> LDAP, since using LDAP for authentication is against
>> >> the spirit of Kerberos.
>
> You need to read up on SASL support in OpenLDAP 2.1. You can use Kerberos
> for authentication to LDAP through SASL, so your single Kerberos identity
> can be used everywhere.
>
As far as I know LDAP only maps dns to principles. If I bind to
LDAP it uses my binddn to come up with a Kerberos identity, which
is then used for authentication. So, afaik, its not possible to
use a Kerberos identity to bind with LDAP.
>> Sorry if I wasn't clear on this. I was aiming at applications
>> which have
>> to authenticate users and use user data. They have to use one
>> identity in
>> two 'namespaces'. The first being Kerberos, the second being
>> LDAP. Since
>> there is no explicit mapping between the two you might run
>> into problems.
>> However, I guess you could use an implicit mapping (a
>> convention). But then
>> you have to hardcode the convention in your applications,
>> which is usually
>> a bad idea.
>
> No. The slapd administrator needs to explicitly define a mapping in
> slapd.conf; no one else needs to worry about the mapping.
True, but when an application (not LDAP) wants to authenticate a
user, it uses Kerberos for this purpose. If it then wants to use
LDAP, it then binds to LDAP as the user's dn! In this setting there
are two identities; the Kerberos principle and the user's binddn.
Another setting would be to use a special dn the application can
use. However, this way it is not possible to use LDAP's acl
mechanism.
>
> There is another alternative for applications that can not be made
> SASL-compliant - Use a Kerberos KDC that uses LDAP for its data store.
> (E.g., Heimdal.) In Symas CDS we've got a design that keeps the Kerberos
> account info in the same entry as the user's regular LDAP info. The KDC
> stores the kerberos key in the userPassword attribute "userpassword:
> {KRB5KEY}xxxxxxxxxxxx" and so the same password can be used for Kerberos
> authentication and LDAP Simple Binds. It does violate the intent of
> Kerberos security, but as has been seen on this mailing list many times
> before, many people prefer convenience to security, and this approach makes
> account management much simpler. As long as the sysadmin is careful about
> database file permissions, TLS/SSL setup, and ACLs, it can be used without
> too much risk.
This is an interesting idea, but I'm one of those people which prefers
security to convenience ;)