The Ultimate Windows Server 1002003 System Administrators Guide [Electronic resources] نسخه متنی

KERBEROS AUTHENTICATION

Underlying Windows OS security is user authentication. The centralized account management supported by Active Directory Services requires a corresponding authentication protocol for network logon. Based on RFC 1510, Kerberos version 5 provides enhanced authentication for the distributed computing environment and standardization to interoperate with other operating systems. However, while Kerberos is the centerpiece of Active Directory domain authentication, other schemes exist in a Windows Server environment to verify user logons. For example, NTLM protocol is still supported for down-level systems and provides nondomain, local logon capability. In addition, secure channels are used to join domains, make password modifications, and access nontrusted domain resources. Finally, Windows Server 2003 supports methods of user authentication that depend on whether the connection is dial-up, over the Internet, or within the local network. The Kerberos protocol is the preferred method and first choice for authenticating users and services in a local intranet.

Chapter 9, the user's eventual ability to use network resources is determined by access permissions assigned to the resource. These permissions are checked after the authentication process completes.

Protocol.

Understanding Kerberos Concepts

Kerberos version 5 is standard on all versions of Windows Server 2003 and ensures the highest level of security for network resources. Its name comes from the three-headed dog of Greek mythology. Its three heads are the Key Distribution Center (KDC), the client user, and the server with the desired service. The KDC is installed as part of the domain controller and performs two services: authentication and ticket-granting. As exemplified in Figure 10.1, three services, or exchanges, are involved when the client initially accesses a server resource:

Authentication Service (AS) Exchange

Ticket-Granting Service (TGS) Exchange

Client/Server (CS) Exchange

THE AUTHENTICATION SERVICE EXCHANGE

