How to use Kerberos Authentication in a Mixed (Windows and UNIX) Environment
Kerberos is the protocol of choice for mixed network environments. This article explains how to use Kerberos authentication in these mixed environments. |
|
The Kerberos authentication method originated at the Massachusetts Institute of Technology in the 1980s, as part of a project called Athena that involved integrating the computers on the MIT campus, which ran on different operating systems, in a network that offered single sign-on (SSO). At that time, most UNIX systems allowed users to access their resources as long as they had an account name and password. Microsoft's first real networking operating system was NT (Windows for Workgroups supported file and printer sharing but not network logon). It used Challenge Handshake Authentication Protocol (CHAP) and later a stronger version, MS-CHAP.
Due to weaknesses in the CHAP method and for better interoperability in mixed environments (those that ran both UNIX and Windows systems), Microsoft switched to Kerberos as the default authentication protocol beginning with Windows 2000. Mac OS X, which is based on UNIX, also uses Kerberos, so it is the protocol of choice for mixed network environments.
Note:
Prior to changes in federal laws in 2000, Kerberos – along with many other cryptography methods – was classified as a munition by the U.S. government and could not be exported outside the country.
How Kerberos Works
The current version of Kerberos is v5, which was developed in 1993. This is the version on which Microsoft's implementation in Windows 2000/XP/Server 2003 is based. Windows 2000 and Server 2003 native mode domains use Kerberos by default. Domains that must authenticate NT systems along with the newer operating systems must use NT LAN Manager (NTLM) authentication.
Kerberos was named after Cerberus, the three-headed dog of Greek mythology, because of its three components:
- A Key Distribution Center (KDC), which is a server that has two components: an Authentication Server and a Ticket Granting Service.
- The client (user)
- The server that the client wants to access
Here's how the logon process works with Kerberos as the authentication method:
- To log on to the network, the user provides an account name and password.
- The Authentication Server (AS) component of the KDC accesses Active Directory user account information to verify the credentials.
- The KDC grants a Ticket Getting Ticket (TGT) that allows the user to get session tickets to access servers in the domain, without having to enter the credentials again (the TGT is good for 10 hours by default; this expiration period can be configured by the administrator).
- When the user attempts to access resources on a server in the domain, the TGT is used to make the request. The client presents the TGT to the KDC to obtain a service ticket.
- The Ticket Granting Service (TGS) component of the KDC authenticates the TGT and then grants a service ticket. The service ticket consists of a ticket and a session key. A service ticket is created for the client and the server that the client wants to access.
- The client presents the service ticket to create a session with the service on the server. The server uses its key to decrypt the information from the TGS, and the client is authenticated to the server.
- If mutual authentication is enabled, the server also authenticates to the client.
Mixed Environment Issues
There are some differences between the MIT version of Kerberos 5 and the Microsoft implementation. In the UNIX environment, Kerberos scopes of deployment are called realms. A realm is somewhat similar to a domain in a Windows network. Users belong to specific realms and they authenticate to their respective realms just as Windows network users authenticate to the domains of which they are members. The KDC and the services and applications that use Kerberos make up the realm.
Applications and services that use Kerberos are referred to as Kerberized applications. In addition to the application itself, the authentication data is saved in a credential cache. The tickets that are issued to identify Kerberized applications are cached so that they can be reused until their expiration period is up.
The MIT version of Kerberos 5 includes the following utilities that can be used to manage Kerberos:
- Kadmin: used to make changes to the accounts in the Kerberos database
- Klist: used to view the tickets in the credential cache
- Kinit: used to log onto the realm with the client's key
- Kdestroy: erases the credential cache so it can't be used by an unauthorized user
- Kpasswd: used to change user passwords
- Kprop: used to synch the master KDC with replicas, if any
On Windows networks, the domain controller is the KDC (in addition to being the Active Directory server). Windows Kerberos supports transitive trusts between domains; this means that if Domain 1 trusts Domain 2 and Domain 2 trusts Domain 3, then there is an implicit trust between domains 1 and 3. Windows domains are arranged into hierarchical trees that form a namespace (parent domains spawn child domains that incorporate the domain name of the parent. For example, sales.acme.com is a child domain of acme.com). Groups of domain trees comprise a forest. Each tree has its own namespace, but there is a trust relationship between all trees in a forest.
Windows uses the standard Kerberos protocol as specified in RFC 1510. This means the way Active Directory user accounts are represented to Kerberos is the same as accounts in UNIX realms.
Using Kerberos in a Mixed Environment
Windows and MIT KDCs can co-exist in a mixed environment. You can have a situation where Windows clients need to authenticate to a UNIX KDC, where non-Windows clients need to authenticate to a Windows KDC, or both. You also need to consider the resources being accessed; that is, whether they're stored on a Windows or UNIX server.
You'll need to set up the Kerberos client software to use the correct KDC and realm. This is usually configured for logon to the local computer. UNIX clients can be configured to get Kerberos tickets from a Windows domain controller by using the kinit tool to point it to the Windows DC as its primary KDC. Likewise, you can configure Windows clients to authenticate to a UNIX KDC using the following Microsoft command line tool Ksetup, which configures Kerberos realms, KDCs and Kpasswd servers.
If network resources reside in an MIT Kerberos realm and you need Windows clients to be able to access them on a regular basis, you can do this by creating a one-way trust between Kerberos realm and the Windows domain, so that the realm trusts the domain. This way, when Windows users log onto the Windows domain, the UNIX Kerberos server will automatically trust them because they've authenticated to the Windows server.
If users who log onto the UNIX server also need to access resources in the Windows domain, you can create another trust that goes the other way (Windows domain trusts MIT realm), making it a two-way trust. Thus, non-Windows users log onto the UNIX server and Windows users log onto the Windows server (domain controller/KDC), and both can access resources in both the Windows domain and MIT realm because the realm and domain trust each other.
You can use account mapping to provide access control and authorization information to the Windows server for the users from the Kerberos realm. To do this, create accounts in the Windows domain that correspond to each account in the Kerberos realm and keep these accounts synchronized with each other. It's also possible to map all the accounts in the Kerberos realm to one account in the Windows domain. You can use Active Directory Service Interface (ADSI) or Lightweight Directory Access Protocol (LDAP) to synch Active Directory with the Kerberos database in the MIT realm. For example, you can write a batch script using LDAP and the kadmin utility. For detailed instructions on how to do this, see Appendix A of the Windows 2000 Kerberos Interoperability paper on Microsoft's TechNet site at http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/kerbinop.mspx
Now when, for example, a Windows client that is logged onto the Windows domain needs to access resources on the UNIX server, the Windows client will present a ticket issued by the Windows KDC to the UNIX application or service. Because a trust exists between the Windows domain and MIT Kerberos realm, the UNIX resource will accept the ticket and grant access according to the authorization method that is set for that resource.
Summary
Kerberos is an authentication standard that can be used in a mixed environment, with Windows domains (which are also Kerberos realms) co-existing with UNIX/MIT Kerberos realms. Users in one realm can access resources in the other, through the implementation of two-way trusts and account mapping. For a detailed step by step guide to configuring a Windows domain controller to serve as a KDC for MIT clients and hosts or configuring Windows clients to use a UNIX/MIT Kerberos realm, see the guide to Kerberos interoperability on the Microsoft TechNet site at http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx
About Deb Shinder
DEBRA LITTLEJOHN SHINDER, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security. She is also a tech editor, developmental editor and contributor to over 20 additional books. Her articles are regularly published on TechRepublic's TechProGuild Web site and Windowsecurity.com, and have appeared in print magazines such as Windows IT Pro (formerly Windows & .NET) Magazine. She has authored training material, corporate whitepapers, marketing material, and product documentation for Microsoft Corporation, Hewlett-Packard, DigitalThink, GFI Software, Sunbelt Software, CNET and other technology companies. Deb lives and works in the Dallas-Ft Worth area and can be contacted at deb@shinder.net or via the website at www.shinder.net
Click here for Deb Shinder's section.
Share this article
Latest articles by Deb Shinder
- The Pros and Cons of Behavioral Based, Signature Based and Whitelist Based Security
- Security in the Mobile Device Era
- Microsoft Live Mesh: What are the Security Implications?
- Securing your OCS deployment
Related links
- Kerberos Authentication Events Explained
- Linux Administrator"s Security Guide - Network Based Authentication
- Protect Against Weak Authentication Protocols and Passwords
- Securing Data in Transit with IPSec
Receive all the latest articles by email!
Receive Real-Time & Monthly WindowSecurity.com article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample
Become a WindowSecurity.com member!
Discuss your security issues with thousands of other network security experts. Click here to join!
About Us : Email us : Product Submission Form : Advertising Information
WindowsSecurity.com is in no way affiliated with Microsoft Corp. *Links are sponsored by advertisers.
Copyright © 2008 TechGenix Ltd. All rights reserved. Please read our Privacy Policy and Terms & Conditions.
Keine Kommentare:
Kommentar veröffentlichen