UID/GID mapping on NFS

Michael Torrie torriem at gmail.com
Thu Feb 6 09:10:15 MST 2014

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.

More information about the PLUG mailing list