Appendix A: Architectural Overview of UNIX and Windows Authentication and Authorization

On This Page

UNIX Authentication and Authorization
Microsoft Windows Server 2003 Kerberos
Microsoft Active Directory Directory Service
Windows Server 2003 LDAP Implementation
Common Uses of Directory Services

UNIX Authentication and Authorization

The UNIX operating system was originally developed to operate on a centralized computer with terminals connected to it by serial lines. Over the years, it has evolved into the networked operating system that it is today. Linux is derived from UNIX and has evolved alongside UNIX over recent years. This section looks at the methods of authorization and authentication used in UNIX and Linux. Several technologies are used in UNIX environments to provide authentication and authorization services. One or more of these technologies may be used in the same environment. The common technologies are summarized in Table A.1.

Table A.1. UNIX and Linux Authentication and Authorization Technologies

	Local Files	NIS	NIS+	Kerberos	LDAP
Domain Structure	Single realm	Flat multiple realm	Hierarchical	Non-hierarchical multiple realm	Hierarchical
Data Store	Flat files	Two-column tables	Multiple-column tables	Kerberos database	Various indexed databases
Server Types	N/A	Master, slave	Root master, master, replica	Master, subordinate	Master, replica, or multimaster, replica
Encryption	Password field only	Password field only	Optional full encryption	Encryption	Choice of methods available
Network Protocol	N/A	TCP/IP Local LAN	TCP/IP	TCP/IP	TCP/IP
Scope	Local computer	Local LAN	Has issues with global operation	Global	Global
Platform	UNIX/Linux	UNIX/Linux	UNIX and Linux support incomplete	Platform-independent	Platform-independent
Extensible security mechanisms	No	No	No	Yes	Yes

The following topics provide further details about several of these technologies and the mechanisms that make use of them:

• Local, file-based, identity stores

• LDAP as an identity store

• Pluggable authentication module (PAM).

  Pluggable authentication modules are one method by which authentication data is accessed. They provide the link between the user and one or more authentication data stores.

• Name service switch (NSS)

  Name service switch (NSS) is similarly a method by which authorization data is accessed from one or more authorization data stores.

For more information about the use of Kerberos by the Active Directory® directory service, see the “Microsoft® Windows Server 2003 Kerberos” section later in this appendix.

Local, File-based Identity Stores

Historically, the UNIX and Linux operating systems have stored authentication and authorization information in text files. These files, along with a large selection of other system configuration files, are located in the /etc directory. The ultimate source of user account information is the /etc/passwd file. On a system with no other authentication sources, this file contains entries for all users of the system. Even on systems augmented by some of the authentication methods listed in Table A.1, this file is still essential for the correct operation of the system. Each entry occupies a single line and is a list of fields separated by colons that takes the following form:

account:password:UID:GID:GECOS:directory:shell

These fields are explained in Table A.2.

Table A.2. Standard Fields for UNIX and Linux passwd Files

Field Name	Description
account	The unique name of the user on the system. Lowercase only.
password	The encrypted password of the user. On most UNIX and Linux implementations, this field contains an asterisk character (*) and the password is actually stored in the /etc/shadow file.
UID	The user identification number. The UID is represented either by a 16-bit or 32-bit integer. Because of the historical use of 16-bit integers for representing UIDs, the maximum UID number on some systems is 65356.
GID	The group identification number. The GID is represented either by a 16-bit or 32-bit integer. Because of the historical use of 16-bit integers for representing GIDs, the maximum GID number on some systems is 65356.
GECOS	The General Electric Comprehensive Operating System field. The name of this field is historical. This field is usually used for the full name of the user or for a comment.
directory	The home directory for the user. This is the directory in which the user process is placed at logon.
shell	The logon shell for the user. Shell is the term used to describe the command-line user interfaces on UNIX and Linux operating systems. This is set to the path of the binary for the user's logon shell. Defaults to /bin/sh (the Bourne shell). Can be set to /bin/false to disable logons.

An example of a typical line from a password file looks like this:

mike:Dli3iI6FUk7bs:512:45:Michael Allen:/home/mike:/etc/sh

The shadow password file, /etc/shadow, was developed to improve security of the encrypted UNIX or Linux passwords. Because the /etc/passwd file contains the information required by user programs to map user names to UID numbers, it must be world-readable. However, this makes the password field of the passwd file available to be read by all users; and while the encryption algorithms used are irreversible, it is quite straightforward to carry out a brute force attack to guess the passwords if the encrypted form of the password is available. This problem is resolved by removing the encrypted password from /etc/passwd and storing it in the shadow password file, /etc/shadow, which can only be read by the system superuser (root).

The /etc/passwd and /etc/shadow files provide the authentication information for the system. The authorization on the UNIX and Linux systems using local files is provided at the individual file level, with permissions being set on files, directories, and programs.

Group information is held in the /etc/group file and is referenced in the passwd file by the GID field. Groups are defined by a line in this file, with fields separated by colons as follows:

Groupname:Password:GID:User list

These fields are explained in Table A.3. In UNIX and Linux, it is not possible to make a group a member of another group.

Table A.3. Description of Fields in UNIX Group File

Field	Description
Groupname	The name for the group.
Password	This field is no longer in common use. It is usually left empty or is set to a common value such as "X" indicating that there is no group password.
GID	The numeric identification for the group.
User list	A list of users who are members of the group in addition to the users that specify the group as their default group in /etc/passwd. The list of users consists of user names separated by commas.

Each file and program has a user owner and a group owner. The permissions on the file or directory define who is authorized to carry out the three types of operation: read, write, or execute, as Table A.4 shows.

Table A.4. UNIX File Operations

Representation	Operation	Description
r	Read	Permission to view the file or list the contents of a directory.
w	Write	Permission to modify the file or the contents of a directory.
x	Execute	Permission to run the file or to access a directory.

These permissions are assigned to each of three groups of potential users of the file—the user owner of the file, members of the group that is the group owner of the file, and all other users.

Displaying the current permissions of a file is possible by using the ls command with the –l switch, which produces a long form of the list of files.

-rw-rw-r--    1 mike       devel           6581 Oct  5 20:43 project.tar
drwx------    4 mike       devel           4096 Aug 15 12:22 project
drwxr-xr-x    7 mike       devel           4096 Jul 28 18:06 www 

This example shows one file and two directories owned by the user “mike” and the group “devel.” The directories are distinguishable by the leading d in the permissions string. The permissions are detailed in Table A.5.

Table A.5. File Permission Example

File	Directory	User	Group	Other
project.tar	-	r w -	r w -	r - -
project	d	r w x	- - -	- - -
www	d	r w x	r – x	r - x

The project.tar file has permissions set so that the user owner (mike) can read and write to it, members of the group owner (devel) can read and write to it, and everyone else is able to read the file. The project directory has permissions set so that only the user owner is able to list the contents of the directory, create a new file in the directory, delete a file in the directory, or change (move) from the current working directory to the project directory. In contrast, the www directory is set so that everyone can read and change into the directory, but only the user owner can create or delete files in it. These file permissions define the authorization within the file system. Because of the way that UNIX handles devices as files, users can easily be restricted from using a certain device by ensuring that the permissions are set correctly.

LDAP as an Identity Store

Each of the methods of storing system information on UNIX and Linux systems has limitations; examples of which are given below:

• Local files do not allow you to implement network-wide centralized administration.

• DNS is not a generic service and only supports network information.

• NIS and NIS+ are specific to UNIX and Linux and do not easily allow you to implement cross-platform integration.

LDAP solves all of these problems (and others). Using LDAP as a naming service on UNIX and Linux systems provides the following advantages:

• LDAP allows you to consolidate information by replacing system-specific and application-specific databases with one directory.

• LDAP makes possible efficient data synchronization between masters and replicas.

• LDAP is an open standard that is compatible with many platforms and vendors.

On UNIX and Linux, stored LDAP configuration and system information can be retrieved after the LDAP NSS module (nss_ldap) has been installed and configured. The /etc/nsswitch.conf file is configured to use LDAP when the LDAP NSS module has been installed and configured by adding the ldap service to configuration lines.

The three lines here show the user and group databases configured to use the NSS LDAP service:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

Because LDAP is a generic directory service, it is necessary to extend the standard schemas to store the objects and attributes required to hold UNIX and Linux system information. Typically, the schema used to hold UNIX and Linux system information will also be capable of holding information for the major system information databases, some of your organization's custom-made databases, and databases used by applications (including, for example, e-mail).

Some standard schemas provided with LDAP may already contain entities that UNIX and Linux servers need to be able to access. However, these entities may not contain the attributes required by UNIX and Linux. For example, the object class person is used to store basic information about an individual, but it does not contain attributes required by UNIX or Linux, such as the individual’s UID number or GID number. The object class organizationalPerson is derived from the person object class. But organizationalPerson does not contain many UNIX or Linux attributes. The inetOrgPerson object class is derived from the organizationalPerson object class, but this also does not contain attributes necessary for use with UNIX and Linux.

