Get started Bring yourself up to speed with our introductory content.

Advanced Kerberos topics: From authentication to authorization

This excerpt from "Windows Server 2003 security infrastructures" focuses on the link between authentication and authorization and the content of Kerberos tickets and authenticators.


Windows Server 2003 security infrastructures

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

To help you navigate this excerpt more quickly and easily, please use the following guide.

 Overview: From authentication to authorization
Enabling a GC-Less logon process
Kerberos and disabled accounts
Analyzing the Kerberos ticket and authenticator
The Privilege Attribute Certificate
Kerberos preauthentication data

From authentication to authorization
Return to Table of Contents

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.

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.

From Windows Server 2003 authentication to authorization.

  • Alice's global group memberships and domain local group memberships: 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 eight 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.

Windows Server 2003 Groups: Group membership and definition storage locations

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").
  • 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.

Enabling a GC-Less logon process
Return to Table of Contents

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.

Windows 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.*
* This UPN resolution process will only occur when using alternate UPN suffixes. These are suffixes that are different from the standard suffixes as they occur in the Windows DNS domain names.

Enabling a GC-less logon process

Kerberos and disabled accounts
Return to Table of Contents

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.

Kerberos and disabled accounts example

Analyzing the Kerberos ticket and authenticator
Return to Table of Contents

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.

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.

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.

Relationship between Kerberos ticket and authenticator.

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.

The Privilege Attribute Certificate
Return to Table of Contents

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 Microsoft.

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 this link. Microsoft also submitted their PAC definition as an Internet Draft to the IETF -- it's called draft-brezak-win2Kkrb-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
Return to Table of Contents

"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 passwordguessing attack. Without preauthentication data, it is easy for a hacker to do an offline password-guessing attack on the encrypted packets returned from the KDC. [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.] 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.

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.

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.

Click for the next excerpt in this series: Advanced Kerberos topics: Kerberized applications.

Click for the book excerpt series or visit Elsevier to obtain the complete book.


Dig Deeper on Microsoft Hyper-V management