On 02/06/2014 04:03 AM, Dan Egli wrote: > Never did understand Kerberos. I understand it works, but the last time I > looked at I was left scratching my head and saying "Huh?"
Kerberos is actually quite simple to understand. Kerberos is a trusted, third-party, authenticator. It's usually used in the context of a lan, or a large private network, though I imagine it can be used over the internet. Say you have a number of services on the LAN (IMAP, ssh, http) that need authentication. Instead of having to configure each service individually to authenticate users, instead we have the client connect first to Kerberos, authenticate with it, and then get a cryptographic ticket. Then when the client connects to the service, it passes this ticket along. The service then, which has a preconfigured trust arrangement with the Kerberos server, checks the ticket with the Kerberos server to make sure it's valid, and then grants access to the service according to its own authorization rules. This is a simplification, but hopefully gives you the right idea. Kerberos has the following advantages: 1. central authentication database 2. passwords are never passed, encrypted or otherwise, to services 3. new services can be brought online at any time and start authenticating. Kerberos is not an authorization system. In PAM (pluggable authentication module) terms, Kerberos provides the AUTH information only; it does not know anything about the users, their uids, gids, what they have access to or not. That is provided in another way. Often using LDAP. In practice, Kerberos isn't used much in the Linux world. Practicality beats purity, I suppose. Even I've implemented LDAP servers on Linux that stored password hashes in LDAP, instead of using it with Kerberos. The real problem on Linux LDAP has always been Samba. Windows clients either required a proprietary extension to Kerberos which was locked up in patents (and used in Active Directory) or ntlm hashes, which have to be stored in LDAP (or a local tdb) which completely bypasses any Kerberos security. If you have Active Directory, or use Samba 4 as a domain controller, then Kerberos is actually integeral to the process. Samba 4 now can speak MS's Kerberos language (and serve Linux machines at the same time). On the web Kerberos principles are now widely used, but instead of tickets, they use cookies. Google's unified login for all Google apps is an example of this architecture. The details are hidden from the user but it works in the exact same way as Kerberos under the hood. And any app that connects into Google's authentication system will be doing similar things as it would with Kerberos. An open source project called CAS is similar too. We used that a lot at BYU. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