When initially logging on to a network, the user must negotiate access by providing a logon name and password that is verified by the AS portion of a KDC within his domain. The KDC has access to Active Directory user account information. Once successfully authenticated, the user is granted a Ticket-granting ticket (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and can be renewed throughout the user's logon session without the user having to reenter his password. It is cached on the local machine in volatile memory space and used to request sessions with services throughout the network.

Authentication Service Exchange Details

The AS request identifies the client to the KDC in plain text. If preauthentication is enabled, a timestamp will be encrypted using the user's password hash as an encryption key. If the KDC reads a valid time when using the hash (stored in the Active Directory) to decrypt the timestamp, it knows that the request is not a replay of a previous one. This feature can be disabled for specific users in applications that do not support preauthentication. Access the user account from the Active Directory Users and Computers snap-in and select the Account tab. In the Account options list, select Do not require Kerberos preauthentication (Figure 10.2). Table 10.1 outlines the basic elements in the client's AS request to the KDC.

The TGT can be issued with many characteristics identified in the client's request, specified through flag settings. These settings enable various authentication requirements discussed later in the chapter. Table 10.2 defines the TGT flag types.

If the KDC approves the client's request for a TGT, the reply (referred to as the AS reply) will include two sections: a TGT encrypted with a key that only the KDC Ticket-Granting Service can decrypt and a session key encrypted with the user's password hash to handle future communications with the KDC. Since the client system cannot read the TGT, it must blindly present it to the TGS for Service Tickets. The TGT includes Time to Live parameters, authorization data, a session key to use when communicating with the client, and the client's name. The AS reply is composed of data identified in Table 10.3.

THE TICKET-GRANTING SERVICE EXCHANGE

The user presents the TGT to the TGS for access to a server service. The TGS authenticates the user's TGT and creates a ticket and session key for both the client and the remote servers. This information, known as the Service Ticket, is then cached locally on the client machine.

The client sends its TGT and desired Service Ticket settings to the TGS, which reads it using its own key. If the TGS approves the client's request (Table 10.4), a Service Ticket is generated for the client and the target server. The client reads its portion using the TGS session key retrieved earlier from the AS reply (Table 10.3). It presents the server portion (Table 10.5, Section 2) of the TGS reply to the target server in the CS Exchange, coming next.

THE CLIENT/SERVER EXCHANGE

Once the client server has the Client Server Service Ticket, it can establish the session with the server service. Using its own long-term key with the KDC, the server can decrypt the information coming indirectly from the TGS. It can then use the Service Ticket to authenticate the client and establish a service session with it. When the ticket's lifetime is exceeded, it must be renewed to use the service.

Client/Server Exchange Detail

The client blindly passes the server portion of the Service Ticket to the server in the CS request to establish a client/server session (Table 10.6). If mutual authentication is enabled, the target server returns a timestamp encrypted by the Service Ticket session key (Table 10.7). If the timestamp decrypts correctly, not only has the client authenticated itself to the server, but the server has authenticated itself to the client.

NOTEThe target server and the KDC never have to communicate directly. This reduces downtime and pressure on the KDC.

FURTHER CLARIFICATION OF THE LOGON PROCESS

A TGT and a Service Ticket are needed to access services on remote computers, but they are also required to successfully log on to a local system. When the logon window appears, password encryption using a one-way hash algorithm occurs immediately, and negotiations commence with the KDC for a valid TGT and Service Ticket. The process is the same as that for accessing a remote service. An access token is created for the user; the token contains all security groups to which he be longs. It is attached to the user's logon session and subsequently inherited by any process or application the user starts.

REFERRAL TICKETS

The Authentication Service and Ticket-Granting Service functions are separate within the KDC. This permits the TGT obtained from an AS in one domain to be used to obtain Service Tickets from a TGS in other domains. This is accomplished through referral tickets.

Once a trust has been established between two domains, referral tickets can be granted to clients who request authorization for services in both. An interdomain key based on the trust password becomes available for authenticating KDC functions. As illustrated in Figure 10.3, a user client in Entcert1.com requests authority for a server in Entcert2.com using referral tickets. The numbers in Figure 10.3 correspond to the following explanations:

The client uses a TGT to contact its domain KDC TGS. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the foreign domain KDC.

The client contacts the foreign trusted domain KDC with the referral ticket. This ticket is encrypted with the interdomain key. If the decryption works, the TGS for the foreign domain returns a Service Ticket for the server service in Entcert2.com.

The client performs the CS exchange with the server and begins the user session with the service.

When more domains are involved, the referral process extends and involves the transitive properties between Windows Server 2003 domains. Maintaining many two-way trusts between Windows NT domains was an administrative nightmare, but Kerberos transitive domains cut down on interdomain administration. This can best be explained as illustrated in Figure 10.4, where Entcert1.com has a trust relationship with Entcert2.com, which has a trust relationship with Entcert3.com. Since there is no trust between Entcert1.com and Entcert3.com, an Entcert1.com client accessing a service on a server in Entcert3.com would obtain a Service Ticket through the following steps, numbered to correspond with those appearing in the figure.

Use the TGS in Entcert1.com to obtain a referral ticket for a KDC in Entcert2.com.

Use the referral ticket with the TGS on the KDC in Entcert2.com and obtain a referral for Entcert3.com.

Use the second referral ticket with the TGS on the KDC for Entcert3.com and obtain a Service Ticket for the server in that domain.

Perform the client/server exchange to open a session with the service in Entcert3.com.

DELEGATION WITH FORWARDING AND PROXY

Some server services require access to a second server, such as backend database. In order to establish a session with the second server, the primary server must be authenticated on behalf of the client's user account and authority level. This is common in a three-tier client/server model (Figure 10.5) and is usually accomplished with proxy or forwarding authentication.

Proxy Authentication

Proxy authentication requires the client to obtain a Service Ticket for the primary server to use with the secondary server on the client's behalf (Figure 10.6). The client must have the proxy policy enabled when its initial TGT is issued. Then the PROXIABLE flag will be set in the client's TGT. When the primary server requests access to the second server, the client must obtain the second server's name and request a Service Ticket using the proxy-enabled TGT. The KDC then issues a Service Ticket with the PROXY flag set, which the client returns to the primary server. The first server uses the new Service Ticket to establish a session with the desired service on the second server. This new session is based on the client's user ID and address.

FORWARDING AUTHENTICATION

Forwarding allows the primary server to access the secondary server without requiring the client to participate when establishing a session (Figure 10.7). If the forwarding policy is enabled on the KDC, the client may request a forwarding TGT. When it retrieves the TGT, it must reveal the forwarding server's address (the server will soon act on the client's behalf) during the AS exchange. The FORWARDABLE flag is set on the client's TGT. The client then sends the TGT directly to the server requiring access to a second server. The primary server requests Service Tickets on the client's behalf using the forward-enabled TGT given by the client. New Service Tickets requested by the first server from the KDC also have the FORWARDED flag set and allow the first server to use the Service Ticket with the second server. Unlike in the proxy delegation method, this forwarding doesn't require the client to know the second server's name.