Although the object classes person, organizationalPerson, and inetOrgPerson do not contain all the user attributes required by UNIX or Linux, they do illustrate the fact that the LDAP schema can be extended by creating new object classes based upon existing ones. Because none of these three object classes contain the full set of UNIX or Linux attributes required to store the information stored in the /etc/passwd and /etc/shadow files, it is necessary to extend the schema. Because extending the schema builds on those attributes that already exist, any information about an individual already stored in the LDAP database and in use by other applications or operating systems will continue to be used as before, and this information is consolidated with the individual's UNIX or Linux attributes.

Extending the LDAP schema is not restricted to object classes describing individuals; it can also be applied to all other system information. In some cases, new object classes are required that will only be used by UNIX or Linux systems and have no application elsewhere. In other cases, such as groups and printers, UNIX or Linux information about these objects could be consolidated with information from other platforms or applications.

This guide provides solutions based on the Active Directory schema and the Active Directory schema extended using Windows Services for UNIX 3.5. The tools and techniques covered in this guide enable you to use other schemas, including custom schemas and the schema described in RFC 2307, “An Approach for Using LDAP as a Network Information Service.”

The RFC 2307 LDAP Schema

The RFC 2307 LDAP schema is a relatively new schema that is currently at an experimental status. There is also an update to RFC 2307, called RFC 2307bis that is currently in development. Despite the current state of its development, it has been implemented in products from a variety of vendors, including PADL, Red Hat, Apple Computers, and most UNIX vendors. RFC 2307 was authored by PADL to standardize a schema that contains the object classes and attributes necessary to replace NIS with LDAP.

The RFC 2307 schema is intended for use in two common scenarios:

• As a direct replacement for NIS. UNIX and Linux clients access LDAP directly. This is the scenario implemented in PADL's LDAP modules.

• In NIS-to-LDAP gateways. UNIX and Linux clients still use the NIS protocol, but the NIS server stores its data in an LDAP directory. This scenario is implemented in NIS gateways from various vendors, including PADL. The same functionality is provided by Microsoft using Microsoft Server for NIS.

The PADL modules covered in this guide can be configured to use most schemas even though the PADL modules use RFC 2307 internally. Therefore, the PADL modules can use both the default schemas provided with Active Directory and the extended schemas provided as a part of Windows Services for UNIX 3.5.

Pluggable Authentication Modules

The /etc/passwd and /etc/shadow files can be used for authentication and authorization on some versions of UNIX and Linux systems. For UNIX and Linux systems to use other methods of authentication, the pluggable authentication module (PAM) service was developed. PAM provides a standard method for configuring authentication systems on UNIX and Linux operating systems. Different PAM modules can be used to provide different methods of authenticating a user and obtaining account information from the standard local account files.

Conventional UNIX and Linux users log on by supplying a unique user name and a password. The user name and password are compared with those stored in the /etc/passwd and /etc/shadow files. PAM allows the user name and password information to be stored in many different places and ways. PAM also allows 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 all tools that require user authentication can be compiled to use PAM for authentication and authorization. To support these, PAM must then be configured to correctly handle the different authentication methods allowed on a particular system.

PAM is configured either with the /etc/pam.conf file or with the files contained in the /etc/pam.d directory. In the /etc/pam.conf file, each line contains fields specifying the behavior of a specific service, and each service often has more than one line to allow for fine levels of control. In the /etc/pam.d directory, there are files defining the behavior of the service—one file for each service—with the file name specifying which service it relates to.

One important feature of the PAM configuration files is that rules defining the behavior of the PAM modules may be stacked to combine the features of different PAM modules for a specific task. For example, several password entries can be stacked so that a valid password could be one that is found in /etc/passwd, /etc/shadow, or an LDAP server.

There are four independent management groups within PAM. These are:

• Account. This management group provides services for checking the validity of the account, for example, by checking if the password has expired and by confirming that the user is permitted access to the service.

• Authentication. This management group authenticates the user using a chosen authentication mechanism. The mechanism can be a simple challenge-response mechanism, such as entering a password, or the mechanism can be based on authentication hardware, such as retina scans or smart card readers.

• Password. This management group provides methods for keeping the authentication mechanism up-to-date. In the simplest case, this makes it possible for users to change their passwords. On UNIX and Linux, changing the password is implemented by using the passwd command or, for Kerberos, the kpasswd command. The kpasswd command does not make use of PAM.

• Session. This management group provides the facility to define tasks that need to take place prior to a service being granted and after it is withdrawn. It can be used for auditing.

Name Service Switch

To ease the use of different methods of providing UNIX and Linux configuration information, the name service switch (NSS) architecture was developed. This modular architecture defines an interface between the standard C programming function calls and a service module that implements the storage of UNIX information in a particular file, database system, or directory.

The name service switch can be used to redefine where UNIX and Linux obtain a wide range of configuration information. The databases typically supported by NSS are shown in Table A.6.

Table A.6. Name Service Switch Standard Supported Databases

Database	Description	Example C Function
aliases	Mail aliases used by sendmail. Presently ignored.	N/A
ethers	Hard-coded Ethernet MAC-to-IP address translations.	ether_ntohost()
group	User groups.	getgrent()
hosts	Defines the relationships between IP addresses and host names.	gethostbyname() or getipnodebyaddr()
netgroup	Network-wide list of hosts and users, used for access rules.	getnetgrent()
network	Network names and numbers.	getnetent()
passwd	The user account database.	getpwent()
protocols	Network protocols.	getprotoent()
publickey	Public and secret keys used by secure RPC.	getpublickey()
rpc	Remote procedure call names and numbers.	getrpcbyname()
services	Network services.	getservent()
shadow	Stores user password and account parameters.	getspnam()

