Novell Home

AppNote: NMAS and Kerberos

Novell Cool Solutions: AppNote
By Preetam Ramakrishna

Digg This - Slashdot This

Updated: 21 Sep 2005
 

Extending Kerberos Single Sign-On to eDirectory with the NMAS Kerberos Method

AppNote by Preetam Ramakrishna

This Appnote describes how the single sign-on feature of Kerberos can be extended to eDirectory. A brief introduction to Kerberos is provided, followed by a discussion of how the NMAS Kerberos Method works and the different features it supports.

  • Topics: Authentication, Single Sign-On, Network Security
  • Products: NMAS Kerberos Method 1.0
  • Audience: eDirectory Administrators, eDirectory Users
  • Level: beginning
  • Prerequisite Skills: Authentication systems, Familiarity with NMAS Methods, Operating Systems: Linux, Solaris, NetWare, Windows

In environments where both Kerberos and eDirectory networks exist, users have both a Kerberos Identity and an eDirectory Identity. With Kerberos authentication, the user gets single sign-on access to all the "Kerberized" applications; with eDirectory authentication, the user gets single sign-on access to all the eDirectory-enabled applications. Thus, the user has to authenticate twice to get access to both the Kerberized and the eDirectory-enabled applications. Also, two passwords have to be remembered and maintained.

The NMAS Kerberos Method solves this problem by allowing the user to use his/her Kerberos credentials to authenticate to eDirectory. Thus, the user has to remember only his/her Kerberos Identity and password.

Introduction to Kerberos

Kerberos is a standard distributed network authentication system based on a trusted third-party authentication system. The user and the service do not trust each other, but both trust a common authentication server.

A Kerberos system consists of three basic entities: the Kerberos user, the Kerberized application(s), and the Kerberos server (the common, trusted authentication server).

A Kerberized application can authenicate a user based on his/her Kerberos credential. Kerberos users and applications are registered with the Kerberos server and are called principals. Each principal shares a unique secret with the kerberos server. The kerberos principals are grouped into logical groups called realms, served by one or more Kerberos servers.

Authenticating to Kerberos

The user authenticates to the kerberos server using his/her Kerberos principal and password and obtains a Kerberos credential called the Ticket Granting Ticket (TGT). The TGT is used to obtain a service ticket (ST) for accessing the particular Kerberized application.

Tickets are encrypted tokens encrypted with the particular application's secret. The TGT is a special ticket which is encrypted with the kerberos server's own secret. Along with the TGT, a user also obtains a session key encrypted with his/her password. This session key is valid for the particular login session.

Kerberos servers are also popularly known as Key Distribution Centers (KDCs) as they distribute session keys for secure communication between kerberos principals.

The tickets are valid for a particular time period. The user authenticates to the application by producing the ST corresponding to that particular application. The application server uses its secret to verify the ticket.

How Kerberos Works

Below is a basic diagram of how Kerberos works.

Figure 1 - Kerberos process flow

NMAS Kerberos Method

The NMAS Kerberos method helps eDirectory authenticate the user based on his/her Kerberos ticket. The method consists of a client and a server component. The client is installed on the user's workstation, and the server component is installed on the NMAS server in eDirectory.

The eDirectory schema is extended to store the required Kerberos data. The following Kerberos data are stored:

  • Kerberos Realm
  • Host name where the Key Distribution Center is running
  • Port where the KDC is listening for requests
  • Subtree where the Kerberos principals can be found in the tree
  • eDirectory service principal's secret

The user's Kerberos identity is associated with the user object.

Architecture

The architecture diagram of the NMAS Kerberos Method is shown below.

Figure 2 - NMAS Kerberos Method architecture

How It Works

