The following excerpt, courtesy of Elsevier Digital Press, is from Chapter 5 of the book "Windows Server 2003 security infrastructures" written by Jan De Clercq. Click for the complete book excerpt series or purchase the book.
Advanced Kerberos topics
In this section we will focus on some advanced Kerberos topics: delegation of authentication, the link between authentication and authorization, the content of Kerberos tickets and authenticators, the details behind the smart card logon process, Kerberos transport protocol and port usage.
To help you navigate this excerpt more quickly and easily, please use the following guide.
Delegation refers to the facility for a service to impersonate an authenticated client in order to relieve the user of the additional burden of authenticating to multiple services. To the latter services it will look as if they are communicating directly with the user, whereas in reality another service will sit between them and the user.
A classical example of where delegation is a very useful feature is when a user asks a print server to print a file that is located on another server. In today's Internet world there are many more examples. Basically, any Web-based multitier application can take advantage of delegation. Examples are Web sites launching user queries against a database located on some backend server, or a user accessing his or her mailbox from a Web interface [a good example is Microsoft's Outlook Web Access (OWA)]. In the future, when Web services become widespread, the need for authentication delegation support will only become bigger. Web services are rooted on highly distributed architectures that can make data and other resources available to a wide range of users. Web services are typically accessed using open Internet protocols (such as HTTP and SMTP). In such environments it would not be a very smart idea to host the data on the Web servers. Web services require multitier application designs and the ability to reuse the user identity end-to-end.
The ability to refer to a user's identity end-to-end in a multitier application scenario is one of the key advantages of the Kerberos delegation support. It means that administrators can enforce authorization settings at the different tiers using a single user identity. This not only simplifies management but also facilitates user tracking and auditing on the different levels of a multitier application. Finally, because of its ability to transparently authenticate a user on multiple tiers, delegation provides SSO support.
Kerberos' ability to support delegation is a consequence of its unique ticketing mechanism. When sending a ticket to a server, the Kerberos client can add additional information to it so the server can reuse it to request other tickets on the user's behalf to the Kerberos KDC.
The Kerberos delegation uses specific flags that can be set in a Kerberos ticket. The Kerberos standard (RFC 1510) defines four types of flags, shown in Table 5.2. Windows 2000 and Windows Server 2003 currently only support the "forwardable" and "forwarded" flags. Notice in Table 5.2 that "forwardable" is a much more powerful concept than "proxiable:" A forwardable ticket is a TGT, a proxiable ticket is a plain ticket; a ticket can be used for one single application, and a TGT can be used for multiple applications.
One of the reasons why Kerberos delegation in Windows 2000 is only used rarely is because few people really know and understand it. Another reason is that the Windows 2000 implementation lacks some important securityrelated configuration options.
In Windows 2000, when a computer is "trusted for delegation," it can impersonate a user to any other service on any other computer in the Windows 2000 domain. In other words, when a Windows 2000 administrator trusts a computer for delegation, the delegation is "complete;" there are no configuration options to make the delegation more granular.
Another obstacle is that Kerberos delegation in a Windows 2000 Web scenario only works if the user has authenticated to the Web server using Kerberos or Basic authentication. There is no way to use delegation when you prefer to use the more secure digest authentication protocol to authenticate your users to the Web server. We also have to keep in mind that the use of Kerberos between a browser and a Web server is only possible when the browser supports Kerberos and the Kerberos KDC is accessible from the browser. The latter is clearly a problem in Internet scenarios: Very few companies are willing to expose their KDC to Internet users. Also, on the Internet, not every user has a Kerberos-enabled Web browser. So far, only Microsoft's Internet Explorer (from version 5.0 on) is Kerberos-enabled. In Windows Server 2003, Microsoft embedded a set of Kerberos protocol extensions to remedy these problems. These extensions are referred to as the "Service-for-User" (S4U) Kerberos extensions. There are two new extensions: the Service-for-User-to-Proxy extension (S4U2Proxy) and the Service-for-User-to-Self extension (S4U2Self). Microsoft is planning to submit the specifications of both Kerberos extensions to the IETF some time in the near future.
The new Kerberos extensions are only available if your Windows Server 2003 domain is in Functionality Level 2 (which is the native Windows Server 2003 functionality level).
The way that delegation works in Windows 2000 is by letting a Kerberos client forward a user's TGT to a service. In Kerberos-speak, a TGT is a very powerful security token: It is a digital piece of evidence that proves that a user's identity has been validated by the Kerberos KDC. A service can use a TGT to get many other service tickets on the user's behalf. This is why in Windows 2000 delegation is considered "complete." What makes the possessor of a TGT even more powerful is the fact that in Windows 2000 Microsoft uses the TGT to transport user-related authorization data [embedded in the Privilege Attribute Certificate (PAC) field].
The S4U2Proxy Kerberos Extension allows a service to reuse a user's "service ticket" to request a new service ticket to the KDC. In other words, there is no more need to forward a user's TGT to the service. The simple fact that the service can present a user's ticket to a KDC is enough to prove a user's identity. The Kerberos exchanges occurring in a typical S4U2Proxy scenario are illustrated in Figure 5.20.
In Figure 5.20 steps 1 through 3 illustrate the Kerberos exchanges related to a user authenticating to server 1.
- Step 1: The user requests a service ticket for server 1 to the KDC (Kerberos TGS_REQ message).
- Step 2: The KDC returns a service ticket for server 1 to the user (Kerberos TGS_REP message).
- Step 3: The user presents the service ticket for server 1 to server 1 (Kerberos AP_REQ message).
- Server 1 then needs to access a resource on server 2 on the user's behalf. Server 1 is running Windows Server 2003 and thus supports the S4U2Proxy extension.
- Step 4: The S4U2Proxy extension on server 1 requests a service ticket for server 2 to the KDC on the user's behalf. To prove the user's identity to the KDC, server 1 presents the user's service ticket for server 1 (Kerberos TGS_REQ message).
Basic S4U2Proxy operation.
- Step 5: The KDC returns a service ticket for server 2 to server 1. Even though this new ticket is passed to server 1, it contains the user's authorization data (Kerberos TGS_REP message).
- Step 6: Server 1 presents the service ticket for server 2 to server 2 (Kerberos AP_REQ message).
If a service could do this with any user ticket it receives, the S4U2Proxy feature would create a security hole: The service would be allowed to access any other service on the user's behalf. That is why Microsoft has added support for fine-grain delegation configuration. In Windows Server 2003 an administrator can configure which services a machine or service is allowed to access on a user's behalf. How to set this constrained delegation up is explained in the next section.
When you open the properties of a machine or a service account in Windows Server 2003 (from the Users and Computers MMC snap-in), you will notice the new "Delegation" tab. This tab is not available in the properties of a plain user account. It only shows up if the account has an associated SPN. From the Delegation tab you can configure delegation in three different ways (as illustrated in Figure 5.21):
Configuring delegation in Windows Server 2003.
- Disallowed: This is done by checking the "Do not trust this computer for delegation" option.
- Allowed for all services: This can be done by checking the "Trust this computer for delegation to any service (Kerberos only)" option. This is the default option and refers to delegation the way it was available in Windows 2000.
- Only allowed for a limited set of services: This can be done by checking the "Trust this computer for delegation to specified services only" option. This is the new "constrained" delegation option coming with Windows Server 2003.
When selecting the latter option (constrained delegation), you can select the SPNs of the services for which the delegation is allowed. You can do so using the "Add..." push button. Pushing this button will bring up the "Add Services" dialog box. Initially, the available services list in this dialog box appears empty. To fill the list, press the "User or Computers..." push button. The latter will bring up the Active Directory object picker dialog box, which will allow you to select the appropriate SPNs. You can only select the SPNs of machines that are a member of the machine's domain. The SPNs for which delegation is allowed are stored in a new AD account object attribute called "msDS-AllowedToDelegateTo." You can examine the content of this multivalued attribute using the Support Tools "AdsiEdit" tool (as illustrated in Figure 5.22). When the Kerberos authentication service receives a delegation request for a ticket for a particular service, it compares the SPNs listed in the Kerberos ticket request with the ones listed in the computer or service account's "msDS-AllowedToDelegateTo" attribute. If there are no matches, the delegation request is denied. Remember that an account's SPNs are stored in the "servicePrincipalName" attribute.
In the scenario illustrated in Figure 5.20, you would set up constrained delegation in the account properties of server 1. You would trust server 1 for delegation to the SPN of server 2.
The new "msDSAllowedToDelegateTo" AD account attribute enabling constrained delegation.
An important problem when using Kerberos delegation in a Web-based Windows 2000 environment is that it can only be used when the client uses Kerberos or Basic authentication to authenticate to the Web server. The Web server (IIS 6.0) that ships with Windows Server 2003 comes with many other interesting authentication options, such as MS Passport–based, Digest-based, or certificate-based authentication. In Windows Server 2003 you can use the latter authentication options together with Kerberos delegation thanks to the combination of the S4U2Proxy (explained earlier) and another new Windows Server 2003 Kerberos extension called Service-for- User-to-Self (S4U2Self).
The service provided by the S4U2Self extension provides a service known as "protocol transition." It allows for the combination of any of the IIS authentication protocols listed earlier on the IIS front end with the Kerberos authentication protocol on the IIS back end. In other words, the Web server can use Kerberos authentication and delegation with a user's identity to a back-end server independently of how the user authenticated to the Web server. Behind this new extension there is nothing else than the ability for an application or service to request to the Kerberos KDC a new service ticket on behalf of a user account defined in the domain or the forest. If this appears to you as a dangerous password-less logon process, keep in mind that before an application or service is allowed to request a service ticket on a user's behalf, it must already have authenticated the user. Also, the application or service itself must hold a valid Kerberos TGT. The basic operation of the S4U2Self Kerberos extension is illustrated in Figure 5.23.
In Figure 5.23, step 1 illustrates the user authenticating to server 1. When server 1 is an IIS6.0 Web server, he or she can do so using Digestbased, Basic-based, MS Passport–based, or client certificate–based authentication.
In steps 2 through 3 server 1 requests a Kerberos ticket for server 1 on the user's behalf.
Basic S4U2Self operation.
- Step 2: The S4U2Proxy extension on server 1 requests a service ticket for server 1 to the KDC on the user's behalf (Kerberos TGS_REQ message).
- Step 3: The KDC returns a service ticket for server 1 to server 1. Even though this new ticket is passed to server 1, it contains the user's authorization data (Kerberos TGS_REP message).
This clearly illustrates the authentication "transition:" A user who was initially authenticated to server 1 using another authentication protocol is transparently authenticated to server 1 using the Kerberos protocol. Once the user has authenticated using Kerberos to server 1 and the KDC has issued a service ticket for server 1, server 1 (in fact, the S4U2Proxy extension) can reuse this ticket to request a ticket for server 2 on the user's behalf. This combined S4U2Self and S4U2Proxy operation is shown in Figure 5.24.
Combined S4U2Self operation and S4U2Proxy operation.
Configuring protocol transition is relatively easy. So far I did not explain the "Use Kerberos only" and "Use any authentication protocol" configuration options (as illustrated in Figure 5.21). These are exactly the options that enable or disable the S4U2Self Kerberos extension. If you select "Use any authentication protocol," protocol transition will be possible; if you select the other one, it will not.
In order for protocol transition to function correctly, the following two conditions should also be met. They are both related to the service account of the service or application that is requesting a new ticket on the user's behalf.
1. In order for the service to obtain an impersonation token, its service account should have the "act as part of the operating system" privilege. If this is not the case, the service will only get an identification token.
2. In order to get the user's authorization data into the newly constructed user ticket, the service account also needs permission to enumerate the user's group memberships. This can be done by adding the service account to the ACL of the "TokenGroupsGlobalAndUniversal" user object attribute or by adding the service account to the "Pre-Windows 2000 Compatible Access" group.
In the scenario illustrated in Figures 5.23 and 5.24, you would set up protocol transition in the account properties of server 1. If in this scenario the service impersonating the user is the IIS Web service, you would give the extra permissions and privileges mentioned earlier to the IIS Web service account.
You can test the new Kerberos services in a small lab environment. Figure 5.25 shows the test scenario that I used. This scenario consists of a simple Web application that queries an SQL Server database on the back end. The database query is defined in a COM+ application that is running on the Web server. The query is called from an ASP page. The Web server and SQL server are members of the same domain. The client machine need not necessarily be a domain member.
The goal of this test scenario from an authentication point of view is to let the user use any authentication protocol (with the exception of Kerberos) to authenticate to the Web server. On the back end, to authenticate to the COM+ application and the SQL Server database, we would like to use Kerberos and Kerberos delegation. This can only be set up if the new Kerberos services (S4U2Proxy and S4U2Self) are available on the Web server. Table 5.3 summarizes the software requirements and configuration options you need to keep in mind when setting this up.
Click for the next excerpt in this series: Advanced Kerberos topics: From authentication to authorization.