Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Kerberos Authentication
On any secured network, before access to a resource is granted, the requestor must first provide proof of identity. This process is known as authentication. In Windows NT, the NTLM authentication protocol provides servers with the capability to identify clients requesting access to a resource. Servers on an NT network are assumed to be trusted resources, with clients having no reason to verify server identities.
The authentication framework changes in Windows 2000 with the introduction of the Kerberos standard.
NOTE
The name Kerberos is taken from Greek mythology, associated with the three-headed dog responsible for guarding the gate to the underworld. This mythical beast is best known by his Latin name, Cerberus.
Kerberos authentication is limited to Windows 2000 domain controllers and Windows 2000 clients. Windows 9x clients can install the Directory Services client to utilize Kerberos, but Windows NT clients must be upgraded to Windows 2000. To provide for backward compatibility, Windows 2000 maintains the NTLM protocol for authentication of down-level clients. In addition, Windows 2000 servers utilize NTLM authentication when accessing resources in Windows NT domains.
The Kerberos version 5 protocol integrated with Windows 2000 is designed without the trusted server assumption and allows both the server and the client to verify the identity of each other. This process is known as mutual authentication.
Mutual authentication requires a trusted third party, the Key Distribution Center (KDC), to verify the identity of all participants. Before a network connection is opened between a client and a server (or between a server and a server), the KDC will verify the identity of each participant. After all identities have been verified, the KDC will ensure that each participant in the connection that the other participants are authentic.
Kerberos is based on the use of shared secret keys for authentication. The secret key is unique to each client because it is a hashed derivative of the user's logon password. When a user logs onto a Windows 2000 domain controller, the user's password is captured in volatile memory on the workstation and run through a one-way hashing algorithm to generate a key. The key is passed to the Key Distribution Center for verification. The KDC is a service that runs on all Windows 2000 domain controllers and uses password information in Active Directory to determine the identity of a client. At the KDC, the key information obtained from the workstation during logon is compared to the key entry for that user in the Active Directory. If the keys match, the user is authentic and the KDC replies by sending a special session ticket to the workstation called a ticket-granting ticket (TGT). Because both the client and the KDC are aware of the secret key, the authentication method is known as shared secret key.
The Microsoft implementation of Kerberos provides extensions to use private/public key pairs from a Certificate Authority for logon authentication. With this method, an additional layer of security is added because the client is identified using the shared secret key but must request a TGT using an X.509 private key certificate. The KDC validates the private key using the client's public key certificate stored in the user object of the Active Directory. After the authentication has completed, the client is issued a TGT. The private/public key method of Kerberos authentication is implemented only during the initial logon process. Subsequent connections with the KDC are negotiated using standard Kerberos protocols.
Every connection between a Windows 2000 client and Windows 2000 server (or service) requires a unique Kerberos session ticket. Before making a connection to a service, the client requests a session ticket for that service from the KDC. To save resources and processing requirements, the KDC does not maintain a list of all authenticated security principles. Instead, a ticket-granting ticket is given to the client during the initial authentication process. When a client later requests a session ticket for a service, the TGT is passed back to the KDC as evidence of the client's authenticity and capability to request session tickets. If the TGT is valid, a new session ticket for the requested service is generated and given to the client. The client uses this session ticket to authenticate with the target server, create a session, and access the requested service.
In reality, the client receives two copies of the session ticket from the KDC. The first copy is encrypted using the client's secret key. Included in the client's copy of the session ticket is a KDC-generated key that will be used to negotiate a session between the client and the target server. The decrypted session key information is placed in a secure cache on the client. By keeping a copy of the session ticket in cache, future connections to the same server will not require a request to the KDC for a new session ticket. Cached session tickets are valid for the length of time specified in the Kerberos policy for the domain.
TIP
You can view basic information on cached session tickets by using the KLIST utility in the Windows 2000 SDK.
In addition to the client copy of the session ticket, the client receives a copy to present to the target server. Included in the server copy of the session ticket is the session key, verification of the client's identity, and the user's access token (individual SID and group SIDs). The target server is the only principle capable of decrypting the server copy of the session ticket because it is encrypted by the KDC using the target server's secret key. After the target server has decrypted the ticket, verified the client's identity, and determined the client's access rights, a session is negotiated. If the client requested authentication of the target server (mutual authentication), an additional step is taken before the session is established. The target server encrypts the time stamp of the session ticket using the server's copy of the session key. This information is returned to the client and decrypted using the client's copy of the session key. If the decrypted time stamp matches the client's copy, the server is authentic because the session time stamp and session keys match.
TIP
Time synchronization within the domain is a critical component of Kerberos. All clients and servers should be configured for time synchronization with a reliable source. Windows 2000 comes with the Windows Time service and can be configured using the NET TIME command line and a new /SETSNTP: switch.
Kerberos authentication can play a foundational role in the security configuration of your Exchange organization. Kerberos surpasses the authentication capabilities of the NTLM protocol and helps ensure a more secure environment, especially when used in conjunction with X.509 certificates.
Trust Relationships
Kerberos is critical for the Windows 2000 implementation of domain trust relationships. Trusts enable clients from a trusted domain to access resources in a trusting domain. For example, a Software Spectrum user located in Garland who logs onto Domain A needs access to a resource in Domain B. Because Domain B, located in Los Angeles, has a trust relationship with Domain A, the Domain B resources are available to this user. In previous versions of Windows NT, all trust relationships were manually configured and were not transitive. For example, if A trusted B, and B trusted C, A did not automatically trust C. A separate trust relationship between A and C had to be created. Windows 2000 extends the trust model by providing transitive trusts in any Windows 2000 forest. Kerberos credentials issued in one domain of a Windows 2000 tree are accepted by Kerberos services in any other domain of that tree. In addition, any tree trusts the Kerberos credentials issued by any other tree in the Windows 2000 forest. This is considered a transitive trust environment.
For many organizations, not all domains will fall under the same Windows 2000 forest. Some companies will have multiple forests or retain several NT domains within the company. Trusts between these domains must be created manually. There are several types of trusts:
One-way—Domain A trusts domain B (A =>B). Users in Domain B (the trusted domain) can be granted access to resources in Domain A (the trusting domain). Users in Domain A cannot be granted access to resources in Domain B because B does not trust A.
Two-way—Domain A and Domain B trust each other (A<=>B). Both Domain A and Domain B are trusted and trusting domains. Users in either domain can be granted access to resources in the other domain.
Transitive—Transitive trusts are always two-way trusts and are accessible by any other domain that is trusted. For example, A<=>B, B<=>C; therefore, A<=>C.
Nontransitive—Nontransitive trusts do not extend to domains beyond the domains that established the trust. Trusts in Windows NT are nontransitive.
When authentication must occur between trusting Windows 2000 and Windows NT domains, nontransitive NTLM trusts are used for pass-through authentication. All trusts (with the exception of trusts automatically created within a forest) are created using the Domains and Trusts MMC snap-in for Active Directory. Right-click a domain, choose Properties, and change to the Trusts tab. From here you can add, edit, or remove trust relationships for the target domain.
Depending on your Exchange implementation, you might be required to manually establish trust relationships between domains in your organization. Ideally, you will be able to use the built-in transitive trusts between Windows 2000 domains.
Kerberos and Exchange
Kerberos is critical for Exchange 2000 security because it is the foundation for user authentication. Kerberos tickets ensure the identity of clients requesting access to the Exchange services and store. As mentioned earlier, access tokens are embedded in Kerberos session tickets and are used to determine permissions for specific Exchange resources.
One advantage of the Kerberos system will be realized in Outlook Web Access. A limitation with Exchange 5.5 Outlook Web Access (OWA) is that all OWA users must be granted Logon Locally rights to the OWA server(s). In addition, if the user's mailbox is housed on an Exchange server other than the OWA server, logon credentials must be passed using Basic (clear-text) authentication. SSL can be used to encrypt the logon session, but this is not enabled by default. The reasons for these configurations revolve around the incapability for NTLM credentials to be impersonated by the OWA server. Kerberos removes these limitations because session tickets can be used by a service to impersonate the user. A front-end server can securely access resources on behalf of the Kerberos-enabled client by presenting the user's authentication ticket in remote connections.