The Kerberos Process

The previous sections discussed ticket exchanges required for user authorization. We now take a look at how these exchanges are handled without compromising user information or causing security breaches.

SYMMETRICAL ENCRYPTION AND SHARED KEYS

The basis for Kerberos communication and authentication is symmetrical encryption algorithms using shared secret keys. These keys depend on fast and comparatively simple encryption, and their implementation does not require a public/private key infrastructure. Figure 10.8 demonstrates symmetrical encryption and how shared keys work.

Data is encrypted using a standard encryption algorithm such as Data Encryption Standard (DES) (discussed in Chapter 13). The algorithm takes in readable data and a key for producing encrypted data. Depending on the algorithm, this encrypted data is very difficult to decrypt without the corresponding decryption algorithm and key. Two parties can share a secret key using an out-of-band method and communicate with a strong degree of confidentiality. For example, they might transfer the secret key through a telephone call or "snail" mail; assuming the sender is the only one with the matching secret key, the receiver has some degree of authentication. This assumes that decrypted data is readable and meaningful to the receiver. There is the possibility that someone is replaying a previously sent message, a scenario addressed in the next section.

SHARED SECRET KEYS

In Kerberos, the shared secret key is generated from the user's password using a one-way hash function that is a combination of the Data Encryption Standard, Cipher Block Chaining (CBC), and Message Digest 5. All Kerberos version 5 implementations must minimally implement this hash function for interoperability. A hash function generally inputs the password text string and generates a 128-bit string that would appear meaningless to anyone without the original passwordit is very difficult to obtain the original password string from the generated hash. For further explanation of this hash function, please see William Stallings's excellent book Cryptography and Network Security: Principles and Practice, 3rd ed. (Prentice-Hall, 2002). The KDC and all clients are aware of the hash function and can produce the hash, given the user's password. When the user logs on to the client, the password is put through the hash function to produce a hash that is used as a shared secret key to communicate with the KDC.

Preventing the Replay of Previous Communications

One security concern is that someone will intercept a communication and attempt to pass it off as his own and thereby gain authorization. To avoid this, a timestamp is used to prevent someone from replaying a previous communication. Say a client desires to establish a session with a server. The client and the server share knowledge of a common key, based on the user's password. The client sends a request to log on containing its user ID and the current date/time encrypted using the symmetric key. The server reads the requesting user ID and retrieves the correct key for that user, whereupon the date/time is decrypted. If the date/time value is tolerably close to the server's local clock, the time must have been encrypted using the user's password hash and so the client's identity is verified. Since the date/time is constantly changing, an intruder cannot simply resend the same data to the server. The server also saves all logon attempts from that user for the last several minutes and tests each logon to make sure it is later than the previous one. This obviously requires domainwide clock synchronization within the tolerable settings.

Another option to prevent replay is using a nonce, which is a number randomly generated by the client and sent to the server. The server encrypts the nonce and sends it back to the client with the reply. It keeps track of previously sent nonces and rejects repeats for a given time period. The client can verify that the server has the shared key if it correctly encrypts the original nonce in the reply.

