As a network environment grows, the overhead on administrators needed to manage those systems grows as well. Unfortunately, where some growth can create new "economies of scale," with systems administration it often seems that the inverse is true. This is especially the case when it comes to user management. When a network is comprised of fewer than five servers, adding a new user is a relatively painless task. Simply connect to each server, add the user account (taking care to keep a consistent UID especially in NFS environments), set the password, and notify the user. However, this process becomes annoying, and eventually unmanageable as the environment grows to ten, fifty, one hundred servers and beyond. In the Microsoft Windows world there is the concept of a Domain. The domain defines all users valid for the network and creates a central place to add users, change their password, and set policies or permissions. Microsoft is hardly unique in this construct; indeed the Active Directory system is just a veneer and user interface unification of the same two technologies we are describing here: Kerberos and LDAP. Before AD or Kerberos+LDAP, there were systems such as NIS (Network Information System, still very common in legacy Solaris environments). Kerberos and LDAP can address many of the shortcomings of NIS while adding some of the nice features AD administrators are familiar with including cross-realm (cross-domain) trust and single sign-on.
The architecture described here is divided into two distinct parts: Authentication and the User Database. The sole function of Kerberos is to securely store and manage the authentication tokens. Kerberos knows nothing about the Unix/POSIX attributes of the users, and it does not need to. LDAP stores this information and makes it available to all hosts in the realm. To make an analogy, Kerberos provides the information typically stored in /etc/shadow (referenced by PAM) while LDAP provides the information stored in /etc/passwd and /etc/group (referenced by the name service switch, or NSS). It is important to note here that while LDAP can provide the authentication services to PAM, we are choosing to use Kerberos instead to gain the functionality it provides. This document will not detail configuring LDAP authentication for hosts.
Authentication Kerberos neworks are organized into "realms," commonly referred to "domains" in Windows. A realm is a complete standalone entity, containing users and hosts with trust mutually assured. At the core of the realm is a service known as the Key Distribution Center, or KDC. The KDC is the keeper of all authentication tokens, both for the end-users and for the hosts participating in the network. Each object in the Kerberos database is known as a "principal." Principals may also have multiple instances, in the form of "principal/instance." In theory, the instances are a special form of the the principal (as in the case of the "user" principal and the "user/admin" instance). In practice, instances are treated as separate principals with a distinct password and ACL definition so this document will refer to them as such. Since Kerberos is a mutual authentication system, all hosts will have a principal which, when signed by the KDC, will verify to the end user that the host with which he is communicating is valid and a participant in the Kerberos realm.
The authentication process:
LDAP-passthrough login procedure (non-SASL LDAP)
* User sends LDAP BIND request to LDAP server with "simple" authentication mechanism (username/DN and password)
* LDAP checks given DN for a Kerberos principal and contacts appropriate KDC. The KDC is sent the just-looked-up principal and the password from the BIND attempt.
* KDC returns pass/fail result for authentication attempt
* If KDC returns "pass," LDAP service access is granted (BIND operation succeeds)
* If a READ, ADD, DELETE or MODIFY operation is requested (any operation other than just BIND), LDAP ACLs are consulted based on the authenticating DN. The request may be granted or denied based on these ACLs.
LDAP SASL (GSSAPI) login procedure
* User sends LDAP BIND request using SASL mechanism (Principal and encoded TGT sent to server)
* LDAP server validates User's TGT
* User validates LDAP service's ticket
* If either ticket validation fails, the connection is aborted. If the validation succeeds, the LDAP BIND operation is successful.
* LDAP server consults rules to map Kerberos principal to LDAP DN
Example: bklang@ALKALOID.NET -> uid=bklang,ou=People,dc=alkaloid,dc=net
* LDAP server checks configured ACLs against resulting DN. Any READ, ADD, DELETE, or MODIFY operation will be allowed or denied based on the result of this ACL check.
Non-kerberized login procedure (non-GSSAPI ssh, PAM):
* User sends authentication credentials to service (username and password)
* Service contacts KDC and requests validation of given credentials
* KDC replies pass/fail to service
* If KDC reply is "pass", access is granted to service
Kerberized login procedure (GSSAPI ssh, other Kerberos or GSSAPI-aware protocols)
* User requests TGT from KDC. Password is NOT sent over the wire (refer to Kerberos protocol documentation for more information)
* User contacts service, signing the request with TGT obtained from KDC
More Here
Courtesy:http://docs.lucidinteractive.ca/index.php/Single_Sign-On_System_using_Kerberos_with_LDAP