8.3 Windows Issues

While the Windows implementation of Kerberos is compatible with the specifications in RFC 1510, the Microsoft implementation of Kerberos varies significantly enough from the MIT and Heimdal implementations to warrant its own explanation. In order to provide the additional functionality required for the Windows Active Directory, as well as backwards compatibility with older Windows NT workstations, the Windows Kerberos environment differs in several important areas from its Unix counterpart.

8.3.1 Encryption Algorithm Support

The primary encryption type used in Windows is based on the RC4 stream cipher, with an MD5-HMAC algorithm used for the checksum field. This encryption type is referred to as RC4-HMAC, and has a variable key length to support both weaker, "export" quality key lengths, as well as stronger 128-bit key lengths.

The reasoning behind this decision by Microsoft is two-fold: first, for compatibility with older Windows NT domains; and second, for political reasons. During the initial design of Windows 2000, neither DES nor triple DES were approved for export from the United States. Microsoft wanted to encourage deployment of Windows 2000; therefore, the RC4-HMAC cipher was chosen as the default Kerberos encryption type since it is the same cipher used to generate the older NT4 password hashes. This way, when an older NT4 domain is migrated to an Active Directory domain, the users' passwords continue to work without manual intervention.

Microsoft did add DES support to Windows 2000 before its release, and users created in a Windows Active Directory have both RC4 and DES encryption keys associated with their account. However, there are two situations when a DES key is not available for an account in the Active Directory. The first situation is the one discussed above, in which an NT4 domain is converted into a Windows Active Directory domain. Since the hashing algorithm only works one way, there is no way for Windows to convert the existing users' RC4 encryption keys into DES keys. The second special-case situation is when a new Windows 2000 domain is created. As part of the domain creation procedure, an Administrator account is created as the new Domain Administrator. This account only has an RC4 key when it is initially created.

In order to add DES keys to users' accounts in both of the above situations, simply change the user's password. When a user's password is changed, the KDC will generate both RC4 and DES encryption keys for that user.

Note that even without the "Use DES encryption types for this account" checkbox checked for a user, the DES keys do exist in the Active Directory database (subject to the limitations of the previous two scenarios), but are not used by the KDC when responding to ticket requests unless the checkbox is activated.

A better solution to this is for other Kerberos implementations to adopt the RC4-HMAC encryption type into their code as well. Heimdal has recently added this support to its distribution, and MIT has incorporated full RC4-HMAC support for its Kerberos 5 1.3 release. With RC4 encryption-type support, interoperability between Unix and Windows Kerberos realms can occur without downgrading the encryption keys used to single DES.

Also note that Windows does not support salts other than the standard Kerberos 5 salt. If you have a Unix KDC that has encryption keys with other salts (such as Kerberos 4 salt or AFS salt) for interoperability with older clients, then you may have issues when attempting to interoperate with Windows. Careful reordering of the encryption types in the configuration file of the Unix KDC can help alleviate this problem, but it is recommended to use only Kerberos 5 salt and encryption types when interoperating with Windows.

8.3.2 Cached Login Credentials

Many Windows machines are mobile, and do not have a fixed network connection. For example, laptops can spend most of their time disconnected from a network; yet, end users expect the ability to log into their own computers, even when no network connection is present. Traditionally, systems that require successful Kerberos authentication for local access, as Active Directory does, require a stable network connection to operate, since communication with the KDC is required to authorize logon. Microsoft provides for disconnected login to domain accounts through a cached credentials feature.

When a user logs into a Windows 2000, XP, or 2003 host, the Local Security Authority (LSA) derives a password verifier and saves this verifier into the local machine's registry. Later, if the user is disconnected from the network or the domain controller is otherwise unavailable, the local system will authorize access if the username and password match the saved credentials stored on the local disk.

The cached credentials are stored in the local machine's registry inside of the HKEY_LOCAL_MACHINE\Security\Cache key, which contains sub-keys NL$1 to NL$10. The last 10 users' login username and password verifier are stored as the values of each of these keys.