Here is the basic process used in NMAS Kerberos authentication:

  1. The user launches the Novell Client and enters his/her eDirectory username, context, treename, and server name.
  2. The user chooses the Kerberos method from the NMAS tab for login.
  3. The Kerberos client method sends all this information to the server method.
  4. The server method returns the list of kerberos principals associated with the given user.
  5. The client displays this list to the user, and the user chooses the one he/she wishes to use for authentication.
  6. The client sends the selected Kerberos identity to the server method.
  7. The server method returns the realm information (KDC hostname and port corresponding to the chosen Kerberos identity).
  8. The user enters his/her kerberos password in the client dialog.
  9. The client then authenticates the user to the KDC and obtains a TGT.
  10. The client sends this ticket to the KDC, requesting a ticket for the eDirectory. It also sends the eDirectory service ticket to the server method as part of the authentication.
  11. Once the authentication is complete, the eDirectory credentials are obtained. Now, the user can use the eDirectory enabled applications without providing the eDirectory password.

The Credential Cache

Kerberos tickets are stored in a credential cache. The credential cache can be a file with restricted rights, or it can be a persistent memory location. The Kerberos client method uses a file as a credential cache, which it destroys once the eDirectory authentication is complete.

The Kerberos client method provides the following features for handling of credential cache:

Population of MIT Credential Cache

If the user uses Kerberized applications that are based on MIT's Kerberos libraries, then those applications look for the tickets in MIT credential cache. The MIT credential cache can be a file or a persistent memory location, depending on the MIT kerberos client configuration.

The NMAS Kerberos client method also provides an option so the user can retain the TGT (normally destroyed after the eDirectory authentication is complete). A stand-alone utitlity, provided as part of the client method, can populate the MIT credential cache with the obtained TGT from the Novell credential cache.

This process enables the user to get single sign-on access to both Kerberized applications based on MIT and eDirectory-enabled applications.

Using the Microsoft Kerberos Cache

Microsoft's implementation of Kerberos stores its credentials in memory. The tickets can be read from this cache, but the cache cannot be used to permanently store the tickets.

Users who are part of an Active Directory Domain can use the TGT obtained from MS-KDC to log in to eDirectory. The NMAS kerberos client method reads the TGT from MS credential cache, obtains a service ticket for eDirectory, and uses it to authenticate the user to eDirectory.

Usage Scenarios

Organization using Active Directory

Consider an organization having offices distributed across geographical boundaries. One of the offices (US office) has AD (Active Directory) as its primary identity store. Employees at this office would primarily authenticate to AD to access the different Windows-based Kerberized services.

In this example, the Europe office has eDirectory as its primary identity store. Employees at this office would primarily authenticate to eDirectory to access various eDirectory enabled services.

Figure 3 - Sample AD authentication

Suppose a sales manager, Ellen, wants to access the sales data of the Europe Office. She would first require an identity in the local identity store (eDirectory). Then she would authenticate to Active Directory as usual. Now, using the NMAS Kerberos Client Method's MS cache feature, she can use the obtained Kerberos Tickets to authenticate to the remote identity store (eDirectory) without providing her eDirectory password. She can access the eDirectory enabled services using the credentials obtained as part of the authentication to eDirectory.

College with Distributed Departments

Consider a college with departments that each have a separate identity store. Let's say the Physics department uses the MIT KDC as the primary identity store. That means the Physics department students primarily authenticate to this KDC and access the different kerberized services in the department. Also suppose the Math department uses eDirectory as the primary identity store, so Math students primarily authenticate to eDirectory to access the various eDirectory enabled services.

The Math and Physics departments share data. Hence, students of the Physics department would have an identity in the eDirectory of the Maths department. The students of the Physics department can access the different services in both the departments using their primary identity (Kerberos principal name).

Figure 3 - Data access in distributed departments

Students can authenticate to the MIT KDC using their kerberos identity and use the obtained kerberos tickets to authenticate to eDirectory without providing a separate eDirectory password. Now, the students can access the various eDirectory enabled services using the obtained eDirectory credentials.

Conclusion

Using the NMAS Kerberos Method, an eDirectory user needs to remember and maintain only one Identity and password. Also, the user gets single sign-on access to both Kerberized and eDirectory-enabled applications.

References

http://www.ietf.org/rfc/rfc1510.txt gives the details of the kerberos protocol.

NMAS Kerberos Login Method Admin Guide:
http://www.novell.com/documentation/nmaslm/treetitl.html


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell