MIT Kerberos LDAP backend

[Simon Wilkinson]

[ Replying to both of your emails at once ]

> Do you know of any other method whereby we would be able to  
> effectively
> let Kerberos delegate the authentication step to LDAP, and then  
> carry on
> as if that part had been done itself?

I think you're misunderstanding the way that Kerberos works. Kerberos  
is an authentication system, and a cryptographically based one at  
that. It requires having access to the users password in order to  
perform the encryption operations that it's security is based on. You  
can't defer these operations to another source to say "is this  
password correct". I suppose it would be technically feasible to have  
Kerberos use an external password store (it would require access to  
the plaintext of all of these passwords), and generate its keys on  
the fly, but as far as I'm aware no-one has done this work.

> Or is the only solution to duplicate all user data into Kerberos, and
> then frequently sync the two?

Kerberos doesn't hold user data in the same way that something like  
LDAP does. All Kerberos holds is the user's principal (usually  
derived from their username), a set of keys (derived from the  
password), and a set of flags controlling the way in which that  
principal may be used. The Kerberos database tends to get populated  
either with an account provisioning system, or creating entries based  
on an LDAP data store. Normally Kerberos would be the authoritative  
password source, with LDAP deferring authentication operations to  
Kerberos - however it is entirely possible that you could maintain  
passwords both in Kerberos and LDAP, and keep this in sync, either by  
running code on both your KDC and LDAP servers to intercept password  
change, or by forcing all password changes to go through a central form.

>
> So what we would have liked is for a web-based user to go to one of  
> our
> web applications that requires authentication and for them to
> authenticate in a way that ends up with them having a valid Kerberos
> ticket somehow for other Kerberos aware applications, so they don't  
> get
> asked for user/pass again in a session.

Kerberos and the web don't currently play that well together. Most  
organisation's web-SSO solutions that I'm aware of use technologies  
such as Cosign (from the University of Michigan) or WebAuth  
(Stanford) to translate the Kerberos authentication that's happening  
behind the scenes into cookie based authentication that works with  
all of today's web browsers. It's worth noting that there's no easy  
way for an authentication operation against a remote web site to  
result in Kerberos credentials being created on the local machine.

However, if you're purely interested in Web based applications, you  
_may_ be able to deploy a web SSO technology without needing to have  
it backed with Kerberos. Cosign, in particular, can support pretty  
much any password database in order to authenticate users. The  
complication arises, however, if your web applications have to  
perform operations on behalf of the user. In the situation where the  
user gives their password to every web site, then that web site can  
easily use that password to gain access to other services on behalf  
of the user (whether the user want's them to or not). This is  
typically used for applications such as webmail, where the web mail  
site uses the user's password to access an IMAP server as the user.  
If you're using web-SSO, then the application never sees the user's  
password, and so can't do this. When you're working with Kerberos,  
the web-SSO system gets round this by giving the application the  
user's Kerberos credentials, allowing other Kerberos enabled services  
to be accessed as the user. This is accomplished without the site  
getting to know the user's long term password, which is a significant  
security gain. If you don't have Kerberos, then you won't be able to  
do this - you'd need to either modify all of your backend services to  
accept cosign proxy authentication, or allow your web sites to simply  
assert identities. It all depends on what you're trying to do.

We've been through this dance at the University of Edinburgh both in  
Informatics (where I work) and centrally. I'd be happy to talk to you  
further if you'd like more information.

Cheers,

Simon.