NOTEIn addition to the client's being authenticated to the server, the server is also authenticated to the client. When the client receives a correctly encrypted timestamp from the server, it is certain that the server is who it claims to be. This is known as mutual authentication, another benefit of Kerberos.

NOTEEncryption and session keys function differently. Rather than repeatedly using the user's password hash as the encryption key, a session key can be distributed using the password hash for further communication. The session key is a randomly generated key that is valid only for the length of the communication session.

NOTEA new feature in Windows Server 2003 is Kerberos extended errors facility. This makes more information available for diagnostic and troubleshooting of authentication errors in a domain-based environment. This feature is integral to the operating system and does not require administrative intervention.

Kerberos Policies

The system administrator manages Kerberos through Group Policy settings. Kerberos policies are found under the Security Settings Account Policies Kerberos Policy node under all Group Policy Objects. Figure 10.9 displays the default settings for the Default Domain Policy GPO.

To modify the current settings, double-click the target policy and make the appropriate changes in the dialog box that appears. The Enforce user logon restrictions policy may be disabled to cut down on the number of user right verifications Kerberos must perform. The default lifetimes for the TGT (user ticket) and CS Service Tickets can be increased to lengthen the time between ticket renewals. All systems participating in a Kerberos realm must implement some sort of clock synchronization so that the timestamps are relatively accurate. The clock tolerance interval field can be increased from the default of 5 minutes to provide more time lag between systems.

The standard Kerberos policies that are manageable by system administrators are further explored in Table 10.8.

NOTEThe Log on locally policy and the Access this computer from the network policy are modified from a group policy snap-in in the Computer Configuration Windows Settings Security Settings Local Policies User Rights Assignment node.

Cross-Forest Authentication

Multiple forests are sometimes required for security, administrative, or budgetary reasons. New to Windows Server 2003, cross-forest authorization grants access to local resources for users and groups from other forests while using the native names of those external security principals. An administrator can select users and groups from trusted forests for inclusion in local groups or access control lists. This feature maintains the integrity of the forest security boundary. It enables the trusting forest to enforce constraints on the security identifiers it will accept.

When using the cross-forest authentication, group membership, and ACL, rules must be enforced. For example, names must be typed in completely and wild card searches are not supported. The Object Picker and ACL Editor use system application programming interfaces (APIs) to store SIDs in group member and ACL entries. Name-SID translation APIs are enhanced to use cross-forest routing hints. NTLMs are leveraged to secure channels between domain controllers along the trust path to resolve security principal names or SIDs from trusted forests. SIDs are filtered when authorization data passes from the root domain of the trusted forest to the root domain of the trusting forest. The trusting forest will only accept SIDs that are relative to domains it trusts the other forest to manage. SID filtering is automatically enforced for Kerberos and Windows NTLM authentication.

The Global Catalog is called when Kerberos and NTLM cannot resolve a principal name on the local domain controller. In cases where the GC cannot resolve the name, the new cross-forest name-matching function is used. The way this function works is that the name matching compares the security principal name with trusted namespaces from all trusted forests. The trusted forest returns a routing hint when a match is found. Kerberos and NTLM use routing hints to route authentication requests along the trust path. The Kerberos Key Distribution Centers (KDC) generate referrals that follow the trust path. The client then seeks them out in standard Kerberos fashion. For NTLM, DCs chain the request across secure channels. This chain follows the trust path, using pass-through authentication. User principal name (UPN) credentials are fully supported.

NEW TRUST WIZARD

New to Windows Server 2003 is an improved Trust Wizard designed to create both sides of a trust link in one operation. This works where proper credentials are supplied for both sides of the trust. This wizard applies to both Windows 2000 and Windows Server 2003 involved with external or forest trust links. A new Trust API is also provided to support delegation required to deploy resource forests. The function includes matching required credentials to type of trust. With this domain, administrators can create inbound forest trust and enforce quotas on user-created trust links. The new wizard is activated via Active Directory Domains and Trusts snap-in Domain Properties Trusts New Trust.