NSS is configured through the /etc/nsswitch.conf file. Like other UNIX and Linux configuration files, nsswitch.conf is a text file with a configuration entry on each line. Lines beginning with a number symbol (#) are comments.

A configuration line begins with the name of the database suffixed with a colon, and it ends with a list of the methods used to resolve the database query or function. The methods listed for a specific entry are tried in turn from left to right.

For example, the standard user and group entries read:

passwd:     files
shadow:     files
group:      files

This example shows that the passwd, shadow, and group information are obtained from the standard files located in /etc. A more complex example is shown here:

passwd:    files nisplus nis
shadow:    files nisplus nis
group:     files nisplus nis

For each of the databases in this case, the operations are made first against the standard system files in /etc, and then by using the latest incarnation of the Network Information System (NIS+), and finally using standard NIS.

The NSS service methods available depend on the installation of shared library objects for a specific service. The services typically found on a UNIX or Linux system are shown in Table A.7.

Table A.7. Typical NSS Services

Service Name	Description
compat	Use with /etc/passwd, /etc/group, and /etc/shadow to support old style plus (+) and minus (-) notation.
db	Use local database files ending with the suffix .db.
dns	Use the Domain Name System (DNS).
files	Use local text configuration files, typically found under /etc.
hesiod	Use hesiod for lookups.
nis	Use the Network Information Service (NIS) for lookups.
nisplus	Use NIS+ for lookups.
ldap	Use for LDAP lookups.

Note   Not all services are available on all UNIX and Linux platforms. Also, not all services are capable of using all data source types. This is particularly true of the LDAP service.

Microsoft Windows Server 2003 Kerberos

The Kerberos implementation present in Microsoft® Windows Server™ 2003 has been developed based upon the standard described in RFC 1510, “The Kerberos Network Authentication Service version 5,” which defines Kerberos 5. This section describes the architecture and implementation of this solution.

Architecture

Windows Server 2003 implements the Key Distribution Center (KDC) as a domain service. It uses the domain’s Active Directory as its account database and gets some information about users from the global catalog.

As in other implementations of the Kerberos protocol, the KDC is a single process that provides two services:

• Authentication Service (AS). This service issues Ticket-Granting Tickets (TGTs) good for admission to the Ticket-Granting Service (TGS) in its domain. Before network clients can get tickets for services, they must get an initial TGT from the authentication service in the user’s account domain.

• Ticket-Granting Service (TGS). This service issues tickets good for admission to other services in its domain or to the Ticket-Granting Service of a trusted domain. When clients want access to a service, they must contact the TGS in the service’s account domain, present a TGT, and ask for a ticket. If the client does not have a TGT valid for admission to that Ticket-Granting Service, it must get one through a referral process that begins at the TGS in the user’s account domain and ends at the TGS in the service’s account domain.

The KDC is located on every domain controller, as is the Active Directory service. Both services are started automatically by the domain controller’s Local Security Authority (LSA) and run in the process space of the LSA. Neither service should be stopped, although the KDC service can be stopped using the command net stop kdc. Windows Server 2003 ensures availability of these services by allowing each domain to have several domain controllers, which are all peers. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain’s KDC.

The security principal name used by the KDC for a Windows Server 2003 domain is krbtgt, as specified by RFC 1510. An account for this security principal is created automatically when a new domain is created. The account cannot be deleted, and the name cannot be changed. A password is assigned to the account automatically. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGTs that it issues. The password for a domain trust account is used to derive an interrealm key for encrypting referral tickets.

All instances of the KDC within a domain use the domain account for the security principal krbtgt. Clients address messages to a domain’s KDC by including both the service principal name, krbtgt, and the name of the domain. Both items of information are also used in tickets to identify the issuing authority. For information on name forms and addressing conventions, see RFC 1510.

Account Database

The account database that the KDC needs to obtain information about security principals is provided by the domain’s Active Directory. Each principal is represented by an account object. The encryption key used in communicating with a user, computer, or service is stored as an attribute of that security principal’s account object.

Only domain controllers are Active Directory servers. Each domain controller keeps a writeable copy of the directory, so accounts can be created, passwords reset, and group membership modified at any domain controller. Changes made to one replica of the directory are automatically propagated to all other replicas. Windows Server 2003 does not, however, implement the Kerberos replication protocol. Instead, it replicates the information store for Active Directory using a proprietary multimaster replication protocol over a more secure channel between replication partners.

Physical storage of account data is managed by the Directory System Agent (DSA), a protected process integrated with the LSA on the domain controller. Clients of the directory service are never given direct access to the data store. Any client wanting access to directory information must use one of the supported Active Directory Service Interfaces (ADSI) to connect to the DSA, or LDAP, and then search for, read, and write directory objects and their attributes.

Requests to access an object or attribute in the directory are subject to validation by Windows Server 2003 access control mechanisms. Like file and folder objects in NTFS, objects in Active Directory are protected by access control lists (ACLs) that specify who can access the object and in what way. Unlike files and folders, however, Active Directory objects have an ACL for each of their attributes. Thus, attributes for sensitive account information can be protected by more restrictive permissions than those granted for other attributes of the account.

The most sensitive information about an account is, of course, its password. Although an account object’s password attribute stores an encryption key derived from a password, not the password itself, this key is just as useful to an intruder.

Warning   There is an option to use reversible encryption, which is disabled by default in Windows Server 2003. If this is enabled, it reduces the security of the object's password attribute. More information on reversible encryption is available in the "Store passwords using reversible encryption" article available at https://technet2.microsoft.com/WindowsServer/f/?en/Library/eeff044c-d4a8-4699-a4b8-c5e563118c931033.mspx.

Therefore, access to an account object’s password attribute is granted only to the account holder, never to anyone else, not even administrators. Only processes with Trusted Computer Base privilege—processes running in the security context of the LSA—are allowed to read or change password information.

In order to hinder an offline attack by someone with access to a domain controller’s backup tape, an account object’s password attribute is further protected by a second encryption using a system key. This encryption key may be stored on removable media so that it can be safeguarded separately or be stored on the domain controller but be protected by a dispersal mechanism. Administrators are given the option to choose where to store the system key and which of several algorithms to use to encrypt password attributes.

Kerberos Policy

In Windows Server 2003, Kerberos policy is defined in the default domain Group Policy object and implemented by the domain’s KDC. By default, the policy settings can be modified only by members of the Domain Admins security group. The elements of Kerberos policy are:

• Enforce user logon restrictions. This element determines whether the KDC validates every request for a service ticket against the user rights policy on the target computer. When this policy is enabled, the user requesting the service ticket must have the right either to Log on locally or to Access this computer from network. Validation of each request is optional because the extra step takes time and may slow network access to services. By default, this policy is enabled.

• Maximum lifetime for service ticket. This element determines the maximum amount of time (in minutes) that a ticket granted for a service (that is, a service ticket) can be used to access the service. If the setting is 0 minutes, the ticket never expires. Otherwise, the setting must be greater than 10 minutes and less than the setting for Maximum lifetime for user ticket. By default, the setting is 600 minutes (10 hours).

• Maximum lifetime for user ticket. This element determines the maximum amount of time (in hours) that a user’s TGT can be used. When a user’s TGT expires, a new one must be requested or the existing one must be renewed. By default, the setting is 10 hours.

• Maximum lifetime for user ticket renewal. This element determines the longest period of time (in days) that a TGT can be used if it is repeatedly renewed. By default, the setting is seven days.

• Maximum tolerance for computer clock synchronization. This element determines the maximum difference (in minutes) that Kerberos will tolerate between the time on a client’s clock and the time on a server’s clock while still considering the two clocks synchronous. By default, the setting is 5 minutes.

These policy settings define many of the settings that will affect the overall security of your solution.

Delegation of Authentication

In Windows 2000, a service can impersonate clients when accessing resources on the computer where the service process is running. In Windows Server 2003, a service can use the Kerberos protocol’s delegation feature to impersonate clients on other computers as well.

The following two conditions must be met:

• The client’s account must be enabled for delegation.

• The service’s account must be enabled for delegation.

Constrained delegation allows for delegation within a restricted context. This allows a service to delegate client credentials, with domain controllers exercising control when issuing the credentials. Thus, when service A requests Kerberos tickets for service B using delegated client credentials, the domain will consult a list to see if service A is allowed to delegate credentials to service B. In other words, the network administrator can control the scope of delegation. The specifics of constrained delegation are described in detail in the "Exploring S4U Kerberos Extensions in Windows Server 2003" article, available at https://msdn.microsoft.com/msdnmag/issues/03/04/securitybriefs/default.aspx.

This feature requires a Windows Server 2003 domain. The computer that initially receives the delegation request and the computer hosting the service must also be running Windows Server 2003.

Preauthentication

By default, the KDC requires all accounts to use preauthentication. This makes offline password-guessing attacks very difficult. Preauthentication can be disabled on an account to ensure compatibility with other Kerberos implementations.

Kerberos Security Support Provider

The Kerberos authentication protocol is implemented as a security support provider (SSP), which is a dynamic-link library supplied with the operating system. Windows Server 2003 includes an SSP for NTLM authentication as well. By default, both are loaded by the LSA on a Windows Server 2003-based computer when the system boots. Either SSP may be used to authenticate network logons and client/server connections. Which one is used depends on the capabilities of the computer on the other side of the connection. Kerberos authentication is generally preferred by Windows Server 2003 over NTLM authentication although there are situations where NTLM authentication is used for performance reasons.

After the LSA establishes a security context for an interactive user, another instance of the Kerberos SSP may be loaded by a process running in the user’s security context to support the cryptographic signing and sealing of messages.

System services and transport-level applications access SSPs through the Microsoft Security Support Provider Interface (SSPI). This is a Microsoft Win32® interface with methods for enumerating the providers available on a system, selecting one, and using it to obtain an authenticated connection. The methods in the SSPI are generic, black-box routines that developers can use without knowing the details of a particular protocol.

All distributed services in Windows Server 2003 use the SSPI to access the Kerberos SSP. A partial list of the ways in which the Kerberos protocol is used for authentication includes:

• Print spooler services.

• CIFS/SMB remote file access.

• LDAP queries to Active Directory

• Distributed file system management and referrals.

• IPSec host-to-host security authority authentication.

• Reservation requests for network Quality of Service (QOS).

• Intranet authentication to Internet Information Server.

• Remote server or workstation management using authenticated remote procedure calls (RPCs).

• Certificate requests to the Microsoft Certificate Server for domain users and computers.

Credentials Cache

On computers running Windows Server 2003, tickets and keys obtained from the KDC are stored in a credentials cache, which is an area of volatile memory protected by the LSA. The credentials cache is never paged to disk. All objects stored there are deleted when a security principal logs off or the system is shut down.

The credentials cache is managed by the Kerberos SSP, which runs in the LSA’s security context. Whenever tickets and keys need to be obtained or renewed, the LSA calls the Kerberos SSP to accomplish the task.

The LSA also keeps a copy of an interactive user’s hashed password. If the user’s TGT expires during a logon session, the Kerberos SSP uses the LSA’s copy of the hashed password to obtain a new TGT silently and without interrupting the user’s logon session. The password is not stored permanently on the computer, and the local copy is deleted when the user’s logon session is terminated.

Hashed passwords for services and computers are handled differently. As in earlier versions of Windows, they are stored in a secure area of the computer’s registry. The registry is also used to store hashed passwords for user accounts on the local system.

DNS Name Resolution

RFC 1510 specifies that Internet Protocol (IP) transport should be used for messages between clients and the KDC. When the Kerberos SSP on a client computer wants to send an initial authentication service request, it needs to find an address for the KDC in the user's account domain. To do that, it needs the Domain Name System (DNS) name of a server where the KDC service is running. If the DNS name can be resolved to an IP address, that is where the Kerberos SSP sends its message. Otherwise, the Kerberos SSP generates an error indicating that it can find no such domain.

In Windows Server 2003 domains, the KDC service runs on every Windows Server 2003-based domain controller. In addition to being KDC servers, domain controllers are also LDAP servers. Both services are registered in DNS service locator records (SRV resource records). Clients can find a domain controller by querying DNS for SRV resource records with the name _ldap._tcp.dc._msdcs.example.com. The KDC service can be located by querying DNS for SRV resource records with the name _kerberos._udp.example.com. Clients that do not support the SRV record type in their DNS resolver can query for a host record (an A resource record) with the name of the domain.

Computers running Windows Server 2003 can participate in Kerberos realms that are not Windows Server 2003 domains. In this case, the KDC will not be on a Windows Server 2003-based domain controller, so the DNS names for KDC servers must be stored in the client computer's registry. The Kerberos SSP looks in the registry for the DNS domain name of the user's realm, and then it resolves the name to an IP address by querying a DNS server.

IP Transport

According to RFC 1510, when a client contacts the KDC, it should send a User Datagram Protocol (UDP) datagram to port 88 at the KDC’s IP address. The KDC should respond with a reply datagram to the sending port at the sender’s IP address.

UDP is a connectionless transport protocol, making it a logical choice when an exchange of messages must precede a connection. UDP is also well suited to applications with one message and one response, such as the exchanges between clients and the KDC, so long as each message fits into a single datagram. Using the UDP transport protocol works best when the higher-level protocol data fits into a single UDP datagram. The capacity of a frame varies with the medium. The Maximum Transmission Unit (MTU) for an Ethernet frame is 1500 octets. The maximum size of the IP header is 60 octets and the UDP header is 16 octets long. If the physical network is Ethernet, then Kerberos messages sent as UDP datagrams can carry up to 1424 octets of data with an IP header of 60 octets. The UDP standard states that hosts must be capable of accepting UDP datagrams that are only 516 octets long.

Windows Server 2003 authorization data can easily total more than 1424 octets. This is outside the capacity of the UDP packet size; therefore, the only solution is to make use of the Transport Control Protocol (TCP) for the transport of this authorization data. The use of TCP transport is consistent with recently proposed revisions to RFC 1510 in the Internet Draft with the file name draft-ietf-krb-wg-kerberos-clarifications-04.txt, and it has been implemented in the latest release of the MIT Kerberos solution.

Authorization Data

Kerberos is a protocol designed primarily for authentication. It verifies that the identity of the Kerberos security principals is correct. It does not determine which files and other objects security principals may access or how they may access them. These decisions are left to whatever access control mechanism may be available on the system. The Kerberos protocol has extensions allowing it to assist authorization mechanisms by providing a field for authorization data in Kerberos tickets. Kerberos does not specify the form of the data or how servers should use it.

Access Control in Windows Server 2003

On some operating systems, applications are required to implement their own mechanisms for determining the level of a user’s authorization. Often, applications do this by maintaining private lists with the names of users who are authorized access. This kind of access control, sometimes called *name-based authorization, *can be integrated with Kerberos authentication just by ensuring that the authorization data field of a ticket carries some form of the security principal’s name.

Applications designed for Windows Server 2003 can implement name-based authorization mechanisms to control access to information internal to the application. Database applications, for example, often maintain private authorization tables to control which fields in a record a particular user can view or change. Unfortunately, private authorization mechanisms are just that—private. A database application is powerless to prevent an unauthorized user from running another application and using it to edit the data file.

On Windows Server 2003, if a file or other resource can be shared by two processes, it is secured against unauthorized access by the operating system’s own access control mechanism. The header of every object includes a security descriptor with an access control list (ACL) maintained by the object’s owner, who has the discretion to grant or deny access to any security principal and to define the level of authorization for a security principal that has been granted access. The operating system enforces the owner’s decisions by performing an access check whenever an application requests access to a protected object. Before returning a handle, the operating system examines the object’s ACL to see whether the security principal that is using the application has been granted access. If not, the application is denied access.

Another important difference from other access control mechanisms is that security principals are not identified by name in Windows Server 2003, either by the operating system or by entries in ACLs. Instead, each security principal is assigned a unique Security Identifier (SID), an alphanumeric value with a structure similar to a telephone number. Like the country or region code used in international calling, the first part of a SID identifies the domain where the SID was issued. Like the number for a particular telephone within a country, the second part of a SID identifies an account within the issuing domain. The value for a domain is unique within an enterprise, and the value for an account is unique within a domain. Unlike telephone numbers, SIDs are never reused. There is no possibility that a user could be assigned a SID that once belonged to another user—a problem not easily solved by name-based access control mechanisms.

A third important difference with name-based access control is that authorization is determined not only by the user’s identity but also by the user’s membership in one or more security groups. In fact, the preferred method of controlling resources is to grant access to groups instead of to individuals, adjusting the level of a group’s authorization according to the needs of its members. This method makes it easier to keep ACLs up-to-date on networks with thousands of users and millions of objects. Group membership can be managed centrally by administrators, who can change a particular user’s level of authorization for many resources just by adding or removing a member from a group.

Windows Server 2003 makes resource security still easier to manage by allowing groups to be nested. A group created in one domain can be included in the membership of a group created in another domain or in the membership of a universal group used throughout a tree of trusted domains. As a result, when employees change jobs, their level of authorization can be changed throughout the enterprise without touching the ACL on a single object.

Like individual security principals, each Windows Server 2003 security group has an SID. A user’s level of authorization is determined, then, by a list of SIDs—one SID for the user and one SID for each security group to which the user belongs.

How the Microsoft KDC Prepares Authorization Data

When the Kerberos protocol is used for authentication, a list of SIDs identifying a security principal and the principal’s group membership is transported to the local computer in the authorization data field of a session ticket. Authorization data is gathered in two separate steps. The first step takes place when the KDC in a Windows Server 2003 domain prepares a TGT. The second step is accomplished when the KDC prepares a session ticket for a server in the domain.

When a user requests a TGT, the KDC in the user’s account domain queries the domain’s Active Directory. The user’s account record includes an attribute for the user’s SID as well as an attribute with SIDs for any domain security groups to which the user belongs. The list of SIDs returned by the KDC’s query is placed in the TGT’s authorization data field. In a multiple-domain environment, the KDC also queries the global catalog for any universal groups that include the user or one of the user’s domain security groups. If any are found, their SIDs are added to the list in the TGT’s authorization data field.

When the user requests a session ticket for a server, the KDC in the server’s domain copies the contents of the TGT’s authorization data field to the session ticket’s authorization data field. If the server’s domain is different from the user’s account domain, the KDC queries Active Directory to find out whether any security groups in the local domain include the user or one of the user’s security groups. If any are found, their SIDs are added to the list in the session ticket’s authorization data field.

This use of the authorization data field is consistent with revisions to RFC 1510 submitted to the IETF. The Windows Server 2003 authorization data is in Network Data Representation (NDR) format and is signed by the KDC.

How Services Use Authorization Data

In Windows Server 2003, services act in their own security contexts only when accessing resources on their own behalf. For the most part, this is just when they are doing their own housekeeping—accessing configuration data stored in registry keys, binding to communications ports, and completing other tasks not related to work for a particular client. When a service does do something for a client, it impersonates the client, acting in the client’s security context. This means that in addition to identifying clients, Windows Server 2003 services must also take on some of their characteristics—specifically, the client’s level of authorization on the system.

When a service sets up housekeeping on a computer running Windows Server 2003, it calls the SSPI method AcquireCredentialsHandle to gain access to its own credentials—the secret key for the account under which the service runs. The service then binds to a communications port where it listens for messages from prospective clients.

When a client requests a connection and presents a session ticket, the service asks the Kerberos SSP to verify the client’s credentials by calling the SSPI method AcceptSecurityContext, passing the client’s session ticket along with a handle to the service’s secret key. The Kerberos SSP verifies the ticket’s authenticity, opens it, and passes the contents of the authorization data field to its parent process, the LSA. If the data includes a list of SIDs, the LSA uses them to build an access token representing the user on the local system. In addition, the LSA queries its own database to determine if the user or one of the user’s security groups is a member of a security group created on the local system. If any are found, the LSA adds those SIDs to the access token. The LSA then confirms to the calling service that the client’s identity has been authenticated, enclosing a reference to the client’s access token.

On receiving confirmation, the service completes its connection with the client and attaches the client’s access token to an impersonation thread by calling ImpersonateSecurityContext. When the impersonation thread needs access to an object, it presents the client’s token. The operating system performs an access check by comparing SIDs in the token to SIDs in the object’s ACL. If it finds a match, it checks to see that the entry in the ACL grants the level of access requested by the thread. If it does, the thread is allowed access. Otherwise, access is denied.

Why Authorization Data Is Signed

Session tickets are encrypted with the secret key for the account under which the service starts. When a service acquires a handle to its own credentials on the system, it gains access to that key. A rogue service could be installed by an unscrupulous user with a legitimate network account but limited authorization on the local computer. The user could request a session ticket for the service, and then the service could decrypt the ticket, modify the authorization data by adding the SID for a privileged group, encrypt the altered ticket, and present it to the LSA in a call to AcceptSecurityContext. The result would be to elevate the user’s level of authorization on the computer where the service is running.

To prevent tampering with authorization data, it is signed by the KDC before it is stored in a session ticket. Any attempt to alter the data will invalidate the signature. The LSA on a Windows Server 2003 computer always checks the validity of this signature when session tickets are presented by untrusted services.

The LSA can trust calls to AcceptSecurityContext from services running under the Local System account. This account is used by services installed with the operating system—by the native server service, for example. Other services can be configured to use the Local System account, but this must be done by a member of the Administrators group. It is assumed that the administrator who installs the service can vouch for its security.

The LSA does not trust services running under any other account. If a session ticket is presented by an application that is not running as Local System, the LSA asks the KDC in its domain to verify the signature on the ticket’s authorization data. The question is asked and answered by a Remote Procedure Call (RPC) over the Net Logon secure channel to the domain controller. Requests for verification do not need to travel beyond the local domain because session tickets are always issued—and therefore authorization data is always signed—by the KDC for the target computer’s domain.

Implementation

When a user with an account in a Windows Server 2003 domain logs on at the keyboard of a computer running Windows Server 2003, the user’s logon request is processed in three stages:

1. The user asks for admission to the Ticket-Granting Service for the domain.

   This is accomplished by an AS exchange between the Kerberos SSP on the computer and the KDC for the user’s account domain. The result of a successful exchange is a TGT that the user can present in future transactions with the KDC.

2. The user asks for a ticket for the computer.

   This is accomplished by a TGS exchange between the Kerberos SSP on the computer and the KDC for the computer’s account domain. The result is a session ticket that the user can present when requesting access to system services on the computer.

3. The user asks for admission to Local System services on the computer.

   This is accomplished when the Kerberos SSP on the computer presents a session ticket to the LSA on the computer.

If the computer’s domain is different from the user’s domain, an extra step is involved. Before requesting a session ticket for the computer, the Kerberos SSP must first ask the KDC in the user’s account domain for a TGT good for admission to the KDC in the computer’s account domain. It can then present the TGT to that KDC and get a session ticket for the computer.

Exactly how the logon process works will depend on how the computer is configured. With standard configurations of Windows Server 2003, interactive users log on with a password. The operating system also includes the option to log on with a smart card. The basic process is the same for both configurations. Their differences will be examined after first stepping through the process for a standard logon with a password.

For example, suppose Alice has a network account in the domain example.com. The computer she normally uses, Machine01, also has an account in example.com. When Alice logs on to the network, she begins by pressing the key combination CTRL+ALT+DEL, the Secure Attention Sequence (SAS) on computers with a standard Windows configuration.

In response to the SAS, the computer’s Winlogon service switches to the logon desktop and dispatches to the Graphical Identification and Authentication (GINA) dynamic-link library, a component loaded in Winlogon’s process. The GINA is responsible for collecting logon data from the user, packaging it in a data structure, and sending everything to the LSA for verification. Third parties can develop replacement GINAs, but in this case Winlogon has loaded the standard component supplied with the operating system, msgina.dll. Winlogon dispatches to it, and it displays the standard Logon Information Dialog.

Alice types her user name and password. From the domains in a drop-down list, she selects example.com. When she clicks OK to dismiss the dialog box, msgina.dll returns her logon information to Winlogon. It sends the information to the LSA for validation by calling LsaLogonUser.

On receiving a data structure with Alice’s logon data, the LSA immediately converts her clear text password to a secret key by passing it through a one-way hashing function. It saves the result in the credentials cache where it can be retrieved when needed for TGT renewal or for NTLM authentication to servers that are not capable of Kerberos authentication.

To validate Alice’s logon information and set up her logon session on the computer, the LSA must obtain:

• A TGT good for admission to the Ticket-Granting Service.

• A session ticket good for admission to the computer.

The LSA gets these tickets by working through the Kerberos SSP, which exchanges messages directly with the KDC in example.com.

The messages follow this sequence:

1. The LSA sends the message KRB_AS_REQ to the KDC in example.com.

   The message includes:

   • The user principal name: Alice.

   • The name of the account domain: example.com.

   • Preauthentication data encrypted with the secret key derived from Alice’s password.

2. If the client’s preauthentication data is correct, the KDC replies with KRB_AS_REP.

   The message includes:

   • A session key for Alice to share with the KDC, encrypted with the secret key derived from Alice’s password.

   • A TGT for the KDC in example.com, encrypted with the KDC’s secret key.

   The TGT includes:

   • A session key for the KDC to share with Alice.

   • Authorization data for Alice.

   The authorization data includes:

   • The SID for Alice’s account.

   • SIDs for security groups in the domain example.com that include Alice.

   • SIDs for universal groups in the enterprise that include either Alice or one of her domain groups.

3. The LSA sends the message KRB_TGS_REQ to the KDC in example.com.

   The message includes:

   • The name of the target computer: Machine01.

   • The name of the target computer’s domain: example.com.

   • Alice’s TGT.

   • An authenticator encrypted with the session key Alice shares with the KDC.

4. The KDC replies with KRB_TGS_REP.

   The message includes:

   • A session key for Alice to share with Machine01, encrypted with the session key Alice shares with the KDC.

   • Alice’s session ticket to Machine01, encrypted with the secret key Machine01 shares with the KDC.

   The session ticket includes:

   • A session key for Machine01 to share with Alice.

   • Authorization data copied from Alice’s TGT.

Having received Alice’s session ticket, the LSA decrypts it with the computer’s secret key and extracts her authorization data. It then queries the local SAM database to discover whether Alice is a member of any security groups local to the computer and whether she has been given any special privileges on the local computer. It adds any SIDs returned by this query to the list taken from the ticket’s authorization data. The entire list is then used to build an access token, and a handle to the token is returned to Winlogon, along with an identifier for Alice’s logon session and confirmation that her logon information was valid.

Winlogon creates a window station and several desktop objects for Alice, attaches her access token, and starts the shell process she will use to interact with the computer. Alice’s access token is subsequently inherited by any application process that she starts during her logon session. This allows Alice to more securely use Active Directory services on various servers running Windows Server 2003 without having to reauthenticate.

Microsoft Active Directory Directory Service

A directory service consists of both a directory storage system (called the directory store) and a mechanism that is used to locate and retrieve information from the system. Active Directory stores objects that provide information about the things that exist in an organization's network and that are associated with one or more domains, such as users, specific groups of users, computers, applications, services, files, and distribution lists. It then makes this information available to users and applications throughout the organization.

In Windows Server 2003, Active Directory is tightly integrated with the operating system and, in particular, the security subsystem. The tight integration of the directory service and security subsystem services is critical to the implementation of Windows Server 2003 distributed systems.

Windows Server 2003 uses modules and modes that combine to provide operating system services to applications. Two processor access modes, kernel and user, divide the low-level, platform-specific processes from the upper-level processes, respectively, to shield applications from platform differences and to prevent direct access to system code and data by applications. Each application, including service applications, runs in a separate module in user mode, from which it requests system services through an API that gains limited access to system data. An application process begins in user mode and is transferred to kernel mode, where the actual service is provided in a protected environment. The process is then transferred back to user mode. The security subsystem in user mode is the module in which Active Directory runs. The security reference monitor, which runs in kernel mode, is the primary authority for enforcing the security rules of the security subsystem.

Access to all directory objects first requires proof of identity (authentication), which is performed by components of the security subsystem, and then validation of access permissions (authorization), which is performed by the security subsystem in conjunction with the security reference monitor. The security reference monitor enforces the access control applied to Active Directory objects.

Security Subsystem Architecture

Windows Server 2003 includes a set of security components that make up the Windows security model. These components ensure that applications cannot gain access to resources without authentication and authorization.

Components of the security subsystem run in the context of the Local Security Authority (LSA) lsass.exe process and include the following:

• Local Security Authority

• Net Logon service

• Security Accounts Manager service

• LSA server service

• Secure Sockets Layer

• Kerberos 5 authentication protocol and Windows LAN-Manager (NTLM) authentication protocol

The security subsystem keeps track of the security policies and the accounts that are in effect on the computer system. In the case of a domain controller, these policies and accounts are the ones that are in effect for the domain in which the domain controller is located. They are stored in Active Directory.

The LSA is a protected subsystem that maintains the information about all aspects of local security on a system (collectively known as the local security policy) and provides various services for translation between names and identifiers.

In general, the LSA performs the following functions:

• Manages local security policy.

• Provides interactive user authentication services.

• Generates tokens, which contain user and group information, as well as information about the security privileges for that user. After the initial logon process is complete, all users are identified by their Security Identifier (SID) and the associated access tokens.

• Manages the audit policy and settings. When an audit alert is generated by the Security Reference Monitor, the LSA is charged with writing that alert to the appropriate system log.

The local security policy identifies the following:

• The domains that are trusted to authenticate logon attempts.

• Who can have access to the system and in what way (for example, interactively, over the network, or as a service).

• Who is assigned privileges.

• What security auditing is to be performed.

• Default memory quotas (paged and nonpaged memory pool usage).

The LSA has the following components:

• netlogon.dll. This is the Net Logon service. Net Logon maintains the computer's secure channel to a domain controller. It passes the user's credentials through a secure channel to the domain controller and returns the domain security identifiers and user rights for the user. In Windows Server 2003, the Net Logon service uses DNS to resolve names to the IP addresses of domain controllers. Net Logon is the replication protocol for Windows-based primary domain controllers and backup domain controllers.

• msv1_0.dll. This is the NTLM authentication protocol. This protocol authenticates clients that do not use Kerberos authentication.

• schannel.dll. This is the Secure Sockets Layer (SSL) authentication protocol. This protocol provides authentication over an encrypted channel instead of a less-secure clear channel.

• kerberos.dll. This is the Kerberos 5 authentication protocol.

• kdcsvc.dll. This is the Kerberos Key Distribution Center (KDC) service, which is responsible for granting ticket-granting tickets (TGTs) to clients.

• lsasrv.dll. This is the LSA server service, which enforces security policies.

• samsrv.dll. This is SAM, which stores local security accounts, enforces locally stored policies, and supports APIs.

• ntdsa.dll. This is the directory service module, which supports the Windows Server 2003 replication protocol and LDAP and manages partitions of data.

• secur32.dll. This is the multiple authentication provider that holds all of the components together.

Directory Service Architecture

Active Directory functionality can be described as a layered architecture in which the layers represent the server processes that provide directory services to client applications. Active Directory consists of three service layers and several interfaces and protocols that work together to provide directory services. The three service layers accommodate the different types of information that are required to locate records in the directory database. Above the service layers in this architecture are the protocols and APIs (APIs are on the clients only) that enable communication between clients and directory services or, in the case of replication, between two directory services.

Figure A.1 shows the Active Directory service layers and their respective interfaces and protocols. The direction of the arrows indicates the manner in which the different clients gain access to Active Directory through the interfaces. LDAP and Messaging API (MAPI) clients gain access to the directory by calling functions, indicated by one-way arrows into the directory system agent. The SAM exists as a separate dynamic-link library (samsrv.dll) and can call only entry points exported by the directory system agent DLL, ntdsa.dll. All other components except the extensible storage engine (esent.dll) are in ntdsa.dll itself and are linked to the functions that they want to call. Thus, a three-way interaction is required between the three DLLs.

Figure A.1. Active Directory service layers and interface agents

Clients obtain access to Active Directory by using one of the following mechanisms that are supported by Active Directory:

• LDAP/ADSI. Clients that support LDAP use LDAP to connect to the directory system agent.

• MAPI. Microsoft Outlook® messaging and collaboration clients connect to the directory system agent by using the MAPI RPC Address Book provider interface.

• SAM. Clients running versions of Windows earlier than Windows 2000 use the SAM interface to connect to the directory system agent. Replication from backup domain controllers in a mixed-mode domain goes through the SAM interface as well.

• REPL. During directory replication (REPL), Active Directory directory system agents connect to each other by using a proprietary RPC interface.

The key service components include the following:

• Directory system agent. This builds a hierarchy from the parent-child relationships stored in the directory and provides APIs for directory access calls.

• Database layer. This provides an abstraction layer between applications and the database. Calls from applications are never made directly to the database; they go through the database layer.

• Extensible storage engine. This communicates directly with individual records in the directory data store on the basis of the object's relative distinguished name attribute.

• Data store (the database file ntds.dit). This file is manipulated only by the extensible storage engine database engine. You can administer the file by using the ntdsutil command-line tool.

These service components are explained in more detail in the following sections.

Directory System Agent

The DSA is the process that provides access to the store. The store is the physical store of directory information located on a hard disk. The DSA is the server-side process that creates an instance of a directory service. Clients use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write Active Directory objects and their attributes.

The Active Directory namespace is partitioned so that individual domain controllers do not store the entire directory. Every DSA holds at least a single Windows Server 2003 directory partition that stores domain data for a domain (such as users, groups, and organizational units) plus two nondomain directory partitions that store forest-wide data, which includes the schema and configuration data.

The DSA layer provides the following functionality:

• Object identification. Every object in Active Directory has a permanent globally unique identifier (GUID) that is associated with several string forms of the object name (SAMAccountName, user principal name, distinguished name) as well as a security identifier. These object names and the security identifier are not permanent—that is, they can be changed. All permanent references to the object are kept in terms of the GUID; the object name is used for hierarchy navigation and display purposes, and the security identifier is used for access control. The DSA maintains the GUID association with an object when the object's string name or security identifier changes.

• Schema enforcement of updates. In a multimaster system, a change to a schema object in one replica might conflict with existing objects in that replica and also with objects in other replicas. In Windows Server 2003, a schema change is a single-master operation; so if an update does not produce a conflict at the originating replica, the update is considered acceptable at all replicas. Thus, replicated updates do not perform any schema checks, and you do not have to wait until the schema replicates before creating instances of a new object or attribute.

• Access control enforcement. The DSA enforces security limitations in the directory. The DSA layer reads SIDs on the access token.

• Support for replication. The DSA contains the hooks for replication notifications. All object updates ultimately must go through the appropriate function for the directory service to work properly.

• Referrals. The DSA manages the directory hierarchy information (referred to as "knowledge"), which it receives from the database layer. The DSA is responsible for cross-references of Active Directory domain objects up and down the hierarchy and also out to other domain hierarchies.

Database Layer

The database layer provides an object view of database information by applying schema semantics to database records, thereby isolating the upper layers of the directory service from the underlying database system. The database layer is an internal interface. No database access calls are made directly to the extensible storage engine; instead, all database access is routed through the database layer.

The database layer in Active Directory uses the LDAP hierarchical naming model, referencing objects by their distinguished name or their relative distinguished name. Data is stored by the database layer in Active Directory using the standard LDAP information model.

Extensible Storage Engine

Active Directory is implemented on top of an indexed sequential access method (ISAM) table manager. The Windows Server 2003 version of this database is esent.dll.

Extensible Storage Engine (ESE) stores all Active Directory objects. It can support a database up to 16 terabytes in size, which can theoretically hold many millions of objects per domain.

The following ESE characteristics make it well suited to the storage needs of Active Directory. The ESE:

• Is used by the information store in Exchange Server 2000.

• Supports indexing.

• Supports multivalue attributes.

• Supports update operations that are transacted for stability and integrity across system failures.

• Can be backed up while the domain controller is online.

• Handles sparse rows well—that is, rows in which many of the properties do not have values.

Active Directory comes with a default schema that defines all of the attributes that are required and allowed for a given object. ESE reserves storage only for the space that is used—that is, only for the attributes that have values, not for all possible attributes. For example, if a user object already has 50 attributes defined in the schema and you create a user with values for only four attributes, storage space is allocated only for those four attributes. If more attributes are added later, more storage is allocated for them.

The esent.dll database implements the search and retrieval functionality of the underlying database. Also, ESE is capable of storing attributes that can have multiple values. For example, the database can store multiple phone numbers for a single user without requiring a different phone number attribute for each phone number.

Protocols and Interfaces to Active Directory

There are four avenues of entry to Active Directory: LDAP/ADSI, REPL, SAM, and MAPI. Each of these access routes uses a different set of protocols and APIs that enable communication with the directory service. Table A.8 shows the APIs that Active Directory supports and that can be used by developers to integrate with Active Directory or use resources in Active Directory.

Table A.8 Active Directory APIs

API Name	Description
LDAP C API	As described in RFC 1823, “The LDAP Application Program Interface,” for LDAPv3, LDAP API is a C language API to the LDAP network protocol.
ADSI	COM interface to Active Directory that abstracts the details of LDAP communications. ADSI provides services and Active Directory information to directory-aware applications. ADSI supports multiple programming languages, including Microsoft Visual Basic®, C, and Visual C++®. ADSI also can be accessed by using Windows Script Host (WSH).
MAPI	Messaging API that is supported for compatibility with Microsoft Exchange Client and Outlook Address Book client applications.
Windows	Windows networking APIs (Net APIs) that are used by Windows clients to gain access to Active Directory through SAM.
SAM	APIs that communicate with the DSA APIs.

These APIs communicate with Active Directory by using various access methods, as described in Table A.9.

Table A.9 Active Directory Access Methods

Access Method	Description
LDAP	Core protocol that is supported by Active Directory, as described in RFC 2251, “Lightweight Directory Access Protocol v3,” and RFC 1777, “Lightweight Directory Access Protocol.”
MAPI RPC	RPC interfaces used by MAPI Address Book provider.
Replication RPC	RPC interfaces used by Active Directory replication over IP transport for replication within sites and between sites.
Replication Simple Mail Transfer Protocol (SMTP)	Replication protocol used by Active Directory replication over IP transport for message-based replication between sites only.

The last two protocols in Table A.9 are used for Active Directory replication, which is explained in the next section.

Active Directory Replication

Active Directory replication is performed over replication transport protocols (REPL). For replication within a site, Active Directory replication uses RPC-over-IP transport protocols. For replication between sites, Active Directory replication uses two replication transport protocols: IP (RPC over IP) and SMTP (SMTP over IP).

Note   The user interface that is associated with connection properties in Active Directory Sites and Services displays RPC for all connections within a site, and it displays either IP (for RPC over IP) or SMTP (for SMTP over IP) for connections between sites. This convention is used to distinguish between RPC over IP for connections that are between sites and those that are within a site.

RPC replication between sites can be scheduled and is compressed. For replication within a site, RPC is always used. RPC replication within a site is not compressed. Thus, Windows Server 2003 directory replication recognizes three degrees of connectivity:

• Uniform, high-speed connectivity (RPC over IP for replication of all directory partitions within a site).

• Point-to-point, synchronous, low-speed connectivity (RPC over IP for replication of all directory partitions between sites).

• Mail-only, asynchronous connectivity (SMTP over IP for replication of only nondomain directory partitions between sites).

On each DSA, replication uses a single thread to receive changes from other servers and applies them locally by using either RPC synchronous transport or asynchronous transport for messaging between sites. The choice of transport is determined by the corresponding connection object (class nTDSConnection). Connection objects are created automatically by the Knowledge Consistency Checker (KCC). You can also create connection objects manually by using Active Directory Sites and Services. Both synchronous and asynchronous transports operate on a request-response basis.

Active Directory Data Storage

Active Directory stores data for an entire forest. "Directory" and "forest" can be considered synonymous. Although there is a single directory, data storage is distributed among one or more domains, while consistent data is maintained throughout the forest that applies to all domains.

Active Directory is partitioned and replicated. So that it can support tens of millions of objects, Active Directory is partitioned into logical segments. To provide support for hundreds of thousands of clients and to provide availability, each logical partition replicates its changes separately among those domain controllers in the forest that store copies (replicas) of the same directory partitions.

Storage Characteristics

Some directory partitions store forest-wide configuration information and schema information; other directory partitions store information that is specific to individual domains, such as users, groups, and organizational units. The directory partitions that store domain information are replicated to domain controllers in that domain only. The directory partitions that store configuration and schema information are replicated to domain controllers in all domains. In this way, Active Directory provides a data repository that is logically centralized but physically distributed. Because all domain controllers store forest-wide configuration and schema information, a domain controller in one domain can reference a domain controller in any other domain if the information that it is requesting is not stored locally. In addition, domain controllers that are global catalog servers store a full replica of one domain directory partition plus a partial replica of every other domain in the forest. Thus, a domain controller that is a global catalog server can be queried to find any object in the forest.

Note   There is a distinction between a directory partition and a database partition. The Active Directory database is not partitioned. Only the directory tree, which is the logical representation of the data held by a domain controller, is partitioned.

The distribution of Active Directory data in the directory tree can be summarized as follows:

• Domain-wide data:

  • Domain-specific data is stored in a domain directory partition.

  • A full, writable replica of the domain directory partition is replicated to every domain controller in the domain, including any global catalog servers in the domain.

• Forest-wide data:

  • Forest-wide data is stored in two directory partitions: the configuration directory partition and the schema directory partition. The Configuration container is the topmost object of the configuration directory partition; the Schema container is the topmost object of the schema directory partition.

  • Full, writable replicas of the configuration directory partition and the schema directory partition are replicated to every domain controller in the forest.

  • In addition to a full, writable replica of a single domain (the domain for which the domain controller is authoritative), partial, read-only replicas of every other domain directory partition in the forest are stored on domain controllers that are designated as global catalog servers. The read-only replicas in the global catalog are "partial" because they store only some of the attributes for each object.

Note   When Active Directory is first installed on a computer that is running Windows Server 2003, the entire full replicas or partial replicas are replicated to create the directory. Thereafter, only changes to directory objects (attribute changes and the creation and deletion of objects) are replicated.

Data Characteristics

The key characteristics of the data that is stored by a directory service correspond to size and latency. Active Directory should store objects that are not so large that they hamper replication and not so unstable that they change before an update replicates to all replicas in the forest.

In general, Active Directory is appropriate for the storage of data that has the following characteristics:

• The data is globally useful information in the domain that needs to be replicated to each Active Directory domain controller.

• The data has well-defined object attributes and semantics.

• The data has a useful life that is at least two times the maximum replication latency for the forest (to include replication of data that is marked to replicate to the global catalog). In general, if data can become outdated before the completion of a replication cycle or shortly thereafter, it should not be stored in Active Directory. Clients should be capable of tolerating the inability to update data for at least as long as it takes for the data to be replicated throughout the domain.

• The data-per-attribute value is not so large that it affects performance. An attribute value is replicated as a single block of data; therefore, an attribute that is x megabytes in size requires an equivalent amount of buffer space in the sending and in the receiving domain controllers. If the amount of required buffer space is large, the performance of the domain controller can be adversely affected.

As a result of these characteristics, large, unstructured data sets and data values that change frequently are not appropriate for storage in Active Directory.

Windows Server 2003 LDAP Implementation

The Windows Server 2003 implementation of LDAP is an essential component of Active Directory because it defines:

• Network connectivity

• Naming model

• Information model

• APIs

In all of these, Active Directory adheres to the LDAP standard. This section looks at the specifics of the LDAP implementation within Active Directory.

The LDAP implementation present within Active Directory is based on the standards described in RFC 2251 (which defines LDAPv3) and RFC 1777 (which defines LDAPv2). Windows 2000 clients, as well as Windows 98 and Windows 95 clients that have the Active Directory client components installed, use LDAPv3 to connect to the directory system agent.

The LDAP Protocol in Active Directory

LDAP is a directory service protocol that specifies directory communications. It runs directly over TCP/IP and can also run over User Datagram Protocol (UDP) connectionless transports. LDAP enables clients to query, create, update, and delete information stored in a directory service over a TCP connection through the TCP default port 389. In Active Directory, LDAP is the only network protocol used to access the directory.

Note   Windows Server 2003 Active Directory does not implement the X.500 protocols (which include Directory Access Protocol [DAP], Directory System Protocol [DSP], Directory Information Shadowing Protocol [DISP], and Directory Operational Binding Management Protocol [DOP]). LDAP provides the most important functions offered by DAP, and it is designed to work over TCP/IP without the overhead of "enveloping" OSI protocols over TCP/IP.

The LDAP Directory Service and Information Model in Active Directory

The Active Directory LDAP directory service is based on a client/server model. One or more LDAP servers contain the data making up the directory tree. An LDAP client connects to an LDAP server and requests information or performs an operation. The server performs the operation or provides the information, or it refers the client to another LDAP server that might be capable of doing so. When connecting to a specific LDAP directory tree, it does not matter what LDAP server a client connects to; a name presented to one LDAP server references the same object (referred to as an entry in LDAP) that it would reference at another LDAP server. This is an important feature of a global directory service.

The LDAP information model is based on the entry, which contains information about some object (for example, a person or computer). In Active Directory, an LDAP entry is referred to as an object. Entries are composed of attributes, which have a type and one or more values. Each attribute has a syntax that determines what kinds of values are allowed in the attribute.

The Active Directory Schema

The Active Directory schema contains formal definitions of every object class that can be created in an Active Directory forest. The schema also contains formal definitions of every attribute that can exist in an Active Directory object. In addition to the default schemas provided with Windows Server 2003, Active Directory also allows you to extend the schema, either using standard-based schemas not included in Active Directory or your own custom schemas.

This guide mainly concentrates on using Active Directory to store user account data and user authentication data; therefore, it is important to consider the schemas that are used to store user account data in Active Directory. Typical LDAP object classes used to store user account information include inetOrgPerson, which is derived from organizationalPerson, which is itself derived from person. Active Directory differs from this structure because user account information is stored in objects of the class user, which is derived from the object class organizationalPerson. Microsoft created the user class to enable them to store the attributes required by a user in an Active Directory domain. The user class extends the organizationalPerson class with many additional attributes; these attributes are defined in two auxiliary classes: securityPrincipal and mailRecipient. The auxiliary class securityPrincipal contains security information about the user, such as the user's SID. The auxiliary class mailRecipient contains information relating to the user's e-mail account; these attributes are most commonly used by Microsoft Exchange Server.

The inetOrgPerson Class in Windows Server 2003 Active Directory

In Windows Server 2003, the inetOrgPerson object class was added to the schema used in Windows 2000 Active Directory. The inetOrgPerson class is defined by RFC 2798. It is used to store information in the directory that is relevant to user accounts; this is similar to the user class in Active Directory.

The inetOrgPerson class is important because it is widely used by other vendors. For example, many companies that use iPlanet or eDirectory as an e-commerce or enterprise directory have built or purchased applications that depend on the existence of the inetOrgPerson class.

The vendors that build these applications would like to integrate them with Active Directory with the smallest amount of modifications to their applications. Additionally, enterprises that have been using other directories and would like to migrate to Active Directory want to be able to move their current set of inetOrgPerson objects to Active Directory with the smallest amount of difficulty.

The implementation of inetOrgPerson in Active Directory differs from RFC 2798, “Definition of the inetOrgPerson LDAP Object Class” in the following ways:

• The inetOrgPerson class is derived from the user class instead of the organizationalPerson class.

• Attributes that have already been defined in the base schema for Active Directory are not changed.

• There are two mandatory attributes that are inherited by the inetOrgPerson class. They are the cn and samAccountName attributes.

• The objectCategory for inetOrgPerson is set to person.

Microsoft took a number of important steps to ensure that inetOrgPerson attributes will integrate with user attributes. Of particular note is the integration of password management. There are two different fields to store passwords in the two schemas: unicodePwd and userPassword. The unicodePwd field stores a one-way format of the password that makes it extremely difficult to determine the original password. The unicodePwd field is the attribute used by Windows 2000 and Windows Server 2003 to store user passwords. The inetOrgPerson attribute used to store passwords is userPassword. In an attempt to ensure that the two password fields are kept synchronized, updating the userPassword attribute over a secure connection will also update the unicodePwd attribute.

Storing User Attributes Using the Windows Services for UNIX Schema in Active Directory

The Windows Services for UNIX schema also contains user attributes, but in this case the user attributes contain UNIX-style account information. The Windows Services for UNIX schema extends the standard Active Directory user class to enable it to store UNIX account information. Additionally, Windows Services for UNIX extends Active Directory management tools and integrates features, such as password management, to include UNIX attributes.

Note   Further information about the Active Directory schemas for Windows 2000, Windows Server 2003, and Active Directory Application Mode (ADAM) can be found at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/active_directory_schema_site.asp.

The LDAP API in Active Directory

Unlike most other Internet protocols, the LDAP protocol has an associated API that simplifies writing Internet directory service applications. The LDAP API is a C language API to the LDAP protocol. RFC 1823 specifies the LDAP APIs that are required for a client to gain access to a directory service that supports the LDAP protocol. This API set is relatively simple and supports both synchronous and asynchronous calls to the server.

Microsoft implements the LDAP API in wldap32.dll—also referred to as "LDAP C" or "C-binding LDAP." Applications that are written using the LDAP API are compatible only with LDAP directory services. ADSI, which provides a COM interface to Active Directory, is layered on top of LDAP and provides the easiest access to Active Directory through LDAP. However, Active Directory also fully supports the LDAP APIs for directory access.

Note   For more information about the LDAP API and about programming in LDAP, see “Using Lightweight Directory Access Protocol” at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/ldap/ldap/using_the_ldap_api_in_a_client_application.asp.

Active Directory Service Interfaces (ADSI)

The primary and recommended API for Active Directory is ADSI. ADSI enables access to Active Directory by exposing objects stored in the directory as COM objects. A directory object is manipulated using the methods on one or more COM interfaces. ADSI providers contain the implementation of ADSI objects for a particular namespace. By implementing the required interfaces, ADSI providers translate these interfaces to the API calls of a particular directory service.

ADSI LDAP Provider

The ADSI LDAP provider operates on the ADSI client to provide access to Active Directory or to other LDAP directory services. The ADSI LDAP provider works with any LDAP server that supports at least LDAPv2. In addition to Windows Server 2003 Active Directory, directory services that are accessible through the LDAP provider include the following:

• Netscape Directory Server

• Microsoft Exchange Server 2000 and later

• Microsoft Commercial Internet System (MCIS) Address Book Server

• University of Michigan Stand-Alone LDAP Directory (SLAPD) Server

• Other Internet directory servers (for example, ldap.yahoo.com)

Note   The Windows ADSI provider enables access to Windows directories, providing for communication with Windows-based primary domain controllers and backup domain controllers. Other providers include NDS for access to Novell Directory Services directories, NWCOMPAT for access to Novell NetWare 3.x and Novell NetWare 4.x directories, and Microsoft Internet Information Services (IIS) for access to HTTP data directories used by IIS.

Common Uses of Directory Services

Directory services can be used to store operating system information. LDAP can be used to store operating system information for UNIX, Linux, and Windows Server 2003. LDAP can also be used as a directory service for applications. The following sections look at some common uses of LDAP as a directory service beyond its use in system management.

Host Name Lookup

Almost all network services and applications require the resolution of network names to IP addresses and vice versa. The standard directory service for the resolution of network names is DNS and, as such, it is the most widely used network directory service.

DNS is a specialized directory service, and it is particularly efficient and effective at providing that service. LDAP directories can be used to store and resolve host names instead of DNS, but because LDAP is a generic directory service, it is not as effective at this task as DNS. Additionally, it is unlikely that DNS will ever be replaced by LDAP for this task. However, the host and network address data stored within DNS has uses beyond those possible with DNS, and it would be helpful if it was stored in LDAP.

One method of making the host information in DNS more widely available is to place the DNS Resource Records (RRs) within a LDAP directory. In this scenario, the DNS server uses LDAP as its data store. Because the data store is LDAP, it is possible to add attributes to the host information stored there and use this information for other purposes. One potential use of this data is for printer management. A printer host entity within an LDAP directory could have attributes to store the resource record data required by DNS, as well as attributes to store printer settings and capabilities.

The Microsoft DNS server in Windows Server 2003 supports placing DNS resource records in Active Directory instead of in zone files. A significant benefit of placing RRs in Active Directory is that the zone data is automatically replicated over all Active Directory domain controllers. The Microsoft DNS server utilizes this for load-balancing and to enable each domain controller to act as part of a DNS multiple-master configuration. In standard DNS configurations, one DNS server acts as the master. The master DNS server is the only server where modifications to the zone data can take place, including modifications resulting from dynamic updates of DNS resource records. Copies of changes to the master zone files are made to secondary DNS servers using a process called a zone transfer (or through incremental zone transfers). In a multiple-master configuration, updates to the zone data can occur on any DNS server. This is a significant advantage gained by using Microsoft DNS, particularly as Dynamic DNS updates are an important part of Active Directory.

Application Stores

Many current applications are capable of using LDAP as a directory store. These applications include Web servers, ERP systems, and e-mail systems.

E-mail systems are probably the single largest users of LDAP directories. LDAP directories are ideal for storing e-mail address books and e-mail configuring settings. Both e-mail clients, such as Message User Agents (MUAs), and e-mail servers, such as Message Transfer Agents (MTAs), can make use of LDAP. The majority of e-mail clients and servers include LDAP integration.

E-mail servers that support the use of LDAP for configuration include:

• Microsoft Exchange Server

• Sendmail

• Postfix

• Exim

E-mail clients that support the use of LDAP include:

• Microsoft Exchange Client

• Microsoft Outlook

• Eudora

• Pine

• Evolution

• Mozilla Mail

• Netscape Communicator

Many other LDAP-enabled applications could be cited. Those listed previously serve to illustrate the potential that exists for consolidating enterprise data into Active Directory, thereby enabling you to benefit from the comprehensive security and management features of Active Directory and from the significant benefits of a single repository for enterprise data.

Note   For more information about how Microsoft Exchange Server 2000 uses Active Directory as a directory for configuration and user information, see the Microsoft online book Understanding and Troubleshooting Directory Access at https://www.microsoft.com/downloads/details.aspx?FamilyID=c976433f-f979-4745-b7a6-9d8446ef6409&DisplayLang=en.

Download

Get the Windows Security and Directory Services for UNIX Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions