What's New in Windows Server 2003 Kerberos Authentication
|
On This Page
 | Introduction |
| Benefits |
Introduction
This page outlines the new features in Kerberos authentication in Windows Server 2003 and provides the basic information necessary to begin using these new features.
The information is designed to benefit administrators who will be testing and deploying Windows Server 2003. No Kerberos authentication features that were available in Windows 2000 have been discontinued or moved to other product lines.
Benefits
| New Feature | Description | ||||||||
No Computer Account Needed for Windows XP Client Logon | Normally, a computer account is required for Kerberos authentication. A user must obtain a service ticket for the computer in order to gain access to the computer's resources. Without this user-to-host authentication, the host computer must perform access control based on mapping the user name to a name that it maintains in its local account database. The user must run KSETUP to set up a local mapping. | ||||||||
SPNs No Longer Canonicalized | In the past, SPNs were canonicalized to the Security Accounts Manager (SAM) account name (for example, mycomputer$). This caused problems when a user requested a service with a non-canonical name—the system was unable to detect that it had a cached ticket for a service and thus would request a new service ticket. Now, the solution is to just use the SPN that was requested (with no name canonicalization). | ||||||||
SPN Must Be Set for Security Principal Acting as a Service for the Key Distribution Center (KDC) To Issue a Service Ticket | This means that the KDC will not issue a service ticket for an account that does not have an SPN (such as a user account). The motivation for this is that it would make it easier to mount an offline dictionary attack against a service if that service were just a user account with a human-generated password. For an account that does not have an SPN, the KDC will return an error indicating that User-2-User is required. | ||||||||
Client Address Verification Enhanced | The Windows 2000 KDC will check the addresses in tickets if they are present. However, the Windows 2000 KDC will not put requested addresses into the ticket. By default, The Windows Server 2003 KDC remains compatible with Windows 2000 clients. The Windows Server 2003 KDC will not propagate the addresses in the AS-REQ to the ticket unless a new registry entry is made (HKLM/System/CCS/Services/Kdc/KdcUseClientAddresses with DWORD value of 1). When a ticket is presented to the ticket-granting service (TGS), the address will be checked if they are present. In Windows Server 2003, this can be disabled by adding a registry entry (HKLM/System/CCS/Services/Kdc/KdcDontCheckAddresses with DWORD value of 0). The default is to check them if present to remain compatible with Windows 2000. Administrators can configure the two new Windows Server 2003 KDC features by adding the following entries in the registry: HKLM/System/CCS/Services/Kdc/KdcUseClientAddresses Controls whether the KDC will propagate client addresses to tickets.
HKLM/System/CCS/Services/Kdc/KdcDontCheckAddresses Controls whether the KDC will check client addresses.
| ||||||||
Key Version Number Option Supported | Key version numbers are an optional part of the Kerberos specification. They may be included as part of the Kerberos encrypted data when that data is encrypted with a long-lived key. Windows Server 2003 introduces the use of key version numbers. For details about key version numbers, see the Windows Server 2003 Technical Reference. | ||||||||
Encryption Type Selection | In Windows 2000, the KDC selects the first encryption type. In Windows Server 2003, the KDC selects the strongest encryption type supported by the client. | ||||||||
TGT Renewal with Windows XP and Windows 2000 with SP2 or Later | The TGT has a default lifetime of ten hours, but can be renewed for up to seven days (by default). The renewal does not require credentials. The renewal will only occur if the TGT is used within five minutes of its expiration. Otherwise, the TGT will expire and must be refreshed (which requires credentials). | ||||||||
TGT Renewal with Windows Server 2003 | The TGT has a default lifetime of ten hours, but can be renewed for up to seven days (by default). The renewal does not require credentials. The renewal occurs through the use of a scavenger thread on the machine. If for some reason the TGT was not able to be renewed it will expire and must be refreshed (which requires credentials). In Windows XP and Windows 2000 with SP2 or later, TGT renewal is triggered when the TGT is used within 5 minutes of its expiration. In Windows Server 2003, periodically the system will automatically renew expiring TGTs. | ||||||||
Constrained Delegation | Kerberos has always provided the mechanism to allow a client to delegate its ticket-granting ticket to an intermediary server. This would allow the intermediary to obtain service tickets to other services on behalf of the client. For example, such delegation enables an intermediary in a three-tier scenario to impersonate the client to an end application. However, this mechanism enables the intermediary to obtain tickets to any service as the client. Constrained delegation is a feature in Windows Server 2003 by which the domain controller will issue tickets to an intermediary to only those services that the intermediary is authorized to obtain delegated tickets (as determined by administrative policy). Thus, the delegation capability of an intermediary is constrained by administrative policy. | ||||||||
Constrained Delegation with Protocol Transition | Protocol transition is a feature that allows an intermediary to request a ticket without requiring the client to initially authenticate with Kerberos authentication. Thus, a client could use Secure Sockets Layer (SSL) to authenticate to the intermediary and the intermediary would use Kerberos authentication to the end application. For details, see Kerberos Protocol Transition and Constrained Delegation. | ||||||||
Forest Trusts | Many organizations deploy multiple forests but require collaboration across forests in different organizations. When this occurs, establishing an external trust relationship requires an enormous amount of management and does not use the newest technological advances. Windows Server 2003 introduces the concept of the forest trust to make multiple forest deployments easier. The forest trust allows administrators to federate two Active Directory forests with a single trust relationship to provide a seamless authentication and authorization experience across the forests. For details, see Planning and Implementing Federated Forests in Windows Server 2003. |