Chapter 1: Overview of Authentication and Authorization Technologies and Solution End States
On This Page
.gif){kind=icon}
Introduction and Goals
The Central Role of Active Directory in Identity and Access Management
Overview of Authentication and Authorization
End States for Integrating Windows and UNIX
For More Information
Introduction and Goals
Many organizations today include computers running both UNIX and Microsoft® Windows® operating systems in their network environments. Ensuring the security of information located on either type of network infrastructure requires validating every user's identity and specifying which network data each user can access.
Currently, most organizations with heterogeneous environments maintain separate systems for Windows and UNIX to authenticate a user's identity when the user logs on to the network (or authenticates to an application server) and to determine which network resources an authenticated user is authorized to access. Maintaining these separate systems incurs administrative overhead and requires users to log on separately to each system or service that they want to access.
The goal of this guide is to demonstrate that it is both feasible and advantageous to integrate Windows and UNIX more closely than the basic interoperation at the network level that is enabled by the fact that both are TCP/IP-based operating systems. Specifically, this guide describes how to integrate Windows and UNIX at the level of authentication (determining the identity of a user before allowing the user to log on) and, optionally, authorization (determining whether an authenticated user is authorized to access a given resource on the network).
This chapter provides a brief introduction to the following topics:
The central role of the Active Directory® directory service in identity and access management.
Overview of authentication and authorization.
End states for integrating Windows and UNIX.
In this guide, an end state defines a specific set of authentication and authorization—or authentication only—interoperability options for a network of computers running the Windows or UNIX operating systems. Five end state options are defined in this guide:
End State 1. UNIX clients use Active Directory Kerberos for authentication but continue to use a UNIX-based store for authorization.
End State 2. UNIX clients use Active Directory Kerberos for authentication and use Active Directory Lightweight Directory Access Protocol (LDAP) for authorization.
End State 3. UNIX clients use Active Directory LDAP for authentication but continue to use a UNIX-based store for authorization.
End State 4. UNIX clients use Active Directory LDAP for both authentication and authorization.
End State 5. A cross-realm trust is established between UNIX-based Kerberos and Active Directory–based Kerberos in UNIX and Windows infrastructures that remain separate. Windows and UNIX clients each authenticate to their own Kerberos Key Distribution Center (KDC) and (if the trust is two-way) can then access resources hosted by computers on the other side.
More than one technology solution is available to implement a given end state. This guide describes two commercial solutions for End State 2; multiple custom or "do-it-yourself" solutions for End States 1, 2, 3, and 4; and one custom solution for End State 5.
For links to in-depth information about the topics summarized in this overview, see "For More Information" at the end of this chapter.
Intended Audience
This chapter is for business and computer professionals who are responsible for planning, designing, and implementing interoperability solutions for security and directory services, including:
Business analysts and business decision makers. Determine which changes to the network are sufficiently important to include in the budget.
Architects and planners. Design the network infrastructure, including how workstations and servers will interact for both Windows-based and UNIX-based computers.
IT security specialists. Focus on providing security across platforms within an organization.
Consultants. Help develop solutions for integrating Windows and UNIX for enterprise customers and partners. Consultants include Microsoft Worldwide Services as well as partners.
IT professionals. Assess an organization's authentication and authorization options and develop and deploy a new or updated solution. IT professionals include Corporate Information Officers (CIOs), IT directors, data center managers, or senior network engineers.
Readers familiar with authentication and authorization in both UNIX and Windows environments might want to skip "Overview of Authentication and Authorization" and read only the later section, "End States for Integrating Windows and UNIX."
The Central Role of Active Directory in Identity and Access Management
On a computer network, a directory is both a data store used for storing and organizing information about objects on a computer network and the directory service used for locating and retrieving the information about those network objects from the data store. Industry-wide directory service standards were developed, in part, to enable interoperability among vendors of different computer operating systems.
Active Directory was introduced with Microsoft Windows 2000 Server as an integral part of the server operating system and was enhanced in Windows Server™ 2003. Two core services that Active Directory provides are:
Directory services. Active Directory stores user, group, computer, and much other information about a network.
Security services. Active Directory enables clients to retrieve information from its data store in order to provide services such as authentication and authorization.
Active Directory uses a hierarchical structure—including forests, sites, domains, and organizational units (OUs) as well as the user, group, and computer accounts stored in those containers—to hold information about network objects. In addition to user, group, and computer accounts, network objects include servers, applications, shared folders (network shares), printers, domains, security policies that specify which resources a user or computer is allowed (or not allowed) to access, and other entities included in your network infrastructure. Like any directory service, Active Directory makes the network information that it stores available to authorized administrators, users, and applications.
One of the ways in which Active Directory integrates the identity of network objects with network security is by managing logon authentication as well as authorization to network resources. Active Directory is designed to be capable of authenticating user identity and authorizing or blocking user access to network resources for users of computers that run not only Windows operating systems but also operating systems other than Windows. This guide shows you how to extend the use of Active Directory as the centralized store for identity, authentication, and authorization information to UNIX-based and Linux-based computers.
The following figure depicts some of the ways in which Active Directory plays a central role for a network environment.
.gif)
Figure 1.1. Active Directory's central role in supporting a network infrastructure
Services that Active Directory provides to the network as a whole include:
Domain controller. For Microsoft Windows 2000 Server and Windows Server 2003, Active Directory runs only on domain controllers; any Windows-based server that does not run Active Directory is not a domain controller. Domain controllers store domain-wide directory data (such as system security policies and user authentication data) and manage user-domain interactions, including user logon processes, authentication, and directory searches.
Global catalog. The first domain controller installed in a Windows forest is an Active Directory global catalog, and each multi-domain forest must have at least one global catalog. The global catalog contains a replica of every object in Active Directory but only a small number of each object's attributes. The attributes in the global catalog are those most frequently used in search operations (such as a user’s first and last names and logon names) and those required to locate a full replica of the object.
LDAP. LDAP stores user accounts centrally in a single repository and provides directory services, authorization, and, optionally, authentication. Active Directory supports LDAP version 2 (v2) and LDAP version 3 (v3) and acts as the LDAP directory service for a Windows-based network.
Kerberos protocol. Kerberos provides highly secure logon and network service authentication, letting users sign on once and then transparently access network resources without being prompted repeatedly for user name and password. Active Directory supports Kerberos version 5 (v5) and acts as the Kerberos service for a Windows-based network.
Group Policy. Group Policy configuration settings stored in Group Policy objects (GPOs) enable policy-based administration. Administrators can apply policy settings to computer and user objects, controlling each object's registry, NTFS security, audit and security policy, software installation, logon and logoff scripts, folder redirection, and Internet Explorer settings. An administrator can update thousands of computers or users by changing a single GPO.
Integration with DNS. Active Directory clients typically use DNS to locate domain controllers. The integration of Active Directory with the Domain Name System (DNS) is a central feature introduced with the advent of Active Directory in the Windows 2000 Server operating system. DNS domains and Active Directory domains can and often do use identical domain names for their respective namespaces. If this is the case, the DNS and Active Directory namespaces share an identical hierarchical domain structure; however, each namespace stores different data and therefore manages different objects. DNS stores its zones and resource records. Active Directory stores its domains and domain objects. Thus, even when the DNS and Active Directory namespaces have an identical structure, the DNS host record that represents a specific computer in a DNS zone is in a different namespace than the Active Directory domain computer account object that represents the same computer.
When the DNS and Active Directory namespaces have an identical structure, a Kerberos realm (used in End State 5) is a DNS domain whose name is shown, by convention, in uppercase letters; thus, the example.com domain is the EXAMPLE.COM realm. On the other hand, if DNS and Active Directory do not share an identical structure, the example.com domain might be the MYKDC.LOCAL realm.
Alternatively, in some organizations, the DNS namespace and the Active Directory namespace do not use an identical structure.
Integration with key infrastructure services. In addition to its integration with DNS, Active Directory is also integrated with other key infrastructure services, such as Certificate Services, File and Print Services, and Remote Access Service.
Integration with key business applications. Active Directory is integrated with such business applications as Microsoft Exchange Server, SQL Server™, and Internet Information Services (IIS).
Interoperability. Active Directory supports interoperability with clients that run operating systems other than Windows and that use directory services other than Active Directory.
This guide focuses on enabling integration between UNIX and Active Directory by migrating UNIX user data to Active Directory (End States 1–4) or by establishing a cross-realm trust between UNIX and Windows infrastructures that remain autonomous (End State 5). Integrating your UNIX or Linux infrastructure with your Windows infrastructure by using Active Directory as the common centralized, scalable, and distributed directory service brings the combined benefits of Active Directory to your integrated environment.
Each of the interoperability solutions in this guide ends with a section (for the Quest Software VAS product or the Centrify DirectControl product) or chapter (for the custom solutions) about how you can evolve your chosen solution beyond authentication and authorization. After you have a stable end state solution in place, you can extend your solution to take full advantage of Active Directory as the central directory with a single identity infrastructure for computers running UNIX and Linux as well as Windows.
For more information about Active Directory and its central role in a Windows or heterogeneous network environment, see:
Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization" in this guide.
"Active Directory" on the Windows Server TechCenter at https://go.microsoft.com/fwlink/?LinkId=57073.
"Group Policy" on the Windows Server TechCenter at https://go.microsoft.com/fwlink/?LinkId=57073.
The Microsoft Identity and Access Management Series, available at https://go.microsoft.com/fwlink/?LinkId=14841.
"Active Directory Architecture" white paper at https://go.microsoft.com/fwlink/?LinkId=51956.
Overview of Authentication and Authorization
Authentication and authorization—both integral components of identity and access management—are separate security mechanisms that work together to help ensure network security:
Authentication. Verifying that a user, computer, or service (such as an application provided on a network server) is the entity that it claims to be. Authentication is an important part of identity management.
Users, computers, and services that can be authenticated when they log on to a network or, after logon, when they authenticate to a network service, are known collectively as principals, security principals, or digital identities.
Authorization. Determining which actions an authenticated principal is authorized to perform on the network. The tasks required to control authorization are also referred to as access management.
Data about principals that specifies which network objects a principal is authorized to access and what level of access is allowed is kept in a repository called an authorization store.
Colloquially, the relationship between authentication and authorization might be summarized as "Now that I know who you are, here's what you can do."
This section provides a brief overview of each of the following topics:
Authentication and authorization mechanisms.
Kerberos and LDAP.
UNIX authentication and authorization.
Windows authentication and authorization.
Authentication and Authorization Mechanisms
Some methods used by Windows and UNIX for authentication and authorization have evolved in isolation from each other. Other methods are based on standard, platform-independent protocols that both Windows and UNIX can use.
The following sections describe the authentication and authorization mechanisms available in Windows and UNIX.
Logon Authentication
Authenticating the identity of users who want to log on to a computer on a network is an important part of network security. Windows and UNIX can use the logon authentication mechanisms listed in the following table.
Table 1.1. Windows and UNIX Logon Authentication Mechanisms
Windows Logon Authentication |
UNIX Logon Authentication |
|---|---|
|
Note For UNIX or Linux operating systems that support pluggable authentication modules (PAM), all of the nondefault UNIX-based authentication methods are enabled through PAM. The Solaris and Red Hat operating systems used in this guide support PAM. (For more information about PAM, see "Using PAM" later in this chapter.) |
Authentication mechanisms can be used singly or in combination. For example, a smart card logon typically also requires a password.
Application Authentication
In the context of network environment security, authentication refers not only to the process of validating the identity of a user when the user logs on to a network computer but also to the identity validation that occurs between a client and a server. For example, if Kerberos v5 authentication is the authentication method in use on your network, application authentication refers to the process of mutual validation that takes place between client and server when the user logged on to the client attempts to connect to an application hosted by the server. The client and server must verify each other's identity before the client can access the network resource residing on the server.
If mutual authentication between client and server is successful (and if the user is authorized to access the resource on that server), the user can connect to the network resource without being prompted for a user name and password. This capability, when a user types a user name and password to authenticate to the network at logon and can then connect to various applications, is called single sign-on (sometimes abbreviated SSO). Single sign-on makes multiple applications and services available to the user over the network without the user having to provide credentials more than once.
Authorization
Windows Server 2003, Windows 2000 Server, and Windows XP use Active Directory–based authorization. Active Directory and UNIX can use the authorization stores listed in the following table.
Table 1.2. Windows and UNIX Authorization Stores
Windows Authorization |
UNIX Authorization |
|---|---|
Active Directory LDAP |
|
Kerberos and LDAP
Most implementations of UNIX and the Active Directory service in Windows Server 2003, Windows 2000 Server, and Windows XP can use Kerberos and LDAP to provide secure, centralized authentication for identified users and to determine if an authenticated user is authorized to access a specific network resource.
Both Kerberos and LDAP are platform-independent TCP/IP-based IETF standards, and both are client/server protocols. The following sections describe these protocols independently of any specific implementation.
Kerberos
Kerberos is a network authentication protocol that enables secure logon by individuals to a computer network and enables secure authentication by a client computer to a server hosting a network resource. The Kerberos IETF standard was originally developed at the Massachusetts Institute of Technology (MIT) to provide strong authentication for a TCP/IP-based client/server network. The primary purpose of Kerberos is to authenticate two principals to each other and to establish a cryptographic key that the two can use to secure any messages they exchange with each other. Each client and server shares a secret key known only to it and to the KDC; knowledge of this key serves as proof of a computer's identity.
Kerberos authentication involves three types of entities:
Kerberos clients. Users, computers (workstations or servers), or applications that require authentication to connect to a network or to a resource on the network.
Kerberos servers. Servers that provide a network resource that clients need.
Kerberos Key Distribution Center (KDC). The KDC service that maintains a database with account information for all principals (users, groups, computers, or services) in its Kerberos realm.
On a Windows network, a Kerberos realm is the equivalent of an Active Directory domain, and the KDC is an Active Directory service. As explained earlier, by convention, a realm name is the DNS domain name converted to uppercase. For example, in a Windows network, the example.com Active Directory domain is the Kerberos realm EXAMPLE.COM.
Kerberos authentication requires host name resolution because, to locate a Kerberos server, a client needs the IP address of a Kerberos server in its domain. In most enterprises, including Windows and many UNIX implementations, host name resolution is done by using DNS. Alternatives to DNS for resolving a host name to its corresponding IP address include hosts files and LDAP.
The Kerberos KDC provides two services as a single process:
Authentication Service (AS). The AS authenticates a user and issues a ticket-granting ticket (TGT) that the client uses to request a service ticket:
TGT. A TGT enables the AS to safely transport the requester's credentials to the ticket-granting service (TGS). A TGT, which is sometimes called "a Ticket to Get Tickets" as a mnemonic device, typically has a default lifetime of 10 hours.
Service ticket. A service ticket is a credential presented by a client to a network service when the client authenticates to that service.
Ticket-Granting Service (TGS). The TGS issues service tickets for network services based on the TGT issued to a client. The service tickets issued by the TGS to clients let clients authenticate to other services on the network. After logon, when a client wants to authenticate to a network service, it must contact the TGS, present a TGT, and ask for a service ticket for that network service.
For a depiction of this process on a Windows-based network, see "Active Directory Kerberos" later in this chapter.
For a list of resources about Kerberos, see "For More Information" at the end of this chapter.
LDAP
The Lightweight Directory Access Protocol (LDAP) is a network protocol designed for querying directory services and modifying data in a directory store. The LDAP IETF standard provides access to a directory service on a TCP/IP-based client/server network. The LDAP standard specifies a protocol for communicating between LDAP clients and servers but leaves the implementation details for LDAP servers to the vendors who develop LDAP products. An LDAP client connects to an LDAP server, issues a query, receives a response, and disconnects from the server.
LDAP defines how to query an existing directory, how to refer to an entity in the directory, how to describe the characteristics of an entity, and the security features that control access to the entities within the directory. LDAP, which updates the older X.500 Directory Access Protocol (DAP), is designed to store information hierarchically. An LDAP directory is structured as a tree of entities; each entity consists of named attributes; and each attribute can contain certain types of values. LDAP can use DNS names for structuring the top levels of the hierarchy and typically uses entries representing network objects (for example, users, groups, computers, or printers) at the lower levels of the hierarchy.
LDAP is extensible to enable the addition of new features (schema extension) while maintaining backward compatibility. Currently, all major directory services conform to the LDAP standard. Windows-based Active Directory and UNIX-based iPlanet are examples of LDAP directories.
An LDAP directory is similar to a relational database but lacks some features of a relational database and contains descriptive, attribute-based data that is read more often than it is modified. A UNIX-based LDAP directory can be read by using the ldapsearch tool. Originally a UNIX command-line tool for querying a UNIX-based LDAP directory, ldapsearch can also be compiled for Windows and used to search for and display attributes of Active Directory objects.
Clients and client applications use host name resolution to locate LDAP servers.
LDAP consists of four component models:
Information model. The LDAP information model provides the data structures and data types necessary to describe the attributes of an entry. The attributes and the characteristics associated with an entry are defined in the entry's object classes. The definition of object classes and attributes is held in the schema. An LDAP directory requires the capability to search for specific entries by their attribute values.
Naming model. The LDAP naming model defines how each entry can be referenced. In an LDAP directory, entries are organized in a hierarchical tree called a Directory Information Tree (DIT). Each node in the tree is an entry that can both store information and be a container for other entries. There are two methods of referencing an entry in the tree: using its relative distinguished name (RDN) or its distinguished name (also known as DN). An RDN is unique within a directory, and a distinguished name is globally unique.
Functional model. The LDAP functional model is the method by which a directory client can communicate with the directory. This is the LDAP protocol itself. LDAP provides the following operations:
Interrogation. This operation allows searching of the directory.
Modification. This operation allows updating, adding, or deleting entries in the directory.
Authentication and control. This operation allows authenticating to the directory (the bind operation).
Security model. The LDAP security model provides methods for authenticating against the directory and for authorizing client access control to the directory. There are two components to the security model:
Authentication by using LDAP binds. LDAP authentication involves an entity binding to the LDAP server. The success of the bind operation is determined by the acceptance or rejection of the entity's credentials. If the bind is successful, the entity is authenticated; if it is unsuccessful, the entity is not authenticated.
Access control to objects in the directory. After a client is authenticated, the client can use the LDAP directory only as defined by the directory's access control lists (ACLs). Each network object has an ACL that identifies user accounts, groups, and computers that are allowed (or denied) access to that object. The implementation of ACLs in an LDAP directory is implementation-dependent.
For information about using Active Directory LDAP for authorization or for authentication, see "Active Directory LDAP" later in this chapter. For a list of resources about LDAP, see "For More Information" at the end of this chapter.
UNIX Authentication and Authorization
Computers in a UNIX-based network can use the default authentication and authorization mechanisms that are built in to UNIX or Linux operating systems. By default, these mechanisms use text files for storing user and group configuration information. Alternatively, a UNIX-based network can use other methods, including Kerberos and LDAP, for authentication and authorization.
This section briefly summarizes file-based authentication and authorization for UNIX. It also introduces pluggable authentication modules (PAM) that support non-file–based authentication methods and the name service switch (NSS) that supports non–file-based authorization methods.
For more in-depth information about UNIX, including file-based authentication and authorization services, PAM, and NSS, see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."
File-based Authentication and Authorization
By default, UNIX operating systems use the following text files, located in the /etc directory, for authentication and authorization:
/etc/passwd
/etc/shadow
/etc/group
These files are used for authentication and authorization as follows:
Used for both authentication and authorization—/etc/passwd file. User account information is stored in the /etc/passwd file. This file contains UNIX directory service information (if no other directory service is used) and is used for authentication and authorization as well as for other purposes.
The /etc/passwd file contains the information required by user programs to map user names to user identification (UID) numbers. On a computer with no other authentication sources, this file contains entries for all users of the computer. Even when the file-based authentication method is augmented by other authentication methods, this file is still essential for the correct operation of the system. The standard format for each entry in the /etc/passwd file is:
username:password:uid:gid:gcos-field:home-dir:login-shell
These fields are defined as follows:
username. The unique name of the user account on this computer.
password. In most UNIX and Linux implementations, the password field contains an asterisk (*) instead of the plaintext password. The actual password is stored as a one-way hash in the /etc/shadow file (described later).
uid. The user ID or unique ID number associated with the user account. This number is assigned to files or directories to which the user has specific permissions (as opposed to permissions assigned through membership in a group). This is similar to the access control mechanisms used in Active Directory and controlled with the user's logon name.
gid. The group ID number of the primary group associated with a user account. Like Active Directory, UNIX separates group membership into a primary group and multiple secondary groups for a user. A user must be associated with a primary group. The addition of secondary groups is optional. Group IDs are assigned to files and directories to provide access control for groups of users.
gcos-field. The field named, for historical reasons, the General Electric Comprehensive Operating System (GECOS) field, can be used to hold any data. Traditionally, it holds the user's full name and might contain other data, such as the user's phone number.
home-dir. The full path and directory name of the user's home directory.
login-shell. The program environment in which the user will operate upon initial logon. Examples of this include /bin/csh (C Shell), /bin/sh (Bourne Shell), and /bin/bash (Bourne Again Shell). All shells are not supported by all operating systems.
Used only for authentication—/etc/shadow file (optional). Encrypted passwords—that is, a one-way hash of passwords—are stored in the /etc/shadow file, which was developed to improve security for UNIX passwords. Because the /etc/passwd file must be readable by everyone so that programs can map user names to UIDs, it is relatively easy to carry out a brute force attack where all possible values are tried one-by-one. You can resolve this problem by removing the encrypted password from /etc/passwd and storing it in /etc/shadow, which can only be read by the system superuser (root). Use of the /etc/shadow file is optional, although some systems are configured to use it by default. The standard format for the /etc/shadow file is:
username:password:lastchg:min:max:warn:inactive:expire:flag
These fields are defined as follows:
username. The user's logon name.
password. An encrypted password.
lastchg. A number indicating the last date that the password was modified.
min. The minimum number of days required between password changes.
max. The maximum number of days the password is valid.
warn. The number of days before a user is warned that the password is about to expire.
inactive. The number of days of inactivity configured for that user.
expire. A number indicating when the password will expire.
flag. A number indicating the number of failed logon attempts.
The hashing algorithm used to create the one-way hash of the password that UNIX-based computers store is, traditionally, a variant of the Data Encryption Standard (DES); more recently, the hashing algorithm used is Message Digest 5 (MD5). In UNIX or Linux environments, the crypt() application programming interface (API) is used to compute the hash. This function takes a plaintext password and returns the cryptographic hash text appropriate for use with this system.
Used only for authorization—/etc/group file. Group information is stored in the /etc/group file and is referenced in the passwd file by the GID field. The standard format for the /etc/group file is:
groupname:password:gid:user-list
These fields are defined as follows:
groupname. The name of the group.
password. If the password field is empty, no password is required.
gid. The unique ID number associated with this group.
user-list. A list of users allowed in the group (separated by commas).
File Access Mode
Authorization on UNIX-based computers is based on UIDs and GIDs and is provided at the individual file level through access permissions (read, write, or execute) that are set on files, directories, and programs. In UNIX, the file access mode refers to the default access permissions that are applied to any file or directory when it is created. A user can use the UNIX list (ls) command to list permissions for files and directories and (if the user is the owner or has root access to where the files or directory reside) can use the change mode (chmod) command to assign or change the access mode of files or directories.
The read, write, and access permissions on a file or directory are represented in a UNIX command-line shell by the letters r, w, and x. These permissions apply to three types of users, as shown in the following table.
Table 1.3. Access Permissions
Owner Permissions |
Group Permissions |
Permissions for Everyone Else |
|---|---|---|
rwx |
rwx |
rwx |
For example, the following permissions indicate that the owner has read, write, and execute permissions, the group has read and write permissions, and everyone else has only read permissions:
rwxrw-r--
Authorization Data Retrieved When a UNIX User Logs On
When a user attempts to log on to a UNIX-based computer, the operating system must retrieve both authentication data (user name and password) and authorization data for the user. The UNIX authorization data defines the environment in which the user will operate and the tools and files to which the user will have access, including whether the user has read, write, or execute access to files and directories. A UNIX client must retrieve UNIX authorization data in order to perform the access checks defined by the file access mode. The authorization data needed for UNIX logon includes these UNIX attributes for the user: UID, primary GID, home directory, and login shell. In addition to these attributes, the GECOS field might also be required.
As described later in this chapter, authorization information for a UNIX client that participates in an End State 2 or End State 4 solution is migrated to Active Directory and is retrieved from Active Directory by the UNIX client when a solution for either of these end states is deployed. However, Active Directory prior to the R2 release of Windows Server 2003 does not include the UNIX attributes listed previously and thus, in most cases, configuring an End State 2 or End State 4 solution requires extending the Active Directory schema so that it can store these UNIX attributes.
Windows Server 2003 R2 includes support for RFC 2307 (which introduces the LDAP attributes used to store UNIX or Linux user and group account information) as part of its default installation. None of the solutions developed in this guide were tested with Windows Server 2003 R2.
The commercial solutions in this guide can each use a variety of methods to handle UNIX authorization data in Active Directory. The custom solutions in this guide use Windows Services for UNIX to handle UNIX authorization data.
For more information about the UNIX file system, see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."
PAM and NSS Add Secure Authentication and Authorization to UNIX
The limited form of file-based authentication and authorization used by default in UNIX environments has significant drawbacks. Approaches to overcome these limitations include the following:
PAM supports multiple authentication methods. Pluggable authentication modules (PAM) can support a variety of authentication methods.
This capability underlies all of the authentication solutions described in this guide. It allows UNIX-based computers to authenticate against Active Directory when either Kerberos or LDAP is used for authentication.
NSS supports multiple authorization methods. Name service switch (NSS) can support a variety of mechanisms for looking up user and group information.
This capability underlies the authorization solutions described in this guide that allow UNIX-based computers to retrieve authorization information from the Active Directory LDAP store.
Both PAM and NSS are important for the technology solutions used to achieve most of the end states described in this guide. Any solution that uses the Active Directory server for authentication or authorization, or both, requires that you configure UNIX-based computers participating in that solution to act as Active Directory clients. In part, this means configuring the UNIX client to use PAM as part of an authentication solution and to use NSS as part of an authorization solution.
Using PAM
The PAM service provides one interface that makes alternative authentication methods available. Typically, UNIX users log on by supplying a unique user name and a password. PAM allows user name and password authentication to be performed in ways that are more secure than comparing strings in text files.
One important feature of the PAM configuration files is that rules defining the behavior of the PAM modules can be stacked to combine the features of different PAM modules for a specific task. The stack contains various mechanisms (modules) to perform the authentication check. Each PAM module checks to see if the user name and password match, using whatever approach is correct for that module. For example:
An /etc/passwd PAM module looks for the user entry in the /etc/passwd file. If the module finds the user entry, the module passes the user-supplied password through the cryptographic API and checks it against the hash stored in /etc/shadow.
A Kerberos PAM module uses the user-supplied user name and password to attempt to retrieve a TGT for that user from the KDC. In this process, no form of the password itself ever goes out over the network.
PAM also enables different methods of authentication that do not use user names and passwords, such as retina scans and smart cards.
On systems that use PAM, the logon process and some tools that require user authentication must be designed to use PAM for authentication and authorization. You must also configure PAM to correctly handle the different authentication methods allowed on a particular system. This configuration is comparatively simple because PAM provides a standard plug-in interface that developers can write to.
In the authentication solutions for End States 1–4 included in this guide, PAM enables UNIX clients to authenticate against Active Directory using either Kerberos or LDAP.
Note UNIX-based applications might or might not be designed to use PAM. In a Kerberos environment, tools such as telnet, rlogin, and ftp can either use PAM for authentication on the server side (the telnetd, krlogind, and ftpd services) or can use Kerberized versions of these services that might or might not use PAM, depending on design and configuration. Some tools that require user authentication might be capable of using Kerberos credentials directly and therefore do not need PAM support. For example, the Kerberos kinit tool does not use PAM. A user might use kinit to authenticate and receive a credential that can be used to access an application.
For a list of resources about PAM, see "For More Information" at the end of this chapter.
Using NSS
The NSS architecture was developed to allow UNIX-based computers to use different methods for obtaining configuration information, including identity and authorization information. By using NSS, applications can, for example, obtain a user name by providing a UID or obtain a list of group memberships by providing a GID. This process is independent of the underlying mechanism performing the lookup.
The NSS architecture allows administrators to specify which data stores to query to obtain information. NSS can be used to retrieve UNIX configuration information from the following types of stores:
Text files
NIS
NIS+
DNS
LDAP
In the authorization solutions for End States 2 and 4 included in this guide, NSS enables UNIX clients to use Active Directory LDAP as the authorization store.
Windows Authentication and Authorization
Active Directory stores user account information, authenticates users, and enforces security policy for a Windows-based (or heterogeneous) network. Active Directory is integrated with the Windows security subsystem through logon authentication and through access control to objects in the directory. It ensures that only authenticated users can log on to the network and that each network resource is available only to authorized users or to members of authorized groups.
Active Directory uses the Kerberos protocol and LDAP as follows:
Active Directory uses the Kerberos protocol for authentication (by default).
Active Directory uses LDAP for authorization (by default).
Active Directory can use LDAP for authentication (optionally).
Because Active Directory, by default, uses the Kerberos v5 protocol for authentication and LDAP v3 for authorization, Active Directory is compatible with Kerberos v5 clients and LDAP v3 clients across all platforms, including UNIX and Linux. Together, Active Directory authentication and authorization can provide a strong, easy-to-administer security system for a mixed network.
Before you begin exploring how to extend Active Directory authentication and authorization to UNIX users, it is helpful to first gain an understanding of how Active Directory uses the Kerberos and LDAP protocols to handle identity authentication and access management.
This section includes the following topics:
Active Directory Kerberos
Active Directory LDAP
Example: Kerberos and LDAP in a mixed environment
Active Directory Kerberos
By default, the Kerberos protocol is the gatekeeper that enables authentication to an Active Directory network. Active Directory works with the Kerberos protocol to confirm the identity of any user trying to log on to an Active Directory domain and lets authenticated users access resources that they are authorized to access located anywhere on the network. Kerberos single sign-on provides access to resources within an Active Directory domain and to resources located in trusted domains.
On an Active Directory–based network, the Kerberos KDC is implemented as a domain service, and each Active Directory domain controller runs the KDC service. Kerberos uses Active Directory as its account database and uses a special kind of domain controller, called a global catalog, to direct referrals for a client to KDCs in other domains in the Active Directory forest.
The Kerberos client component runs on all nondomain controller computers that are running Windows Server 2003, Windows 2000 Server, or Windows XP and are joined to an Active Directory domain. Every Active Directory domain controller acts as a KDC; therefore, a client can find a KDC server by querying DNS (or by using a non-DNS method for host name resolution) for the IP address of a domain controller in its domain.
RFC 1510, which defines Kerberos v5, specifies that the security principal name of a KDC is krbtgt. Windows creates this account automatically whenever you run the Active Directory Installation Wizard (the dcpromo command) to create a new domain. Clients address messages to a domain's KDC by specifying both the service principal name (krbtgt) and the name of the domain.
The Kerberos Ticket Process in Active Directory
Like other implementations of the Kerberos protocol, with Active Directory Kerberos, a user is authenticated by successfully logging on, and then each subsequent client/server connection requires that the client and server mutually authenticate each other. If the authentication process is successful, a secure client/server session is established and the client can then connect to the network service that the server provides.
When the user logs on, the client first contacts the KDC service running on the Active Directory server to authenticate to the network (interactive logon), during which process the client requests and the Kerberos authentication service (AS) returns a ticket-granting ticket (TGT). The client can then request service tickets from the KDC for specific network resources (network authentication). The client obtains a service ticket from the Ticket-Granting Service (TGS) on the KDC during the latter part of the authentication process. Then, the client presents this ticket to the network server with which the client wants to interact. A Kerberos ticket represents the client's network credentials throughout the period of time that the client is logged on to the network. The interaction is not bilateral between the client and the server hosting the network resource to which the client wants to connect; instead, it is a trilateral interaction between the client, the AS and TGS on the Active Directory KDC, and the server hosting the network resource.
Illustration of the Kerberos Ticket Process in Active Directory
The following figure illustrates a simplified version of the steps that take place in the Kerberos authentication process on an Active Directory network. Two exchanges—first between the client and the AS on the Active Directory server to obtain the TGT and then between the client and TGS to obtain the service ticket—are followed (if both exchanges succeed) by the establishment of a session between the client and a server hosting the network resource that the user wants to access. A new client/server session can be established later without repeating the process, that is, without prompting the user to provide a password more than once.
.gif)
Figure 1.2. Interactive logon followed by authenticating to a network resource
The following steps outline the Active Directory–based Kerberos single sign-on process depicted in the figure.
When the user logs on to a computer, the Kerberos client component on the user's workstation begins the logon authentication process to the KDC service on the Active Directory domain controller by requesting a TGT from the AS component of the KDC.
If the AS successfully validates the user's identity, the AS provides a TGT to the user.
When Kerberos returns the TGT to the user, Windows includes information called a Windows Privilege Attribute Certificate (PAC) in the Kerberos v5 authorization data field. The Windows Local Security Authority (LSA) on the client uses the PAC to create an access token. Windows will use the access token later to enforce access checking when the client attempts to access network objects.
The LSA is a Windows subsystem service used for logon authentication. The access token identifies the user to the network, identifies the groups to which the user belongs, and identifies the user's rights to access specific network objects. Each network object has an Access Control List (ACL) that identifies the users and groups that are authorized to access that object as well as users or groups to which access is denied.
Because Active Directory Kerberos provides the user rights data in the PAC, no call to LDAP is needed to assemble the user data at logon. (This differs from the logon process on a UNIX network that uses, for example, MIT Kerberos. In the UNIX case, the system uses UNIX LDAP APIs to retrieve user authorization data at logon.)
When the user attempts to contact a network resource for the first time, the Kerberos client does not send a request directly to that resource. Instead, the client sends its TGT to the TGS component of the KDC, requesting a service ticket specifically for the network resource to which it wants to establish a connection.
The TGS returns a service ticket to the client for the network resource to which the client wants to connect.
Next, the client sends the service ticket that it received from the KDC to the network resource to which it wants to connect:
If mutual authentication occurs—that is, if the client successfully identifies itself to the network resource, and if the network resource successfully identifies itself to the client—the client can contact the resource.
After the user authenticates to the network and then authenticates to the network resource, the user is allowed or blocked from actually accessing the information available on the network resource based on a comparison of the privileges in the user's access token with the permissions specified in the ACL of the resource.
When the client wants to contact the same network resource again, it checks its ticket cache for a service ticket valid for that network resource.
If the client finds a valid ticket, it presents the ticket for access.
If the ticket has expired, the client must return to the TGS to renew the out-of-date ticket.
When the user on the client wants to access a different network resource, the client can use the TGT that it received initially from the KDC for the network resource that the client contacted earlier. The client submits the TGT to the TGS along with the name of the new network resource that the client wants to contact. After validating the user's identity, the TGS issues a service ticket for the new network resource, which the client stores in its system cache and uses to contact the new network resource.
This process, which occurs repeatedly over the course of a typical day, is transparent to the user because single sign-on means that the user is prompted for credentials only once, when initially logging on to the computer.
The interaction between the KDC, the client, and the network resource when Kerberos authentication takes place is actually much more complex than the simplified version just described. For a list of resources about the Kerberos protocol, see "For More Information" at the end of this chapter.
The secure user authentication provided by Kerberos v5 is tightly integrated with Windows Active Directory; in addition, a growing number of other operating systems, including implementations of UNIX and Linux, can use Kerberos. For this reason, the Kerberos standard plays an increasing role in enabling computers running the Windows and UNIX or Linux operating systems to interoperate with each other in a heterogeneous environment.
For information about using Active Directory Kerberos to authenticate UNIX clients, see "End State 1: Use Active Directory Kerberos to Authenticate UNIX Clients" and see "End State 2: Use Active Directory Kerberos to Authenticate and Active Directory LDAP to Authorize UNIX Clients" later in this chapter.
Active Directory LDAP
Active Directory implements an LDAP directory service that runs on Windows Server 2003 and Windows 2000 Server domain controllers. Active Directory supports LDAP v2 (RFC 1777) and LDAP v3 (defined in a series of IETF RFCs, which are summarized in RFC 3377). LDAP is the only network protocol used to access information in Active Directory.
Because LDAP v3 is an industry standard, it can be used to provide interoperability with any directory service that implements the LDAP protocol. Thus, Active Directory uses LDAP to enable interoperability with other LDAP-compatible client applications. Given the appropriate permission, you can use any LDAP-compatible client application to browse, query, add, modify, or delete information in Active Directory.
Active Directory LDAP As Directory Store
Like any LDAP directory service, Active Directory stores and organizes information about a network and allows administrators to manage access to network resources. LDAP is used to add, modify, and delete information stored in Active Directory as well as to query and retrieve data from Active Directory. LDAP defines how services or applications running on a directory client can access a directory server (in Windows, a domain controller) and how the client can perform directory operations and share directory data.
Active Directory stores information about directory objects in the Ntds.dit file located, by default, in the C:\Windows\Ntds folder on each domain controller. The .dit extension stands for directory information tree. To ensure availability, directory data is replicated to other domain controllers in an Active Directory domain.
The Windows Server 2003 and Windows 2000 Server operating systems include several Active Directory administrative tools, and a related Group Policy tool, to simplify directory service administration. These tools are Microsoft Management Consoles (MMCs), which are graphical user interface (GUI) consoles that host administrative tools called snap-ins:
Active Directory Users and Computers snap-in. Used to create and manage Active Directory accounts for users, groups, and computers, including passwords and other configuration information. When you deploy an End State 1, 2, 3, or 4 solution, you migrate UNIX accounts to Active Directory and can administer these accounts with the Active Directory Users and Computers snap-in. The UNIX user acquires an Active Directory account, and the UNIX client is joined to the Active Directory domain.
Active Directory Domains and Trusts snap-in. Used to create and manage Active Directory domains and trusts. For an End State 5 solution, you use this tool to configure a trust between an Active Directory–based domain and a UNIX-based Kerberos realm.
Active Directory Sites and Services snap-in. Used to create and manage Active Directory sites.
Active Directory Schema snap-in. Used to extend the Active Directory schema. If you deploy an End State 2 or End State 4 solution (and if your domain controllers are running an operating system earlier than Windows Server 2003 R2, which includes UNIX attributes by default), most solutions included in this guide require that you extend the Active Directory schema to include UNIX authorization data (UID, primary GID, home directory, and UNIX login shell).
Although each solution in this guide (except for End State 5) requires that you extend the Active Directory schema, you might or might not need to use the Active Directory Schema snap-in to extend the schema. If, for example, you deploy one of the custom solutions, which use Windows Services for UNIX, you do not need to use this tool to extend the schema.
Group Policy snap-in. Used to create and configure Group Policy objects (GPOs), which contain policy settings and control settings for users, groups, and computers in Active Directory sites, domains, and organizational units. The Group Policy snap-in is accessed either through Active Directory Users and Computers or through Active Directory Sites and Services (depending on which task you want to perform).
You can also use command-line tools to configure, manage, and troubleshoot Active Directory.
Active Directory LDAP As an Authorization Mechanism
Active Directory works with the LDAP protocol to secure resources from unauthorized access. For Windows clients, after a user account is authenticated and can therefore potentially access a network object, the type of access actually granted to the user to access specific network objects is determined by user rights, which are assigned to group (or user) accounts, and by access control permissions, which are attached to the network objects that the user wants to access.
In order for LDAP to be used by a UNIX client for authorization in an End State 2 or End State 4 solution, in the custom solutions included in this guide, the UNIX client must be configured to use LDAP NSS. In the commercial solutions (Quest VAS or Centrify DirectControl), the UNIX client must be configured to use the commercial product's NSS module.
For information about using Active Directory to authorize UNIX clients, see "End State 2: Use Active Directory Kerberos to Authenticate and Active Directory LDAP to Authorize UNIX Clients" and see "End State 4: Use Active Directory LDAP to Authenticate and Authorize UNIX Clients" later in this chapter.
Active Directory LDAP As Authentication Mechanism
In addition to the role that Active Directory LDAP plays as a source of information used for authorization, Active Directory LDAP can also, optionally, be used to authenticate users, such as users on UNIX clients migrated from an environment that does not use Kerberos. Although, by default, LDAP provides authorization and Kerberos provides authentication on a Windows-based network, it is also possible for Active Directory LDAP to store authentication information and thus to authenticate users as they log on and to enable clients to authenticate to a network service.
Unlike Kerberos, which is designed as an authentication mechanism for users logging on and for clients connecting to resources on network servers, LDAP authentication is designed specifically for securing directory transactions. Using LDAP authentication for purposes other than LDAP directory access (such as using it for logon authentication) might provide performance that is slower than when Kerberos is used for authentication. This is because LDAP directory services are not designed to handle large numbers of authentication requests. Instead, LDAP is tuned to perform optimally when handling directory transactions.
In order for LDAP to be used by a UNIX client for logon or service authentication in an End State 3 or End State 4 solution, the UNIX client must be configured to use LDAP PAM.
For information about using Active Directory to authenticate UNIX clients, see "End State 3: Use Active Directory LDAP to Authenticate UNIX Clients" and "End State 4: Use Active Directory LDAP to Authenticate and Authorize UNIX Clients" later in this chapter.
Example: Kerberos and LDAP in a Mixed Environment
The example in the following table compares the sequence, in real time, for client authentication and authorization in one possible interoperability solution—in this case, an End State 2 solution—that uses Active Directory to support both Windows-based and UNIX-based computers. In this example, the user on the UNIX client, like the user on a Windows client, has an account in Active Directory, uses Active Directory Kerberos for authentication, and uses Active Directory LDAP for authorization.
As the user logs on, each client interacts with Kerberos and LDAP. This interaction achieves the same end but differs in some of the details depending on whether the client computer is running Windows or UNIX.
Table 1.4. Example: Comparison of Windows and UNIX Client Interaction with Kerberos and LDAP in an End State 2 Solution
Windows Client |
UNIX Client |
|---|---|
Start: Adam sits down at his Windows workstation and types his Active Directory user name and password. |
Start: Eva sits down at her UNIX workstation and types her Active Directory user name and password. |
PAM: [Not applicable—the Windows client does not use PAM.] |
PAM—mediates between UNIX client and Kerberos: The UNIX client hands Eva's user name and password to PAM. PAM hands Eva's user name and password to the PAM Kerberos module on the UNIX client. |
Kerberos: Kerberos on the Windows client contacts the KDC on the Active Directory server to request a TGT from the AS component of the KDC. If the AS successfully validates Adam's identity, the AS returns a TGT to Adam's Windows-based workstation. The TGT includes the Windows PAC in the Kerberos v5 authorization data field of the Kerberos ticket. Now Adam is authenticated. The Windows client puts away the TGT for future use. |
Kerberos: The PAM Kerberos module on the UNIX client contacts the KDC on the Active Directory server to request a TGT from the AS component of the KDC. If the AS successfully validates Eva's identity, the AS returns a TGT to Eva's UNIX-based workstation. The TGT does include the Windows PAC and authorization data—but most UNIX implementations cannot make use of it. Now Eva is authenticated. The UNIX client puts away the TGT for future use. |
PAC and access token: LSA (a Windows subsystem used for logon authentication) on Adam's Windows-based workstation uses the PAC to create Adam's access token. Adam's access token defines Adam's rights, which are contained in Adam's security identifier or SID (which identifies him to the network) and in the SIDs of each group to which he belongs. |
PAC and access token: [Not applicable: Eva's UNIX client does not use the Windows PAC. Eva does not have an access token and therefore does not have SIDs.] |
LDAP calls: [Not applicable: Because Active Directory Kerberos provides the user rights data in the PAC, no call to LDAP is needed to assemble the user authorization data at logon.] |
LDAP calls—UNIX login uses NSS to perform LDAP lookups: The UNIX client connects to the LDAP server (the Active Directory server) to retrieve Eva's UNIX authorization, using Eva's user name to do the lookup:
|
Adam accesses a network resource: Adam is allowed or blocked from accessing information on the network resource based on a comparison of the rights in his access token with the permissions specified in the ACL of the network resource. The Windows System Resource Manager on the network resource performs this comparison. |
Eva accesses a network resource: Eva is allowed or blocked from accessing information on the network resource based on a comparison of the rights in her UID and GIDs with the permissions specified in the ACL of the network resource. The UNIX kernel on the client performs this comparison. |
Of the five end states in this chapter, End State 2 (the example used in Table 1.4) provides a level of integration with Active Directory for UNIX-based computers that is closer to that available by default in an Active Directory–based domain for Windows computers than the integration provided by the other end states. Of all the possible end states, End State 2 thus has the highest potential for secure interoperability between Active Directory and UNIX-based computers and applications.
For more information about how each end state handles authentication and authorization, see "End States for Integrating Windows and UNIX," described next.
End States for Integrating Windows and UNIX
The first key step in a comprehensive identity and access management strategy is to consolidate— to the greatest extent possible—divergent identity stores into a single, centralized store. Ideally, UNIX-based computers can use the same identity store as Windows—namely, Active Directory—for both authentication and authorization. Alternatively, UNIX-based computers can use Active Directory for authentication only.
By integrating UNIX system authentication and authorization information into Active Directory, you put the foundation in place for a more comprehensive integration of all applications into a single identity and access management scheme. Although the scope of this guide is restricted to solving the basic authentication and authorization requirement for UNIX-based computers, how to extend your identity and access management strategy is discussed in the section (for the Quest Software VAS product or the Centrify DirectControl product) or chapter (for the custom solutions) about evolving each solution beyond this basic implementation.
This section summarizes:
Five end state options
Technology solutions available for each end state
Five End State Options
The five end states described in this guide represent possible options for enabling interoperability between UNIX and Windows computers in a mixed network environment. You can configure interoperability either at the level of authentication only or at the level of both authentication and authorization.
End States 1–4 are integrated solutions in which the account for each UNIX user is migrated to Active Directory using any of four combinations of authentication and authorization options. For End State 5, the Windows and UNIX environments remain separate but are connected by a cross-realm trust that enables authentication between the UNIX and Windows realms. For End State 5, when authentication occurs, if the trust is a two-way trust, each client is trusted by workstations and servers hosting network resources in the other environment. UNIX user accounts continue to be stored in the UNIX KDC. Authorization is not a factor in End State 5.
The following figure depicts the authentication and authorization options by end state.
.gif)
Figure 1.3. End states vary by how they use Active Directory authentication and authorization.
Although these five end states are described independently of each other in this guide, the appropriate solution for your organization might be to use more than one end state solution. Depending on your networking environment, it might be appropriate to:
Deploy one end state throughout your entire organization.
Deploy one end state in part of your organization.
Deploy more than one end state in different parts of your organization. For example, one typical combination might be to deploy both an End State 2 solution and an End State 5 solution.
The following sections briefly describe each of the end states included in this guide.
End State 1: Use Active Directory Kerberos to Authenticate UNIX Clients
End State 1 introduces the use of Active Directory as a Kerberos KDC to store authentication data for users on both UNIX and Windows computers. However, an End State 1 solution continues to rely on your existing UNIX-based source, such as the local /etc/passwd and /etc/group files, iPlanet, or NIS, to store authorization data for UNIX users.
Using Active Directory Kerberos authentication for both Windows and UNIX clients lets users log on securely to either UNIX or Windows hosts with a single user name and password. An authenticated UNIX user, like an authenticated Windows user, can access Kerberized applications (applications that use Kerberos for authentication) without being prompted again to provide a user name or password.
With an End State 1 solution, Windows and UNIX clients both authenticate to the Kerberos KDC on Active Directory, but the logon process is not completely identical:
Windows Active Directory Kerberos logon. The Windows client requests a TGT from the AS component of the Active Directory KDC. When the AS returns a TGT to the Windows client, the TGT includes the Windows PAC in the Kerberos v5 authorization data field of the Kerberos ticket.
UNIX Active Directory Kerberos logon. The UNIX client requests a TGT from the AS component of the Active Directory KDC. In this case, when the AS returns a TGT to the UNIX client, it includes the Windows PAC and authorization data, but most UNIX implementations cannot make use of it. Instead, the UNIX client retrieves authorization data from Active Directory by making a series of LDAP calls.
For a more detailed description of this process, see "Example: Kerberos and LDAP in a Mixed Environment" earlier in this chapter.
Consolidating Windows and UNIX authentication data storage in Active Directory eliminates the need for separate administration of authentication data on the UNIX side. However, typically, in an End State 1 solution, you cannot retire UNIX-based computers currently used for storing authentication data because in most cases these computers also store authorization data. LDAP, NIS, and /etc/passwd stores typically store not only passwords (authentication data) but also store UIDs and GIDs (authorization data). In addition, these computers might also be used for authentication by UNIX-based computers not included in the End State 1 solution.
Maintaining two authorization data stores—one for UNIX users and another for Windows users—incurs extra administrative overhead. However, your organization might prefer to maintain two authorization data stores for one or more of the following reasons:
If your UNIX infrastructure includes applications that require a UNIX-based authorization store. For example, if you have an existing legacy system such as iPlanet and do not want to migrate authorization data to Active Directory yet.
If you have a sophisticated infrastructure already in place to manage authorization on UNIX-based computers.
If you want to minimize risk by changing only one element of security at a time. In this case, you might find it appropriate to migrate to an End State 2 solution later after confirming that the End State 1 solution functions well and operates securely.
End State 1 is appropriate for an organization with an existing UNIX infrastructure where you want to migrate to Active Directory authentication data that is currently maintained in any type of UNIX-based authentication data store, such as in local files, on a UNIX-based Kerberos server, or in NIS, but it is impractical or not possible to migrate authorization data to Active Directory.
End State 1 Example
In this example, an organization currently uses NIS to store both authentication and authorization data for UNIX users. They want to centralize administration of authentication data for both Windows and UNIX users in Active Directory while maintaining the existing NIS infrastructure to store UNIX authorization data. They also want to provide users with a single user name and password to access both UNIX-based and Windows-based computers on their network.
This organization plans to migrate authorization data to Active Directory in the future, but they want to make the change one step at a time.
.gif)
Figure 1.4. End State 1: UNIX clients using Active Directory Kerberos for authentication and UNIX-based NIS for authorization
End State 2: Use Active Directory Kerberos to Authenticate and Active Directory LDAP to Authorize UNIX Clients
The use of the Kerberos protocol and LDAP in conjunction with each other is integral to the Windows security model. To take full advantage of the authentication and authorization support that Active Directory can extend to UNIX users, the ideal interoperability solution includes:
UNIX clients authenticate to Active Directory Kerberos v5.
UNIX clients use Active Directory LDAP v3 for authorization.
End State 2 introduces the use of Active Directory to store both authentication and authorization data for UNIX users, replacing existing UNIX-based authentication and authorization storage methods. With an End State 2 solution, authentication data for UNIX users is migrated to the Active Directory Kerberos KDC so that UNIX clients can authenticate to the Active Directory KDC. Authorization data for UNIX users is migrated to the Active Directory LDAP data store so that UNIX clients can use Active Directory LDAP for authorization. Using both Active Directory Kerberos and Active Directory LDAP enables UNIX clients to take full advantage of Windows authentication and authorization security mechanisms.
Storing UNIX authentication data in Active Directory allows users to log on securely to either UNIX or Windows hosts with a single user name and password. An authenticated UNIX user, like an authenticated Windows user, can access Kerberized applications without being prompted again to provide a user name or password.
Consolidating Windows and UNIX authentication and authorization data in Active Directory eliminates the need for separate administration of authentication and authorization data on the UNIX side. You can retire UNIX-based computers currently used for storing authentication and authorization data or reallocate them for other use.
Like End State 1, with End State 2, Windows and UNIX clients both authenticate to the Kerberos KDC on Active Directory, but the logon process is not completely identical:
Windows Active Directory Kerberos logon. The Windows client requests a TGT from the AS component of the Active Directory KDC. When the AS returns a TGT to the Windows client, the TGT includes the Windows PAC in the Kerberos v5 authorization data field of the Kerberos ticket.
UNIX Active Directory Kerberos logon. The UNIX client requests a TGT from the AS component of the Active Directory KDC. In this case, when the AS returns a TGT to the UNIX client, it does include the Windows PAC and authorization data, but most UNIX implementations cannot make use of it. Instead, the UNIX client retrieves authorization data from Active Directory by making a series of LDAP calls.
For a more detailed description of this process, see "Example: Kerberos and LDAP in a Mixed Environment" earlier in this chapter.
When you use Active Directory as the LDAP store for one of the custom End State 2 solutions in this guide, you must either extend the Active Directory schema to include UNIX-specific attributes (for versions of Windows earlier than Windows Server 2003 R2), or you must install or upgrade to Windows Server 2003 R2.
The two commercial End State 2 solutions included in this guide handle UNIX attributes for UNIX users whose accounts have been migrated to Active Directory in the following ways:
Quest Software VAS product:
Provides its own RFC 2307-compliant schema extension.
Provides the VAS UNIX Personality Management (UPM) feature. UPM solves the UNIX attribute problem in a different way than the VAS schema extension by enabling VAS to manage UNIX user attributes through defining "Personalities" (alternative identities) that the user can assume when logging on to different UNIX-based computers. Even though UNIX users can have multiple UNIX personalities, they have only one underlying identity—the Active Directory user account.
Supports the use of Windows Services for UNIX schema extensions for storing UNIX user attributes in Active Directory.
Supports Windows Server 2003 R2, which includes support for RFC 2307 as part of its default installation. The VAS solution described in this guide was not tested with Windows Server 2003 R2.
Centrify DirectControl product:
Provides its own method for solving the UNIX attribute problem through its use of zones. DirectControl zones make use of the Active Directory feature that allows applications to store data in Active Directory under the Program Data container hierarchy. UNIX users can be associated with multiple UNIX identities in numerous zones, if required, even though they have only one underlying identity—the Active Directory user account.
Supports the use of Windows Services for UNIX schema extensions for storing UNIX user attributes in Active Directory.
Supports Windows Server 2003 R2, which includes support for RFC 2307 as part of its default installation. The DirectControl solution in this guide was not tested with Windows Server 2003 R2.
End State 2 is appropriate for organizations that want to simplify administration, retire UNIX authentication and authorization data stores, take advantage of Active Directory Kerberos, and provide users with a single user name and password for logon to both Windows-based and UNIX-based computers.
End State 2 Example
In this example, an organization currently uses NIS to store authentication and authorization data for UNIX users. They want to retire existing user data storage systems and use Active Directory to store both authentication and authorization data. They also want to provide users with a single user name and password to access UNIX-based or Windows-based computers on their networks. The added security of Kerberized authentication with single sign-on to applications using Kerberos credentials also interests them.
.gif)
Figure 1.5. End State 2: UNIX clients using Active Directory Kerberos for authentication and Active Directory LDAP for authorization
End State 3: Use Active Directory LDAP to Authenticate UNIX Clients
In End State 3, Windows clients continue to use the Kerberos KDC on Active Directory, which is the default Windows method for storing authentication data. However, in an End State 3 solution, UNIX clients do not use Active Directory Kerberos for authentication. Although Kerberos v5 is the default method used for authentication in an Active Directory–based network, it is also possible to use Active Directory LDAP for authentication, and End State 3 introduces the use of Active Directory LDAP to store authentication data for UNIX clients. End State 3 continues to rely on your existing UNIX-based source, such as the local etc/passwd and /etc/group files, iPlanet, or NIS, to store authorization data for UNIX clients.
Centralizing Windows and UNIX authentication data storage in Active Directory allows users to log on to either UNIX or Windows hosts with a single user name and password. However, with End State 3, users do not get the single sign-on benefits provided by Kerberos authentication for applications: Users logged on to UNIX clients must provide their user name and password each time they want to access a Kerberized application (or any application that requires authentication) because End State 3 uses LDAP instead of Kerberos for authentication.
Consolidating Windows and UNIX authentication data storage in Active Directory eliminates the need for separate administration of authentication data on the UNIX side. Typically, in an End State 3 solution, you cannot retire or reallocate UNIX-based computers currently used for authentication data storage for other use because, in most cases, these computers also store authorization data or are used for authentication by UNIX-based computers not included in the End State 3 solution.
As with End State 1, in End State 3 maintaining two authorization data stores—one for UNIX users and another for Windows users—incurs extra administrative overhead. However, your organization might prefer to maintain two authorization data stores for one or more of the following reasons:
If your UNIX infrastructure includes applications that require a UNIX-based authorization store. For example, if you have an existing legacy system such as iPlanet and do not want to migrate authorization data to Active Directory yet.
If you have a sophisticated infrastructure already in place to manage authorization on UNIX-based computers.
If you want to minimize risk by changing only one element of security at a time. In this case, you might find it appropriate to migrate to an End State 4 solution later after confirming that the End State 3 solution functions well and operates securely.
End State 3 is appropriate for an organization with an existing UNIX infrastructure where the authentication data is currently stored in a UNIX-based LDAP database, where it is impractical or not possible to migrate from UNIX-based LDAP authentication to Active Directory–based Kerberos authentication, and where it is impractical or not possible to migrate authorization data to Active Directory. This includes customers who have extensive, complex, and rich multiplatform authorization infrastructures in place that they want to maintain but who do want to move toward a single identity and single point of authentication.
End State 3 is also appropriate for custom UNIX systems that have a unique authorization environment but want centralized authentication. For example, a Linux-based cash register has no file system and thus does not make standard authorization decisions, but it does need to authenticate cashiers. An organization whose environment includes a small-footprint device such as this might find that using LDAP for authentication meets its needs.
End State 3 Example
In this example, an organization uses a tool that they developed in-house to centrally build and distribute /etc/passwd files to all of its UNIX clients. These files are constructed on a nightly basis to control the computers to which individual users have access. The in-house tool is tightly coupled to other internal business systems and processes. The customer wants to move to a centralized authentication environment to reduce the cost of password-related help desk calls. While all of their computer systems support LDAP authentication, some clients do not support Kerberos.
Adopting an End State 3 solution enables users to have the same user name and password on all computers, centralizing administration and reducing help desk costs; it allows the organization to continue to use the tightly coupled authorization systems (which, in this example, use the default UNIX /etc/passwd and /etc/group files for storing authorization data) that it depends upon today.
.gif)
Figure 1.6. End State 3: UNIX clients using Active Directory LDAP for authentication and UNIX /etc/passwd and /etc/group files for authorization
End State 4: Use Active Directory LDAP to Authenticate and Authorize UNIX Clients
End State 4 introduces the use of Active Directory LDAP to store both authentication and authorization data for UNIX clients. End State 4 is similar to End State 2 in that both end states replace UNIX-based authentication and authorization methods with the use of Active Directory to provide both authentication and authorization for UNIX users. However, unlike End State 2, which uses Active Directory as a Kerberos KDC for authentication and Active Directory LDAP to handle authorization, End State 4 uses Active Directory LDAP for both authentication and authorization.
Centralizing Windows and UNIX authentication data storage in Active Directory allows users to log on to either UNIX or Windows hosts with a single user name and password. However, with End State 4, users do not get the single sign-on benefits provided by Kerberos authentication for applications: Users logged on to UNIX clients must provide their user name and password each time they want to access a Kerberized application (or any application that requires authentication) because End State 4 uses LDAP instead of Kerberos for authentication.
Consolidating Windows and UNIX authentication and authorization data in Active Directory eliminates the need for separate administration of authentication and authorization data on the UNIX side. You can retire UNIX-based computers currently used for storing authentication and authorization data or reallocate them for other use.
End State 4 is appropriate for an organization with an existing UNIX infrastructure that currently stores both authentication and authorization data in a UNIX-based LDAP database, wants to move both types of UNIX data into Active Directory, but finds it impractical or not possible to migrate from UNIX-based LDAP authentication to Active Directory–based Kerberos authentication.
End State 4 might also be appropriate for an organization that has standardized on LDAP or does not want to maintain a dual Kerberos/LDAP stack on every UNIX client. In addition, End State 4 is appropriate for customers with computers for which Kerberos is unavailable; adopting LDAP enables a single authentication mechanism for all of their resources.
End State 4 Example
In this example, an organization currently uses a UNIX-based LDAP directory for both authentication and authorization data for UNIX users. The organization wants to consolidate this information to reduce infrastructure costs and to let users use the same user names and passwords on both Windows and UNIX-based computers.
.gif)
Figure 1.7. End State 4: UNIX clients using Active Directory LDAP for both authentication and authorization
End State 5: Create a Cross-Realm Trust Between UNIX and Windows KDCs
End State 5, unlike End States 1–4, continues to use your existing UNIX and Windows infrastructures but establishes interoperability between UNIX-based Kerberos (such as MIT Kerberos) and Active Directory–based Kerberos by deploying a cross-realm trust. Windows clients and UNIX clients each authenticate to their own KDC and, if the trust is a two-way trust, are then trusted by workstations and servers hosting network resources on the other side.
UNIX users, when authenticated to the UNIX KDC, can access services (applications) in the Windows environment without having to reauthenticate. The Windows KDC trusts the UNIX KDC's authentication credentials and so grants access to Windows services to UNIX users without reprompting the user for authentication. You can configure the trust to be one-way (the Windows KDC trusts the UNIX KDC but the UNIX KDC does not trust the Windows KDC, or vice versa) or two-way (each KDC trusts the other).
End State 5 requires minimal infrastructure modification yet enables both Windows users and UNIX users to access Kerberized applications in either environment without being prompted repeatedly for user name and password. With End State 5, authorization is not a factor, so you continue to use your existing UNIX-based authorization method for UNIX users.
End State 5 is appropriate for an organization with an existing UNIX-based Kerberos infrastructure where it is impractical or not possible to make extensive changes to that infrastructure.
End State 5 Example
In this example, an organization has a network that includes a UNIX-based Kerberos environment and a separate Active Directory environment, which uses Kerberos authentication by default. In this case, the network has Kerberized applications in each environment that administrators want to make available to users from either side without requiring users to retype their user names and passwords.
.gif)
Figure 1.8. End State 5: UNIX and Windows clients using a two-way cross-realm trust to authenticate to Kerberized applications in the opposite realm
Technology Solutions Available for Each End State
The technology solutions presented in later chapters in this guide represent possible alternatives for deploying the end state—the authentication and authorization choices—that you decide to implement.
More than one approach is available to achieve the various end states. This guide includes the following technology solution categories:
Commercial. Commercially available products that you can buy.
Custom , or do-it-yourself , solutions:
Native OS solutions. You can develop a solution that uses only components of the native UNIX or Linux operating system. These solutions are referred to in this guide as the "native OS" solutions.
Open source solutions. You can implement a solution that uses the native operating system as a foundation but adds Kerberos and LDAP components and tools, which are available as open source software and free downloads from third parties. These solutions are referred to in this guide as the "open source" solutions.
The following table maps the technology solutions described in this guide to the five end states.
Table 1.5. Technology Solutions Available for Each End State
1st Decision: End State |
2nd Decision: Types of Technology Solution |
|---|---|
End State 1 |
|
End State 2 |
|
End State 3 |
|
End State 4 |
|
End State 5 |
|
Both the native OS and the open source custom scenarios described for each end state in this guide include two alternative solutions: one for the Solaris 9 version of UNIX and another for the Red Hat 9 version of Linux.
CAUTION We do not recommend deploying the native OS Red Hat 9 solution in your production environment because of the security risks inherent in this solution. For more information, see the discussion in the section "Use Red Hat 9 with Native OS Components for End States 1 and 2" in Volume 2: Chapter 4, "Developing a Custom Solution." (This limitation does not apply to the open source Red Hat solution or to either the native OS or open source Solaris solution.)
For information about choosing the appropriate technology solution for your organization, see Volume 2: Chapter 1, "Choosing the Right Technology and Planning Your Solution" in this guide.
For More Information
Overview of both UNIX and Windows:
- Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization" in this guide.
Documentation about the commercial solutions described in this guide:
"DirectControl White Papers and Datasheets" on the Web site for the Centrify DirectControl product at https://www.centrify.com/directcontrol/whitepapers.asp.
"Vintela Authentication Services Documentation" on the Web site for the Quest Software VAS product at https://www.vintela.com/support/docs/vas/.
Active Directory:
"Access Control in Active Directory" in Windows Server 2003 Help and Support Center.
"Active Directory Users, Computers, and Groups" white paper at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/adusers.mspx.
"How Active Directory Searches Work" in Windows Server 2003 Technical Reference at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/8196d68e-776a-4bbc-99a6-d8c19f36ded4.mspx.
"How the Data Store Works" in Windows Server 2003 Technical Reference at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/54094485-71f6-4be8-8ebf-faa45bc5db4c.mspx.
"Active Directory Architecture" at https://go.microsoft.com/fwlink/?LinkId=51956.
Identity and access management:
Microsoft Identity and Access Management Series available at https://go.microsoft.com/fwlink/?LinkId=14841. This series of articles provides detailed, Windows-specific information about:
Directory services
Identity life cycle management
Authentication
Authorization
Aggregation and synchronization
Trust
Auditing
Applications
Provisioning and Deprovisioning
”Integrating UNIX Systems with Active Directory for Authorization and Authentication (Level 200)," talk by Jason Zions, Microsoft Corporation, available at https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032268756&EventCategory=3&culture=en-US&CountryCode=US.
Kerberos:
RFC 1510, "The Kerberos Network Authentication Service (Version 5)" at https://www.ietf.org/rfc/rfc1510.txt.
RFC 1964, "The Kerberos Version 5 GSS-API Mechanism" at https://www.ietf.org/rfc/rfc1964.txt.
RFC 3244, "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" at https://www.ietf.org/rfc/rfc3244.txt.
Kerberos: The Definitive Guide, by Jason Garman. O'Reilly Media, 2003.
"Using Encryption for Authentication in Large Networks of Computers," by Roger M. Needham and Michael D. Schroder. ACM Press, 1978).
*"*Kerberos Authentication and Authorization System," by S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Salzer. MIT Project Athena, 1988.
The MIT Kerberos Web site at https://web.mit.edu/kerberos/www/.
The Heimdal Web site at https://www.pdc.kth.se/heimdal/.
"Kerberos Authentication Technical Reference" in Windows Server 2003 Technical Reference at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/b748fb3f-dbf0-4b01-9b22-be14a8b4ae10.mspx.
"Security Services Technical Reference Topics" in Windows Server 2003 Technical Reference at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/techref/gensec.mspx.
"Microsoft Kerberos" in the MSDN Library at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthn/security/microsoft_kerberos.asp.
LDAP:
RFC 1777 (LDAP v2).
RFC 3377 (summarizes a series of RFCs that define LDAP v3).
LDAP System Administration, by Gerald Carter. O'Reilly Media, 2003.
The OpenLDAP Web site at https://www.openldap.org.
Understanding and Deploying LDAP Directory Services, by Mark C. Smith, Gordon S. Good, Timothy A. Howes. Macmillan Technical Publications, December, 1998.
"LDAP Authentication" at https://java.sun.com/products/jndi/tutorial/ldap/security/ldap.html.
"Authentication Mechanisms" (for LDAP) at https://java.sun.com/products/jndi/tutorial/ldap/security/auth.html.
Pluggable authentication modules (PAM):
Solaris 9 at https://www.sun.com/software/solaris/pam.
RedHat 9 at* *https://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/ch-pam.html.
General Linux information at https://www.kernel.org/pub/linux/libs/pam.
For information about existing UNIX applications that are PAM enabled, see the Linux Kernel Archives’ PAM Modules Web site at https://www.kernel.org/pub/linux/libs/pam/modules.html.
For information about writing applications that can use the services provided by PAM, see PAM developer documentation, including:
The Linux-PAM Module Writers' Guide at https://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_modules.html.
O’Reilly’s Writing PAM-Capable Applications at https://www.linuxdevcenter.com/pub/a/linux/2002/04/04/PamModules.html.
Public Key Infrastructure (PKI):
Windows Server 2003 Public Key at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/pubkey.mspx.
IETF standards for Public-Key Infrastructure (X.509) (pkix) at https://go.microsoft.com/fwlink/?LinkId=124.
"Certificate Services" in Help and Support Center for Windows Server 2003.
"Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services in the Windows Server 2003 Resource Kit at https://go.microsoft.com/fwlink/?LinkId=4719.
Download
Get the Windows Security and Directory Services for UNIX Guide
Update Notifications
Sign up to learn about updates and new releases
Feedback