Notice that I have been referring to a password verifier, and not password or password hash. The password verifier is a hash of the password hash, so the password verifier cannot be used to derive either the original password or a password hash. The verifier therefore contains just enough data that it is able for the local login process to take in a password, run a hashing algorithm over it twice, and compare to the verifier.

For security reasons, Windows restricts access to this registry key to the local SYSTEM account. To view these keys as Administrator, launch the regedt32 application, navigate to HKEY_LOCAL_MACHINE\Security, and select Security Permissions. Set the checkbox for read permission for the Administrators group.

Unfortunately, certain situations cause Windows to provide no indication to the end user when the system authenticates the user through a cached credential verifier. When a user is verified against a password verifier located in the cache, the login process cannot acquire any initial tickets for the user. While Windows will notice when a Windows domain controller becomes available again and transparently acquire tickets, cached login credentials can be particularly problematic when Windows is set up to authenticate against a non-Microsoft KDC, either directly or through a cross-realm trust with a Windows domain.

8.3.2.1 Disabling the cached credentials feature

The drawback, of course, to disabling the cached credentials feature is that if the machine loses its network connection and can no longer reach the domain controller, any local login requests to that domain will fail. The number of cached logins can be forced to zero by using a Domain Security Policy. Set "Number of previous logins to cache (in case domain controller is not available)," which can be found under Computer Configuration Security Settings Local Policies Security Options, to zero. This change affects the CachedLogonsCount registry key on each member machine in the domain. This registry value can be found inside the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon.

8.3.3 Windows Active Directory Authorization Field

The initial announcement by Microsoft that Windows 2000 would use Kerberos as its authentication system has produced mixed feelings in the security community. On one hand, observers lauded Microsoft for choosing a standardized Internet protocol for its security needs, opening the door for cross-platform authentication between Windows and other operating systems. However, concerned readers posted messages on discussion sites such as Slashdot implying that Microsoft was planning to "embrace and extend" the standard Kerberos protocol for their own gain.

It certainly didn't help when Microsoft announced that Windows 2000 domain controllers would add a proprietary Privilege Access Certificate (PAC) to tickets returned by the KDC, and that a reimplementation of the Windows domain controller functionality would have to create valid PAC structures. Adding fuel to the fire, Microsoft has only released the full specifications to the PAC as a Windows executable file, requiring readers to accept a restrictive license that grants the right to review the specification only for security reasons, and specifically forbids the creation of software that implements the specification as described in the document. Readers who wish to download the full specification from Microsoft (and permanently give up their rights to develop Kerberos software relating to the information contained therein) can do so at http://www.microsoft.com/Downloads/details.aspx?displaylang=en&FamilyID=BF61D972-5086-49FB-A79C-53A5FD27A092.

In 2002, Microsoft released a summary of the Windows 2000 PAC specification, which is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnkerb/html/MSDN_PAC.asp, and also submitted an Internet Draft to the IETF, currently available at http://www.ietf.org/internet-drafts/draft-brezak-win2k-krb-authz-01.txt.

The PAC is generated by the KDC during the Authentication Server exchange and contains authorization data about the client, including the SID (a unique numeric identifier for users and groups) associated with the user who requested the ticket and any groups that the user is a member of. This data is encrypted to ensure integrity and authenticity, so Windows services can trust the information to make authorization decisions based on the contents of service tickets presented for validation. This authorization data is also available by performing LDAP queries against the Active Directory servers, but is included here as an optimization, to reduce the number of round-trips between clients and the Domain Controllers. However, most Windows-based services will not perform this extra step if the authorization field is missing from tickets presented by clients, refusing access to those clients.

In general, non-Microsoft Kerberos clients will ignore the PAC field included with tickets issued by a Microsoft KDC. There is, however, one case where some interoperability problems may arise: if a user is a member of a large number of groups, then the PAC might grow large enough that the KDC reply does not fit in a single UDP packet. If this happens, the Windows KDC asks the client to retry the request using TCP. Earlier versions of MIT Kerberos 5 (before 1.3) and some other Kerberos implementations cannot retry with TCP, and will fail.