Starting with Windows 2000, Microsoft provides support for the Kerberos authentication protocol. Kerberos is an open and proven authentication protocol defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 1510. Kerberos has many useful security features, including support for mutual authentication and smart card logon. Because many platforms have a Kerberos implementation, you can use Kerberos as a single sign-on (SSO) solution. Kerberos also supports delegation, aka authentication forwarding. The new Kerberos delegation features that Microsoft has embedded in Windows .NET Server (Win.NET Server) 2003 make Kerberos an even better choice for user authentication in a Windows environment. (A basic understanding of the Kerberos authentication protocol will help as you read about Win.NET Server's Kerberos implementation. For a Kerberos primer, see the Windows & .NET Magazine article "Kerberos in Win2K," http://www.winnetmag.com, InstantDoc ID 7193.)
The Power of Delegation
Delegation refers to a service's ability to impersonate an authenticated user so that the user doesn't need to authenticate to multiple services. In other words, the user authenticates to one service, and that intermediary service authenticates on the user's behalf to other services. The latter services think they're communicating directly with the user, whereas in reality, an intermediary service sits between them and the user.
A classic example of delegation's usefulness is a user asking a print server to print a file that's on another server. Without delegation support, the print server must use its identity to authenticate to the file server and consequently might be denied access to the file. With delegation support, the print server can use the user's identity to access the file. Today's Internet-oriented world provides many more examples. Any Web-based multi-tier application—a Web site that passes user queries to a database on a back-end server, a user who uses a Web interface such as Microsoft Outlook Web Access (OWA) to check his or her mailbox—can take advantage of delegation.
In the future, as Web services become widespread, the need for authentication delegation will only increase. Web services require highly distributed architectures that can make data and other resources available to a wide range of users, who typically use open Internet protocols such as HTTP and SMTP to access Web services. In such environments, hosting the data on the Web servers isn't a good option. Web services require multi-tier application designs and the ability to reuse a user's identity from one end of the application to the other (i.e., end-to-end).
The ability to refer to a user's identity end-to-end in a multi-tier application scenario means that administrators can establish on the different tiers access-control settings that recognize the same user identity. Using one user identity not only simplifies management but also facilitates user tracking and auditing on the different levels of a multi-tier application. Delegation also provides users the benefit of SSO.
Kerberos can support delegation because of its unique ticketing mechanism. When sending a ticket to a server, the Kerberos client can add information that the server can reuse to request other tickets on the user's behalf from the Kerberos Key Distribution Center (KDC). For example, the print server that accesses a file on behalf of a user can use an existing user ticket that the user machine forwarded to the print server to request a new ticket from the KDC. This new ticket gives the print server access to the file.
What's Missing in Win2K Kerberos Delegation?
One reason that Kerberos delegation is rarely used in Win2K is that few people really understand it. Another reason is that the Win2K implementation lacks some important security-related configuration options.
In Win2K, when a computer is trusted for delegation, it can impersonate a user to any other service on any other computer in the Win2K domain. In other words, when a Win2K administrator trusts a computer for delegation, the delegation is complete; no configuration options can make the delegation more granular. For example, to retrieve user-specific data from a Microsoft SQL Server database server, a Win2K Web application server's computer account must be trusted for delegation. However, the Win2K Web application server isn't limited to retrieving data from the SQL Server database on the user's behalf; it can also contact other servers, such as file servers or other application servers, in the user's name and retrieve other data or execute transactions without the user's knowledge. The exposure could get even worse if the Web application server were used by a dishonest internal Web programmer or compromised by an external intruder.
Another obstacle is that Kerberos delegation in a Win2K Web scenario works only when the user uses Kerberos or Basic authentication to authenticate to the Web server. If you prefer to use the more secure Digest authentication protocol to authenticate your users to the Web server, you can't use delegation. The Digest authentication protocol (which Microsoft Internet Explorer—IE—5.0 and Microsoft Internet Information Services—IIS—5.0 and later support) is a challenge-response authentication protocol that (unlike Basic authentication) transmits the user's credentials in an encrypted format across the HTTP connection. You also must keep in mind that you can use Kerberos between a browser and a Web server only if the browser supports Kerberos and can access the Kerberos KDC. The latter requirement is clearly a problem in Internet scenarios: Few companies are willing to expose their KDC to Internet users. Also, the only Kerberos-enabled Web browser is IE 5.0 and later.
In Win.NET Server, Microsoft embedded a pair of new Kerberos protocol extensions—called the Service-for-User (S4U) extensions—to remedy these problems. The S4U extensions are the Service-for-User-to-Proxy (S4U2Proxy) extension and the Service-for-User-to-Self (S4U2Self) extension. Microsoft says it plans to submit the specifications of both new Kerberos extensions to the IETF soon. The new Kerberos extensions are available only if your Win.NET Server domain is at Functionality Level 2 (the native Win.NET Server functionality level)—which basically means that all the domain controllers (DCs) in the domain are running Win.NET Server.
The S4U2Proxy Kerberos Extension
Win2K delegation lets a Kerberos client forward a user's ticket-granting ticket (TGT) to a service. A Kerberos TGT is a powerful security token—a digital piece of evidence that proves that the Kerberos KDC has validated a user's identity and enables the user to request service tickets. In Win2K, a service can use a TGT to obtain a service ticket for the service itself and for other services on the user's behalf. The possessor of a TGT is even more powerful in Win2K because Microsoft uses the TGT to transport user-related access-control data (this data, embedded in a ticket's Privilege Attribute Certificate—PAC—field, includes a user's universal and global group memberships).
The S4U2Proxy extension lets a service reuse a user's service ticket to request a new service ticket from the KDC. In other words, there's no more need to forward a user's TGT to the service—as was the case in Win2K. The simple fact that the service can present a user's ticket to a KDC is enough to prove a user's identity to the KDC.
As described thus far, the S4U2Proxy feature has the same security hole as Win2K: The intermediary service can access any other service on any authenticated user's behalf. To close the hole, Microsoft added support for fine-grain delegation configuration. In Win.NET Server, an administrator can configure which services a machine or service is allowed to access on a user's behalf.
Configuring Constrained Delegation
When you open the properties of a machine or a service account in Win.NET Server (from the Microsoft Management Console—MMC—Active Directory Users and Computers snap-in, you'll notice the new Delegation tab. This tab isn't available in a plain user account's Properties dialog box—it shows up only when the account has an associated Service Principal Name (SPN).
As Figure 1 shows, you can use the Delegation tab to configure delegation in three ways:
- Select the Do not trust this computer for delegation option to disallow delegation.
- Select the Trust this computer for delegation to any service (Kerberos only) option to allow complete delegation similar to what Win2K supports. This option is the default.
- Select the Trust this computer for delegation to specified services only option for constrained delegation. This option is new with Win.NET Server.
If you select the third option (constrained delegation), you can select the services for which delegation is allowed. Click Add to open the Add Services dialog box. Initially, no services are listed. Click Users or Computers to open the Active Directory (AD) Object Picker dialog box, from which you can select the appropriate SPNs. You can select the SPNs only of machines that are members of your machine's domain. In Figure 1, for example, you can see that I selected the SPNs of a set of Lightweight Directory Access Protocol (LDAP) services running on the DCs of the Qnet domain.
Win.NET Server stores the SPNs for which you want to allow delegation in a new AD account object attribute called msDS-AllowedToDelegateTo. You can use the Win.NET Server Support Tools' ADSI Edit tool (which is an MMC snap-in) to examine the content of this multivalued attribute. Web Figure 1 (http://www.secadministrator.com, InstantDoc ID 26450) shows the SPNs of the LDAP services for which I let computer Qnet-dc9 be trusted for delegation. When the Kerberos authentication services receive a delegation request for a ticket for a particular service, they compare the SPNs in the Kerberos ticket request with the ones in the computer or service account's msDS-AllowedToDelegateTo attribute. If no matches exist, the Kerberos authentication services deny the delegation request. An account's SPNs are stored in the servicePrincipalName attribute.
The S4U2Self Kerberos Extension
You face a significant problem when you use Kerberos delegation in a Web-based Win2K environment: The client must use Kerberos or Basic authentication to authenticate to the Web server. IIS 6.0, the Web server that ships with Win.NET Server, comes with other authentication options such as Microsoft .NET Passport, Digest, or Certificate authentication. In Win.NET Server, you can use these authentication options with Kerberos delegation, thanks to the combination of the S4U2Proxy and S4U2Self Kerberos extensions.
The S4U2Self extension provides a service known as protocol transition, which permits the combination of any of the IIS authentication protocols listed above on the IIS front end with the Kerberos authentication protocol on the IIS back end. In other words, no matter how a user authenticates to IIS, IIS can use the user's identity with Kerberos authentication and delegation to reach a back-end server. Behind this new extension is the ability for an application or service to request from the Kerberos KDC a new service ticket on behalf of a user account defined in the domain or the forest, independent of the authentication protocol used on the front end. If what I describe here sounds like a dangerous passwordless logon, remember that before an application or service can request a service ticket on a user's behalf from the KDC, the application or service must already have authenticated the user. Also, the application or service must hold a valid Kerberos TGT.
Configuring Protocol Transition
Configuring protocol transition is relatively easy. You use the Use Kerberos only and Use any authentication protocol options in Figure 1 to disable protocol transition or enable it, respectively.
For protocol transition to function correctly, the service account of the service or application that's requesting a new ticket on the user's behalf must meet the following two conditions. First, the service account must have the Act as part of the operating system privilege. Otherwise, the service will receive only an identification token, not an impersonation token, from the KDC.
Second, to add the user's access-control data to the newly constructed user ticket, the service account needs permission to enumerate the user's group memberships. To give the service account this permission, add the account to the ACL of the TokenGroupsGlobalAndUniversal user object attribute or add the account to the Pre-Windows 2000 Compatible Access group.
A Sample Scenario
You can test the new Kerberos services in a small lab environment. Figure 2 shows my test scenario, which consisted of a client running a Web browser, a simple COM+ application running on an IIS 6.0 server, and a SQL Server database on a back-end server. An Active Server Pages (ASP) page called a database query defined in the COM+ application. The client, the IIS server, and the SQL Server system were all members of the same domain.
The goal of this test scenario from an authentication point of view was to let the user use any supported authentication protocol to authenticate to IIS and to have IIS use Kerberos and Kerberos delegation to authenticate to the COM+ application and the SQL Server database. This setup works only if the new S4U2Proxy and S4U2Self Kerberos extensions are available on IIS (i.e., if your Web server is running Win.NET Server). Table 1 summarizes the necessary software and configurations.
The Kerberos protocol extensions in Win.NET Server emphasize the important role Kerberos will have in future Microsoft infrastructures. The extensions let Web service consumers use any authentication protocol to authenticate to a Microsoft-based Web service. On the back end, the extensions let Web services exploit Kerberos and its SSO and delegation capabilities to the maximum extent.
