5.4 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.
5.4.1 Delegation of authentication
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 Webbased multitier application can take advantage of delegation. Examples are Web sites launching user queries against a database located on some back- end 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 Inter- net 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.
Delegation: Behind the scenes
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.
| Flag | Meaning |
|---|---|
| Proxiable | Tells the TGS that a new service ticket with a different network address may be issued based on this ticket |
| Proxy | Indicates that the ticket is a proxy ticket |
| Forwardable | Tells the TGS that a new TGT with a different network address may be issued based on this TGT |
| Forwarded | Indicates that this ticket has been forwarded or was issued based on an authentication using a forwarded TGT |
What’s missing in Windows 2000 Kerberos delegation?
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 Inter- net, 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 S4U2Proxy Kerberos extension
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.
Figure 5.20: Basic S4U2Proxy operation.
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).
-
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.
Configuring constrained delegation
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):
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.
Figure 5.22: The new “msDSAllowedToDelegate To” AD account attribute enabling constrained delegation.
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 S4U2Self Kerberos extension
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.
Figure 5.23: Basic S4U2Self operation.
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 Digest- based, 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.
-
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.
Figure 5.24: Combined S4U2Self operation and S4U2Proxy operation.
Configuring protocol transition
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.
-
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.
-
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.
A sample scenario
You can test the new Kerberos services in a small lab environment. Figure5.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.
Figure 5.25: Sample scenario.
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.
| Component | Software Requirements and/or Configuration Settings |
|---|---|
| Web Browser | Support for Basic authentication, Digest authentication, certificate-based authentication (SSL), or MS Passport–based authentication. The user account is a member of the domain. |
| Web Server | Delegation settings for computer account:
|
| COM+ Application |
|
| Database Server |
|
5.4.2 From authentication to authorization
In this section we will explain the link between Windows Server 2003 authentication and authorization in the context of a Kerberos authentication exchange. Figure 5.26 illustrates the link between these two core operating system security services.
Figure 5.26: From Windows Server 2003 authentication to authorization.
Next we will explain how we get from the Kerberos ticket (the basic entity used for authentication) to the access token (the basic entity used for authorization). An important component in this process is the Kerberos Privilege Attribute Certificate (PAC). Microsoft extended the base Kerberos protocol to include authorization data (e.g., global group memberships). A Windows Server 2003 ticket and TGT both contain a PAC.
Let us start off with a normal Kerberos authentication sequence. We are once more dealing with three entities: a user (Alice), a resource server, and a Kerberos KDC. Once Alice’s workstation has located a domain controller, it will request a TGT. The KDC will generate the PAC, embed the authorization data listed next, put the PAC into a TGT, and send the TGT to Alice.
-
Alice’s global group memberships and domain local group member- ships: These are available from the KDC’s local Active Directory (Domain NC).
-
Alice’s universal group memberships: These are available:
-
In the global catalog. If the KDC server himself or herself does not host a global catalog, the KDC service will need to query a global catalog on another domain controller.
-
In the domain naming context of Alice’s logon domain. This is only true if the site of Alice’s authenticating DC has universal group caching enabled (see following side note). The GC-less logon process or universal group caching is a new Windows Server 2003 feature that caches a user’s universal group membership in the msDs-Cached-Membership attribute of a user account. Universal group memberships are cached in this attribute at the first user logon instance and are by default refreshed every 8 hours.
-
The user rights assigned to Alice or any of her groups (universal, global, and domain local). These are available from the domain controller’s LSA database.
Table 5.4 gives an overview of which group memberships are available where.
| Group Type | Group: Available Where? | Group Membership: Available Where? |
|---|---|---|
| Universal group | AD: Global catalog | AD: Global catalog AD: Domain NC: only if Universal Group Caching (GC-less logon) is enabled. |
| Global group | AD: Global catalog | AD: Domain NC |
| Domain local group | AD: Domain NC | AD: Domain NC |
| Local group | Local machine: SAM | Local machine: SAM |
Alice then decides she wants to access a resource hosted on a member server. Alice sends a request for a ticket to the KDC. This ticket will contain the same PAC as the one contained in the TGT. The ticket is sent back to Alice.
Alice authenticates to the resource server using the ticket. The LSA on the resource server will generate Alice’s access token (for use in subsequent authorization decisions). In the access token the LSA will embed:
-
Alice’s authorization data found in the ticket’s PAC (her universal, global, and domain local group memberships and user rights, assigned to her or any of the groups of which she is a member)
-
Alice’s authorization data found in the local security database (SAM): These are the local group memberships of Alice, the local group memberships of the groups (universal, global, or domain local) of which Alice is a member, and the user rights of Alice and Alice’s groups.
To look at the contents of your access token, use the whoami tool (with the /all switch) that comes with the Windows Server 2003 code.
Key things to remember from this section are the following:
-
The PAC data are added to a ticket on the KDC level and are inherited between subsequent TGT and ticket requests and renewals. The PAC data are not refreshed at ticket-request time. This means that if a user’s group memberships change during its logon session, he or she will have to log off-log on (just as in NT4), wait for an automatic TGT renewal to occur, or purge the Kerberos ticket cache (using the klist or kerbtray utilities explained next). Note that even though Windows does not refresh the authorization data it will check whether the account hasn’t been disabled (see also the sidenote on “Kerberos and disabled accounts”).
Enabling a GC-Less Logon Process A GC-less logon or universal group caching is a new Windows Server 2003 feature that enables Windows Server 2003 domain controllers to cache a user’s universal group memberships in the msDS-Cached-Membership attribute of a user account. It is enabled in the NTDS settings properties of a site object—as illustrated in Figure 5.27.
Figure 5.27Windows 2000 requires the availability of a GC server to retrieve a user’s universal group membership when logging on to a domain. In Windows 2000 Microsoft provides a workaround for this requirement by enabling DCs to ignore GC failures, when a GC could not be contacted to find out about a user’s universal group memberships. This workaround was based on a registry key called IgnoreGCFailures, which had to be added to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa registry folder of every DC. This hack also took away the possibility to use universal groups in a Window 2000 forest. (This is documented in Microsoft Knowledge Base article Q241789.)
The new Windows Server 2003 feature does not fully take away the need to put a GC in every site—or at least to have one reachable GC for every site. Although GCs are not needed anymore to find out about a user’s universal group memberships, you still need them to resolve UPN names when users are logging on using a UPN.*
-
Unless you have enabled the GC-less logon process (see the previous side note), the presence of at least one domain controller hosting a global catalog per domain tree is mandatory to log on a normal user. An exception to this rule is accounts that are member of the Administrators or Domain Administrators groups: They can log on even when a global catalog server is not available.
Kerberos and Disabled Accounts The following example illustrates how the fact that Kerberos TGTs are reusable as long as they are valid, together with the action of disabling a Windows account can lead to security holes in a Windows multi-domain environment. The AD environment illustrated in Figure 5.28 consists of a single forest with a single domain tree. A user’s Windows account and machine account are defined in domain emea, a file server is part of the asiapac domain. When the user logs on to emea, he or she will receive a TGT for the emea domain. When the user accesses the file server in asiapac he or she will in addition get a TGT for the asiapac domain (see also Section 5.3.2). When the administrator disables the user account in emea, he or she won’t be able to get any more tickets for resources in emea. The user will however still be able to get new tickets for resources in the asiapac domain—this will be possible as long as the user’s TGT for asiapac remains valid. The reason for this is that the DCs in the asiapac domain don’t check the user’s account status when they issue tickets.
Figure 5.28: Kerberos and disabled accounts: Example
5.4.3 Analyzing the Kerberos ticket and authenticator
This section provides some inside information on the Kerberos ticket and authenticator. The concepts of a ticket and an authenticator and the relationship between the two are illustrated in Figure 5.29.
Figure 5.29: Relationship between Kerberos ticket and authenticator.
Remember that the primary purpose of a ticket is to securely transport the session key to be used for authentication between two entities. A ticket can only be decrypted by a KDC and the destination resource server. This way the client cannot decrypt and change its own authorization data (the information contained in the PAC). An authenticator is the Kerberos object that is providing the actual authentication. An authenticator can be checked by anyone possessing the corresponding session key. A detailed overview of the content of both the ticket and the authenticator is given in the following sections.
Ticket content
Table 5.5 shows the ticket fields, their meaning, and whether they are sent in encrypted format across the network.
| Encrypted? | Name | Meaning |
|---|---|---|
| Tkt-vno | Version number of the ticket format. | |
| Realm | Name of the realm (domain) that issued the ticket. | |
| Sname | Name of the server (Principal name). | |
|
| Flags | Ticket options. These are explained in more detail later in the chapter. |
|
| Key | Session key. |
|
| Crealm | Name of the client’s realm (domain). |
|
| Cname | Client’s name (Principal name). |
|
| Transited | Lists the Kerberos realms that took part in authenticating the client to whom the ticket was issued. |
|
| Authtime | Time of initial authentication by the client. The KDC places a timestamp in this field when it issues a TGT. When it issues tickets based on a TGT, the KDC copies the authtime of the TGT to the authtime of the ticket. |
|
| Starttime | (Optional) Time after which the ticket is valid. |
|
| Endtime | Ticket’s expiration time. |
|
| Renew-till | (Optional) Time period during which the ticket is automatically renewed without the client having to provide his or her master key. |
|
| Caddr | (Optional) One or more addresses from which the ticket can be used. If omitted, the ticket can be used from any address. |
|
| Authorization data | (Optional) Privilege attributes for the client. Microsoft calls this part the Privilege Attribute Certificate (PAC). |
Kerberos encryption types
Windows Server 2003 Kerberos supports the following cryptographic algorithms: RC4-HMAC, DES-CBC-CRC, and DES-CBC-MD5. The default encryption algorithm is “RC4-HMAC”—it was defined in an Internet draft called draft-brezak-win2k-krb-rc4-hmac-05.txt.
The default Kerberos encryption type can be changed using the “Use DES encryption types for this account” AD account property. The property can be set in the account options, which are available from the account tab in the account properties. Enabling this property is required when you’re looking after UNIX and Windows Kerberos interoperability. DES encryption is the default in most UNIX Kerberos implementations.
There are two reasons why Microsoft did not use DES as the default algorithm:
-
Ease of upgrading from NT4 to Windows 2000 or Windows Server 2003. The key used for RC4-HMAC can also be used with the Windows NT 4 Password Hash.
-
Export law restrictions. In the early stages of the Windows 2000 development, 56-bit DES could not be exported outside of the United States. Because MS wanted to use the same Kerberos encryption technology in both the domestic and export versions of the product, they chose the 128-bit RC4-HMAC alternative. RC4-HMAC was already exportable at that point in time.
The algorithm used for a Kerberos ticket can be checked using the “klist” or “kerbtray” resource kit utilities. These utilities are explained later in this chapter.
Table 5.6 shows the algorithms and their supported key lengths. When the Windows 2000 “Strong encryption fix” has been installed, RC4- HMAC can use 128-bit keys for bulk encryption. This is the default in Windows Server 2003. A Windows domain can contain a mix of clients with and without the fix installed. Windows Kerberos will automatically choose the strongest available encryption algorithm.
| Algorithm | Authentication | Signing | Confidentiality Protection |
|---|---|---|---|
| RC4-HMAC | 128 | 128 | 128 (56) |
| DES-CBC-CRC | 56 | 56 | 56 |
| DES-CBC-MD5 | 56 | 56 | 56 |
The Privilege Attribute Certificate
The Privilege Attribute Certificate (PAC) enables the Kerberos protocol to transport authorization data—in the Windows case these data are user group memberships and user rights. We already explained part of the reason for existence of the PAC in the section on “From authentication to authorization.”
Shortly after the release of Windows 2000, Microsoft received some negative press attention because of the proprietary way they used the PAC field in a Kerberos ticket. This forced Microsoft to release the PAC specifications. They can be downloaded from http://www.microsoft.com/ downloads/details.aspx?displaylang=en&familyid=BF61D972-5086-49FBA79C-53A5FD27A092. This document can be used only for informational purposes; it explicitly forbids the creation of software that implements the PAC as described in the specifications. A summary of the specifications can be found at http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnkerb/html/MSDN_PAC.asp. Microsoft also submitted their PAC definition as an Internet Draft to the IETF—it’s called draft-brezak-win2K- krb-authz-01.txt.
Most non-Microsoft Kerberos implementations ignore the PAC field and its content. Interoperability issues may arise though if a user is a member of a large amount of groups. In that case, the PAC size may become so big that it cannot be transported in a single UDP packet anymore. If this happens, a Windows KDC will request the client to switch to TCP, which cannot be done by some of the early Kerberos implementations (see also Section 5.5.3).
An important PAC security detail is that its content is digitally signed. By signing the authorization data, a hacker cannot make modifications to the data without being detected. This was possible in NTLM version 1: Authorization data for part of NTLM version 1 messages were not protected. Microsoft corrected this error in NTLM version 2, which is included in Windows 2000, XP, Windows Server 2003, and all the NT4 Service Packs from SP4 onward (see also Chapter 4 for more information).
The Kerberos PAC content is signed twice:
-
Once with the master key of the KDC (this is the master key linked to the krbtgt account). This signature prevents malicious server-side services from changing authorization data. The LSA on the server side will require a validation of the signature for every ticket coming from a service that is not running using the local system account. To validate the signature, the server will need to set up a secure channel with the KDC that signed the authorization data. This extra validation step might remind you of NTLM and its pass-through authentication. This time, however, the pass-through is not used for validation of a response but for validation of a digital signature.
-
Once with the master key of the destination service’s service account (the destination service is the one responsible for the resource the user wants to access). This is the same key as the one used to encrypt the ticket content. This signature prevents a user from modifying the PAC content and adding its own authorization data.
The Kerberos ticket has a fixed size, which indirectly also limits the PAC size. If a user is a member of a large amount of groups, this size may be exceeded and, as a consequence, authentication and group policy processing may fail. Microsoft allows you to adjust the maximum size of a Kerberos ticket using the MaxTokenSize registry parameter. This parameter is a REG_DWORD value and is contained in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos registry container. The value should be adjusted on all Windows machines users are logging from to a domain to using Kerberos.
In Windows 2000, the default MaxTokenSize value is 8,000 bytes. In Windows 2000 Service Pack 2 (SP2) and Microsoft Windows Server 2003, the default value is 12,000 bytes.
The MaxTokenSize parameter is documented in Microsoft Knowledge Base article Q327825.
In order to reduce the PAC size, Microsoft implemented a new method to store authorization data in the PAC in Windows 2000 Service Pack 4 (SP4) and later, and in Windows Server 2003. This solution is also available as a hotfix for pre-Windows 2000 SP4 machines (see also Q327825). This new PAC authorization data storage method can be summarized as follows:
-
If the global and universal groups a user belongs to are local to the domain the user is in, then only the RID (relative identifier) is stored.
-
If the groups are local groups or are from other domains, the entire SID is stored.
This means for example that instead of storing an “S-1-5-21- 1275210071-789336058-1957994488-3140” value (the SID), you would only store the “3140” value (the RID) in the PAC. Microsoft provides a special process on the client and server side to explode the RIDs back to the SID format during the Windows authorization process.
Even on platforms where this new PAC authorization data storage method is available, it may be required that the maxtokensize registry value be adjusted.
Kerberos preauthentication data
“Preauthentication” is a feature introduced in Kerberos version 5. With preauthentication data, a client can prove the knowledge of its password to the KDC before the TGT is issued. In Kerberos version 4, anyone, including a hacker, can send an authentication request to the KDC; the KDC does not care. It does not even care about authenticating the client: Authentication is completely based on the client’s ability to decrypt the packet returned from the KDC using its master key.
Preauthentication also lowers the probability of an offline password- guessing attack. Without preauthentication data, it is easy for a hacker to do an offline password-guessing attack[13] on the encrypted packets returned from the KDC. A hacker can send out dummy requests for authentication; each time he or she will get back another encrypted packet, which means he or she gets another chance to make a brute-force attack on the encrypted packet and to guess the user’s master key.
In a standard Kerberos authentication sequence, the preauthentication data consist of an encrypted timestamp. When logging on using a smart card, the preauthentication data consist of a signed timestamp and the user’s public key certificate. In Windows 2000 and Windows Server 2003, preauthentication is the default. An administrator can turn it off using the “Do not require Kerberos preauthentication” checkbox in the account properties (“account” tab). This might be required for compatibility with other implementations of the Kerberos protocol. Preauthentication affects the content of a ticket: Every ticket contains a special flag that is reserved for preauthentication.
Authenticator content
Table 5.7 shows the authenticator fields, their meaning, and whether they are sent in encrypted format across the network.
| Encrypted? | Name | Meaning |
|---|---|---|
|
| Authenticator-vno | Version number of the authenticator format. In Kerberos v.5 it is 5. |
|
| Crealm | Name of the realm (domain) that issued the corresponding ticket. |
|
| Cname | Name of the server that issued the corresponding ticket (Principal name). |
|
| Cksum | (Optional) Checksum of the application data in the KRB_AP_REQ. |
|
| Cusec | Microsecond part of the client’s timestamp. |
|
| Ctime | Current time on client. |
|
| Subkey | (Optional) Client’s choice for an encryption key to be used to protect an application session. If left out, the session key from the ticket is used. |
|
| Seq-number | (Optional) Initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages (protection against replay attacks). |
TGT and ticket flags
In this section, we will analyze the content of a Kerberos TGT and a service ticket; we will focus on the TGT and ticket “flags.” The ticket flags and their meaning are explained in Table 5.8.
| Flags | Meaning |
|---|---|
| Forwardable | Indicates to the ticket-granting server that it can issue a new Ticket Granting Ticket with a different network address based on the presented ticket. |
| Forwarded | The ticket has either been forwarded or was issued based on authentication involving a forwarded Ticket Granting Ticket. |
| Proxiable | Indicates to the ticket-granting server that only nonticket-granting tickets may be issued with different network addresses. |
| Proxy | The ticket is a proxy ticket. |
| May be postdated | Indicates to the ticket-granting server that a postdated ticket may be issued based on this Ticket Granting Ticket. |
| Postdated | Indicates that a ticket has been postdated. The end service can check the ticket’s authtime field to see when the original authentication occurred. |
| Invalid | The ticket is invalid. |
| Renewable | The ticket is renewable. If this flag is set, the time limit for renewing the ticket is set in RenewTime. A renewable ticket can be used to obtain a replacement ticket that expires later. |
| Initial | The ticket was issued using the AS protocol instead of being based on a Ticket Granting Ticket. |
| Preauthenticated | Indicates that, during initial authentication, the client was authenticated by the KDC before a ticket was issued. The strength of the preauthentication method is not indicated, but is acceptable to the KDC. |
| Hardware preauthentication | Indicates that the protocol employed for initial authentication required the use of hardware expected to be possessed solely by the named client. The hardware authentication method is selected by the KDC and the strength of the method is not indicated. |
| Target trusted for delegation (OK as delegate) | This flag means that the target of the ticket is trusted by the directory service for |
Next are some important notes on usage of the ticket flags in Windows 2000 and Windows Server 2003 Kerberos.
-
By default, every ticket has the “forwardable” flag set. This default behavior can be reversed by setting the “account is sensitive and cannot be delegated” property on an account object. Windows 2000 and Windows Server 2003 Kerberos do not support “proxy” tickets.
-
By default, every ticket has the “renewable” flag set. When a ticket expires and a new ticket is needed, the system will not automatically request a new ticket (a TGT or a service ticket) (automatic ticket requests will work as long as a user’s cached credentials are available).
-
By default, every ticket has the “preauthenticated” flag set.
-
Every Windows 2000 TGT has the “initial” flag set.
-
A ticket has the “Target trusted for delegation” (OK as delegate) flag set if the service or user account for which the ticket was issued has the “account is trusted for delegation” property set, or, in the case of a computer account, if the computer object has “trust computer for delegation” set.
A single ticket can contain multiple flags. The flags are added to a ticket’s properties as a hexadecimal 8-bit number, of which only the first 4 bits are significant. One bit can refer to different flags. If flags refer to the same bit position, they are added hexadecimally. This hexadecimal number is displayed when looking at the TGTs in the Kerberos ticket cache using the resource kit tool “klist”; the other resource kit tool “kerbtray” automatically converts the number to its appropriate meaning.
5.4.4 Kerberized applications
Kerberized applications are applications that use the Kerberos authentication protocol to provide authentication (and maybe in a later phase to provide encryption and signing for subsequent messages). Windows 2000 and Windows Server 2003 include the following Kerberized applications:
-
LDAP to AD
-
CIFS/SMB remote file access. Common Internet File System (CIFS) is the new name of Microsoft’s SMB protocol that is mainly used for file and print sharing.
-
Secure dynamic DNS update
-
Distributed File System Management
-
Host to Host IPsec using ISAKMP
-
Secure intranet Web services using IIS
-
Authenticate certificate request to certification authority (CA)
-
DCOM RPC security provider
Smart card logon process
Windows 2000 and Windows Server 2003 include extensions to Kerberos Version 5 to support public-key–based authentication. These extensions are known as PKINIT—which stands for use of Public Key cryptography for INITial authentication—and are defined in an IETF Internet draft available from http://www.ietf.org. PKINIT enables the smart card logon process to a Windows 2000 or later domain. PKINIT allows a client’s master key to be replaced with its public key credentials in the Kerberos Authentication
Using Klist and Kerbtray The Windows Server 2003 Resource Kit contains two utilities you can use to look at the content of the Kerberos ticket cache: kerbtray.exe (illustrated in Figure 5.30) and klist.exe (illustrated in Figure 5.31). Kerbtray.exe is a GUI tool, and klist.exe is a command-line tool. Both tools can be used to display and/or purge the content of the Kerberos ticket cache.
Figure 5.30: Looking at the Kerberos ticket cache using the Klist utility.
Figure 5.31: Looking at the Kerberos ticket cache using the Kerbtray utility.To bring up the kerbtray dialog box and look at your logon session’s Kerberos ticket cache, double-click the kerbtray icon in the status area of your Windows desktop. The kerb- tray icon is only displayed if you started the kerbtray program—it looks like a green ticket. The upper pane of the kerbtray dialog box shows all Kerberos tickets (both service tickets and TGTs) that are cached in your logon session’s Kerberos ticket cache. The lower part of the dialog box has four tabs: Names, Times, Flags, and Encryption Types. The content of these tabs differs depending on the ticket that is selected in the upper pane.
The Names tab shows the name of the security principal the Kerberos ticket was issued to [this is the user’s User Principal Name (UPN)], together with the name of the service for which the ticket was issued [this is the service’s Service Principal Name (SPN)].
The Times tab shows the validity period of the ticket: its start and end time. For both TGTs and tickets, the default validity period is 10 hours.
The Flags tab shows the Kerberos ticket flags that have been set in the ticket. Examples of ticket flags are the forwarded and proxy flags used during the Kerberos delegation process. For a more detailed explanation of all the Kerberos ticket flags, I refer to the Kerberos Version 5 (V5) standard document [Request For Comments (RFC) 1510], which can be downloaded from the IETF Web site at http://www.ietf.org.
Finally, the Encryption Types tab shows the names of the symmetric encryption algorithms that were used by the Kerberos software to encrypt the tickets’ content.
To purge the tickets in the Kerberos ticket cache, right-click the kerbtray icon in your desktop’s status area and select Purge Tickets. This option deletes all tickets in your ticket cache. Use this option with extreme caution: Deleting tickets may stop you from authenticating to other Windows services during your logon session. If you have purged your tickets, you can only obtain new ones by logging off and then logging on again.
To display the content of the Kerberos ticket cache using the klist command-line utility, type the following at the command prompt:
Klist ticketsor
Klist tgtThe first command will bring up the service tickets in the cache, and the second command will bring up the TGTs in the cache. To purge the cache from the command line, type:
Klist purgeAgain, use the latter command with extreme caution.
The kerbtray utility displays more ticket information than the klist utility does—it also displays the information in a much more readable format. For example, the klist utility displays the TGT tickets flags altogether in a single hexadecimal string: It is up to the user to decipher this string and retrieve the associated ticket flags.
Request (KRB_AS_REQ) and Reply (KRB_AS_REP) messages. This is illustrated in Table 5.9.
| Standard Kerberos Usage of Master Key | PKINIT Replacement |
|---|---|
| Client-side encryption of the preauthentication data | Private key |
| KDC-side decryption of the preauthentication data | Public key |
| KDC-side encryption of session key | Public key |
| Client-side decryption of session key | Private key |
PKINIT introduces a new trust model (illustrated on the right side of Figure 5.32) in which the KDC is not the first entity to identify the users (as is the case for classical Kerberos). Before KDC authentication, users are identified by the certification authority in order to obtain a certificate. In this new model the users and the KDC obviously both need to trust the same CA.
Figure 5.32: Smart card logon trust model.
Figure 5.33 shows the way the Kerberos smart card logon process works (notice that the cryptic names of the Kerberos messages have changed):
Figure 5.33: Smart card logon process.
-
Alice starts the logon process by introducing her smart card and by authenticating to the card using her PIN code. The smart card contains Alice’s public key credentials: her private key and certificate.
-
A TGT request is sent to the KDC (AS); this request contains the following (PA-PK-AS-REQ):
-
Alice’s principal name and a timestamp
-
The above signed with Alice’s private key
-
A copy of Alice’s certificate
-
-
To validate the request and the digital signature on it, the KDC will first validate Alice’s certificate. The KDC will then query the Active Directory for a mapping between the certificate and a Windows account. If it finds a mapping, it will issue a TGT to the corresponding account.
-
The KDC sends back the TGT to Alice. Alice’s copy of the session is encrypted with her public key (PA-PK-AS-REP).
-
To retrieve her copy of the session key, Alice uses her private key.
We will come back to smart card support in Windows Server 2003 in Chapter 17.
[13]During an offline password-guessing attack, a hacker intercepts an encrypted packet, takes it offline, and tries to break it using different passwords This kind of offline attack is also known as a brute-force attack: The hacker tries out different keys (in this case “passwords”) to decrypt a packet until he or she finds the right key that decrypts the packet in cleartext.
EAN: 2147483647
Pages: 137