Windows Server 2003 Kerberos Extensions

Applies To: Windows Server 2003 with SP1

There are two new extensions in the implementation of the Kerberos protocol in Windows Server 2003:

• Protocol transition: The protocol transition extension allows a service that uses Kerberos to obtain a Kerberos service ticket on behalf of a Kerberos principal to the service without requiring the principal to initially authenticate to the Kerberos Key Distribution Center (KDC) with a credential.

• Constrained delegation: The constrained delegation extension allows a service to obtain service tickets (under the delegated users identity) to a subset of other services after it has been presented with a service ticket that is obtained either through the TGS_REQ protocol, as defined in IETF RFC 1510, or in the protocol transition extension.

  For more information about RFC 1510, see the IETF Web site (https://www.ietf.org).

Note

Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

The extensions that are included in Windows Server 2003 are described in the following sections of this document.

The Protocol Transition Extension

As mentioned in the previous section, the protocol transition extension allows a service to obtain a Kerberos service ticket to the service on behalf of a Kerberos security principal. No user credential is required for the transition. Applications may transition into Kerberos through two mechanisms that are described in this section.

The first method that you can use to transition to the Kerberos protocol is to call the LsaLogonUser Win32 function or directly instantiate a WindowsIdentity class object. The new KerbS4ULogon logon message type and KERB_S4U_LOGON logon information structure have been defined to support protocol transitioning through the LsaLogonUser function. A successful call to the LsaLogonUser function returns a Windows user token.

There is a new WindowsIdentity class constructor in the Microsoft .NET Framework assembly that s the LsaLogonUser function to help managed code applications use the Kerberos protocol extension features. The sample in this article uses this new WindowsIdentity class.

Two variations of user tokens may be returned, depending on whether the caller process has the Act as part of the operating system privilege. When the call is made from a process without the Act as part of the operating system privilege, an identification token is returned. When the caller process is assigned the Act as part of the operating system privilege, an impersonation token is returned. The Windows Server 2003 family includes a new SeImpersonatePrivilege privilege. Only processes that have this privilege can obtain impersonation-level tokens and use the tokens to impersonate the users to perform certain operating system functions. To use the full feature of the impersonation-level token that is obtained through protocol transition, the caller process that uses protocol transition must have both the SeImpersonatePrivilege and Act as part of the operating system privileges. If the caller process has only the Act as part of the operating system privilege, the impersonation-level token is downgraded to an identification-level token when it tries to impersonate by using the token. Basically, an identification token allows the process to determine the identity and privileges that are associated with a user, but an impersonation token also allows the process to take on the token users identity and operate in that users identity. The user token level does not directly determine whether the caller process can subsequently use constrained delegation to call other services. The caller process may use the service ticket that was obtained through protocol transition to obtain service tickets to other services if you correctly configure the service account to use the Kerberos constrained delegation extension. (The constrained delegation extension is discussed in more detail in the next section.)

The programmatic mechanism that is described above allows applications to initiate protocol transition. In addition, you should also configure the applications to run as services that use Kerberos. Programming and configuration tasks are discussed in more details later in this document.

The second method that you can use for applications to transition into Kerberos is through other existing Windows-integrated authentication protocols, such as HTTP basic, digest, or Secure Sockets Layer/Transport Layer Security (SSL/TLS). Some applications are designed to use non-Kerberos, Windows-integrated authentication protocols when the Kerberos protocol may not be the best option at the user-authentication tier. Subsequent application tiers may switch to Kerberos when it is needed and possible to do so. This concept is illustrated in Figure 1:

• In step 1, an application user is authenticated through a non-Kerberos authentication protocol that is integrated into the Windows operating system.

• In step 2, the security package creates a Windows user token for the authenticated user when the authentication is completed. Note that the user token is indirectly linked to a Kerberos service ticket for the user if the user is authenticated by the Kerberos protocol. If the user is not authenticated by Kerberos, no service ticket is associated with the user token.

• In step 3, the application impersonates the user and connects to a database server that requires Kerberos for authentication.

• In step 4, the Kerberos security package detects that there is no Kerberos ticket in the user token.

• In step 5, the Kerberos Security Support Provider (SSP) automatically initiates protocol transition by requesting a service ticket for the impersonated user.

  Figure 1: Protocol Transition from Windows-Integrated Authentication Protocols

Note

Two sample Web scenarios that you can use for Kerberos protocol transition are discussed later in this document.

The following network and operating system requirements must be met if you are using protocol transition in an Active Directory forest:

• You must run the operating system process that initiates protocol transition on a computer that is running Windows Server 2003

• All domain controllers that are used for protocol transition in the service and user account trust path domains must be running Windows Server 2003. There are two ways to accomplish this, and you can use either one:

  • You can upgrade all domain controllers in the domain to computers that are running Windows Server 2003

  • You can upgrade all domain controllers in Active Directory sites where domain controllers are used for protocol transition to computers that are running Windows Server 2003

To use protocol transition across Active Directory forests, the following additional requirements must also be satisfied:

• Both Active Directory forests must be running at the Windows Server 2003 forest functional level

• The forests must have established two way trusts across forests

The Constrained Delegation Extension

The reason why the constrained delegation extension is introduced in Windows Server 2003 can be best explained by describing the limitations in the Windows 2000 implementation of Kerberos delegation. In the Windows 2000 Kerberos delegation model, the Kerberos Key Distribution Center (KDC) does not limit the scope of services to which a Kerberos principal's identity can be delegated. In other words, after a service account is trusted for delegation, it can request service tickets on behalf of an authenticated user to any other service accounts. (See the Windows 2000 Kerberos Authentication white paper on the MSDN Web site for more technical information about the mechanics of delegation at https://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx.) This delegation method does not provide precise mechanisms for an application to specify a subset of service accounts that it determines to be trustworthy for delegation. Essentially, applications are exposed to broader impersonation risks that may span across resource domains that have different levels of security policy requirements; some of the security policies may not be as strict as the applications security requirements. From the domain administrators point of view, it is too risky to enable unconstrained Kerberos delegation in the enterprise because there is no way to exclude untrusted servers from participating in delegation.

With constrained delegation, domain administrators can configure service accounts so that they delegate only to specific sets of service accounts. On Active Directory that is running Windows Server 2003, a new Allowed-to-Delegate-to (A2D2) Active Directory attribute is added to service accounts to help enforce constrained delegation. The A2D2 attribute lists the service principal names (SPNs) of other service accounts to which a given service account is allowed to delegate. When a Windows Server 2003 KDC processes a service ticket request by using the constrained delegation extension, the KDC verifies that the target service account is listed in the A2D2 attribute. With the addition of constrained delegation, computers that are running Windows Server 2003 support two modes of delegation: Kerberos unconstrained delegation and Kerberos constrained delegation. Kerberos unconstrained delegation is supported if the user initially provides a user credential to obtain a ticket-granting ticket (TGT) that can be forwarded to a service that is trusted for delegation. This behavior is the same as the Windows 2000 behavior for Kerberos implementations. Constrained delegation can be used by a service if the service can obtain a Kerberos service ticket to itself for the user whose security context is to be delegated. It does not matter whether the user obtained the service ticket directly by authenticating through Kerberos, or whether the service obtained a service ticket on behalf of the user through the protocol transition extension. Note that constrained delegation works only in the boundary of a domain.

For a service account to use protocol transition in conjunction with constrained delegation, you must set a new control flag, Trusted-to-Authenticate-for-Delegation (T2A4D), on the service account in Active Directory. Only domain administrators can change the value of the control flag. If you set the flag for a service account, the account can use the protocol transition extension to obtain a service ticket that it can then use to obtain service tickets to a preconfigured subset of services that use Kerberos. In addition, you must not mark the impersonated user account as a sensitive account that cannot be delegated.

Enabling User Identification, Impersonation, and Delegation Through Extension Configurations

You can perform several security-related operations by using the extensions that have been discussed in this document. You can perform these security-related operations, even when a users Kerberos authentication credential is not available. For example, you can:

• Obtain both privilege and authorization information for a user.

• Impersonate a user by running an application request in a users identity.

• Make remote calls to a set of preconfigured Kerberos service instances in a given users identity.

Whether an application can perform one or all of the above operations is based on how you configure the service account. As discussed earlier in this paper, an application can initiate protocol transition by using two mechanisms: by programmatically invoking the LsaLogonUser function or automatically through the Kerberos SSP. The necessary conditions for protocol transition to take place are different for the two mechanisms.

Scenario A, Scenario B, Scenario C, and Scenario D in Figure 2a, Figure 2b, Figure 2c, and Figure 2d illustrate the successful results that can occur when you call the LsaLogonUser function with different service account configurations.

In Scenario A in Figure 2a, protocol transition allows a service without the Act as part of the operating system privilege to obtain an identification-level token that works only for making application authorization decisions. In this scenario, the Act as part of the operating system service account does not have the Trusted-to-Authenticate-for-Delegation (T2A4D) permission and the service ticket that is issued does not have the Forwardable flag set. A ticket that does not have the Forwardable flag set cannot be used for a constrained delegation operation.

Figure 2: a Scenario A: Service Account Does Not Have TCB and the T2A4D Flag Is Not Set

In Scenario B in Figure 2b, the service account has the Act as part of the operating system privilege and protocol transition allows the service to obtain an impersonation token. As noted previously, the service process must also have the SeImpersonatePrivilege privilege to use the impersonation token so that it can run in the users identity. You do not want any arbitrary service to be able to impersonate and run as other users. Because of this, the service must have both the Act as part of the operating system and SeImpersonatePrivilege privileges that can be assigned only by members of the local administrators group. Only local administrators can give those services the ability to impersonate users on the computers where the services are running. Like Scenario A in Figure 2a, the Kerberos service ticket that is obtained by the service account in Scenario B does not have the Forwardable flag set and therefore the ticket cannot be used for constrained delegation.

Figure 2: b Scenario B: Service Account Has TCB and the T2A4D Flag Is Not Set

The T2A4D control flag is set for the service account on Active Directory by domain administrators and is independent of Act as part of the operating system privileges on the local computer. In Scenario C in Figure 2c, the KDC that issues the service ticket does not check to see if the calling process has either the Act as part of the operating system or SeImpersonatePrivilege privileges when processing a service ticket request by using the protocol transition extension. Because of this, the KDC issues a service ticket with the Forwardable flag set if the T2A4D control flag is set. This service ticket is accepted by a KDC for constrained delegation requests if both the requesting and target services are in the same domain and the target service (SPN) is listed in the requesting services A2D2 attribute in Active Directory.

Figure 2: c Scenario C: Service Account Has TCB and the T2A4D Flag Is Set

In Scenario D in Figure 2d, the service ticket is issued with the Forwardable flag set and the created user token is an identification-level token because the service does not have the Act as part of the operating system privilege. Although the service ticket allows constrained delegation, the service cannot use the identification-level token to impersonate the user. Most practical applications require an impersonation-level token to perform network-related operations before authenticating as the delegated user. Because of this, the service cannot impersonate the user and use the service ticket for constrained delegation for most applications.

Figure 2: d Scenario D: Service Account Does Not Have TCB and the T2A4D Flag Is Set

In situations where protocol transition is initiated by the Kerberos Security Support Provider (SSP) as in the scenario shown in Figure 1(for example, not by directly calling the LsaLogonUser function or the WindowsIdentity class object), an impersonation-level user token must already exist for that user before the Kerberos SSP tries to perform protocol transition. The impersonation-level user token could be created previously by any of the Windows-integrated SSPs. The service must also have the SeImpersonatePrivilege privilege to impersonate the user and initiate the protocol transition extension through the Kerberos SSP. Subsequently, the services ability to perform constrained delegation is determined by the Active Directory policies and the state of the Forwardable flag in the service ticket that is issued through protocol transition. The Active Directory policy checks that are used by the KDC to issue service tickets that are enabled for constrained delegation are the same as the flags that were previously described (for example, the T2A4D and A2D2 flags).

Sample Web Service Scenarios

Figure 3 displays two simple Web service scenarios that illustrate how the Kerberos features work.

The first sample scenario illustrates where protocol transition is initiated by the Kerberos SSP. The scenario consists of a browser client that invokes an ASP.NET Web service that, in turn, calls a stored procedure on a computer that is running Microsoft SQL Server.

The second sample scenario illustrates how protocol transition works by programmatically instantiating a WindowsIdentity class object. In this scenario, the browser client is used to navigate through an ASP.NET Web application that invokes the same SQL Server stored procedure that is invoked in the first sample scenario.

Both scenarios are configured to use an Active Directory forest with a single-domain Kerberos Key Distribution Center (KDC). Note that you can run both the ASP.NET Web service and application from different virtual directories of the same computer that is running Microsoft Internet Information Services (IIS).

For the sample scenarios to work, Active Directory must run on Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition. Also, IIS must run on Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; or Windows Server 2003, Web Edition. The computer that is running SQL Server 2000 must run Windows 2000 Professional, Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, or a later version of Windows.

Sample Scenario One

Sample scenario one illustrates the following authentication flow:

1. The user is initially authenticated to the Web service through a non-Kerberos Windows authentication protocol. This sample scenario uses Hypertext Transfer Protocol (HTTP) digest authentication.

2. The Web service impersonates the authenticated Windows user before connecting to the SQL server.

3. The Web service tries to open a connection to the SQL server, and is challenged to prove its identity.

4. The Kerberos authentication package that is running on the same computer as the Web service cannot find a Kerberos ticket for the impersonated user and, therefore, uses protocol transition to obtain a service ticket to the Web service in the impersonated user context.

5. The Web service uses constrained delegation to obtain a service ticket to the SQL server. When this occurs, the authentication is completed in the impersonated user identity.

For demonstration purposes, the Web service uses HTTP digest authentication for initial user authentication. Although the sample uses digest authentication, you can easily modify the sample to support protocol transitioning from other Windows-integrated authentication protocols by changing the IIS directory security configuration.

The sample Web service supports the public TestKerbSfu method that the browser client invokes. This Web service method then invokes the GetUserInfo SQL server stored procedure that returns the identity of the user who invoked the stored procedure. The Web methods final return value is a string that contains the caller identities of the Web service and stored procedure. If you set up the sample that is described in this document, the two user identities that are in the return string are identical and they reflect the domain user account under which the Web service and stored procedure code operates.

In this scenario:

1. The browser gains accesses to the Web service with a URL such as https://www.fabrikam.com/KerbExtWebSvc/authxws.asmx?op=TestKerbSfu.

2. The browser displays an authentication dialog box that prompts for the user name and password to authenticate to the Web server.

3. The user name and authentication credential is sent to the server on which IIS is running to host the Web service.

4. IIS performs the HTTP digest authentication before forwarding the Web service request to the .NET Framework .asmx handler.

5. Before establishing the connection to the SQL server, the Web service impersonates the authenticated user and transitions into the Kerberos protocol by obtaining a Kerberos service ticket to the Web service.

The Web service uses Kerberos constrained delegation to obtain a service ticket to the SQL server in the authenticated browser users identity.

Figure 3: Sample Scenarios

Sample Scenario Two

Sample scenario two illustrates a slightly different method that you can use to use the Kerberos protocol transition extension. In this scenario, the Web service is replaced by an ASP.NET Web application that uses ASP.NET form-based authentication to authenticate users. The Web application goes through a series of interactive steps to show you how an application can use an authentication protocol that is not integrated in the Windows operating system to authenticate the Web users and then transition into Kerberos to authenticate to backend services, such as the SQL server that was used in sample scenario one.

The Web application illustrates the following authentication flow:

1. The browser client navigates to the virtual directory of the sample and is redirected to the login Web form.

2. The user types a user name and password in the login Web form, and then clicks Login.

3. The login Web page authenticates the user by using a custom authentication mechanism (for example, by checking a hashed password that is stored in a SQL server database), and then issues a login cookie to the browser when the authentication is successful. The user is then redirected to the default Web page for the Web application.

4. The user types a unique principal name (UPN) to be used for Kerberos protocol transition, and then the user clicks Do protocol transition.

5. The Web application transitions into Kerberos by using the specified UPN, and then saves the Kerberos security context in the Web application session state.

6. The user has the option to connect to the SQL server if they click Invoke SQL Server. When the user clicks this option, the Web application retrieves the user context from the application session state, and then the Web application impersonates the user before connecting to the SQL server.

7. When the Web application is challenged by SQL server to authenticate, the Web application uses Kerberos constrained delegation to obtain a service ticket to the SQL server in the impersonated user identity.

8. The Web application returns a response string that shows the impersonated user identity and the user identity that is authenticated on the SQL server.