[ 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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
