Kerberos in Win2K

Transitive Trust
As in NT 4.0, a trust (i.e., a secret that two domain controllers share) between two Win2K domains facilitates cross-domain resource access and creates cross-domain account visibility. Microsoft simplifies trust creation and management in Win2K by letting you create trusts automatically as part of the domain hierarchy building process and allowing transitive trust.

Transitive trust means that if both europe.company.com and us.company.com trust company.com, then europe.company.com implicitly trusts us.company.com. Transitive trust reduces the number of trusts needed for authentication. For an example of how transitive trust simplifies authentication, see the sidebar "Kerberos Transitive Trust Examined," page 78.

Transitive trust is only a logical concept—no shared secret exists between the domain controllers of the domains that share a transitive trust. This setup means that for authentication to occur between entities on opposite ends of a transitive trust, the authentication process doesn't flow across the transitive trust but through the trust path (i.e., the tree of entities within a transitive trust). Microsoft claims that this referral process doesn't affect network traffic and the traffic this process generates is comparable to the traffic NT 4.0's pass-through authentication process generates. However, the referral process is evidence that Kerberos isn't suited for large distributed environments such as the Internet. Kerberos is an intranet-authentication protocol.

Win2K contains five basic types of trust relationships, as Table 1 outlines. You can view trust relationships through each domain objects' properties, as Screen 3 shows, or you can use the trustdom.exe command prompt utility. You can also use these tools to explicitly create trusts. End users who are working from Kerberos-compliant workstations can see the effect of transitive trusts when they log on. They can choose every domain with which their domain has a direct trust or an indirect trust. An NT 4.0 end user sees only the direct trusts of his or her domain.

Win2K Kerberos trusts that you implicitly or explicitly create within the same forest are transitive by default. Microsoft included a check box in Win2K beta 2 that let you turn off transitivity, but Microsoft didn't include this option in beta 3. Explicit trusts between forests or trusts to non-Win2K domains, such as a UNIX Kerberos domain, are nontransitive by default. So, if you want authentication interoperability between two domains that are part of different forests, you have to establish a trust relationship between the two domains manually.

Authentication Delegation
Using authentication delegation, user A can give rights to intermediary machine B to authenticate to an application server C as if machine B were user A. This setup means that application server C will base access control decisions on user A's identity rather than on machine B's account. Delegation is also known as authentication forwarding. In the Kerberos delegation process, user A forwards a ticket to intermediary machine B, and machine B uses user A's ticket to authenticate to application server C.

You can use delegation for authentication in multitier applications, such as Outlook Web Access (OWA). To use OWA, users access their mailboxes from a browser. In most cases, the Microsoft Exchange server that contains users' mailboxes isn't collocated to the Microsoft Internet Information Server (IIS). This means that IIS must authenticate to the Exchange server as if the IIS server were the user. In NT 4.0, this scenario causes problems when you want to use the NT LAN Manager (NTLM) protocol for authentication on both links (i.e., between the browser and IIS and between IIS and the Exchange server) because NTLM doesn't support delegation.

You can set delegation on each Win2K user and computer account by selecting the Account is trusted for delegation check box in an account's properties dialog box, as Screen 4 shows. You can also use the Win2K GPO Enable computer and user accounts to be trusted for delegation entry to set delegation.

Smart Card Logon
Win2K includes support for smart card logon, which provides much stronger authentication than password logon does because smart card logon relies on two-factor authentication. To log on, a user needs a smart card and the smart card's personal identification number (PIN) code. In addition, smart card logon blocks Trojan-horse attacks, in which intruders attempt to grab users' passwords out of memory.

In Win2K, an extension to the Kerberos protocol, PKINIT, makes smart card logon possible. During a PKINIT-based logon sequence, PKINIT replaces all occurrences of a user's password with the user's public key credentials, which the system has stored on a smart card. (For more information about PKINIT, see the Internet Engineering Task Force—IETF—document at http://search.ietf.org/ internet-drafts/ draft-ietf-cat-kerberos-pk-init-09.txt.)

To use smart card logon, you need to install a Win2K certificate server that has the necessary smart card logon certificate templates loaded. Users need a smart card reader and a smart card. Win2K currently supports smart cards from Gemplus and Schlumberger (both vendors provide a Cryptographic Service Provider—CSP—as a plug-in to Microsoft's CryptoAPI).

Smart card installation is straightforward thanks to Win2K's Plug and Play (PnP) support. In addition, Microsoft lets you define an enrollment agent to centralize and accelerate loading your corporate users' smart cards. An enrollment agent is an account with a special certificate that has permission to request and load other users' certificates.

Kerberos Is an Open Standard
Microsoft based its Kerberos implementation on the open standard that RFC 1510 defines (i.e., Kerberos V5), which means that Kerberos can provide authentication interoperability between Win2K and other OSs that support an RFC 1510-based Kerberos implementation.

Kerberos authentication interoperability comes in three flavors: A Win2K server hosts the Kerberos KDC and serves as a KDC for Win2K and other platform clients. Alternatively, a non-Win2K server hosts the Kerberos KDC and serves as a KDC for Win2K and other platform clients. Finally, you can create a cross-realm trust relationship between a Win2K domain and another platform to provide authentication interoperability. In this case, you have two KDCs—one KDC on each side of the trust relationship.

Authentication interoperability isn't simple and makes administration more complex. For example, to use a cross-realm trust to obtain authentication interoperability between Win2K and a UNIX platform, you must define an explicit mapping between each UNIX account that will access resources in your Win2K domain and a Win2K account, as Screen 5 shows. You must map each UNIX account because UNIX Kerberos account names are meaningless to Win2K domains. Windows environments use SIDs to identify accounts. UNIX accounts defined in a UNIX Kerberos domain don't have SIDs. The Security Identity Mapping dialog box shows mappings as part of a user object's advanced features.

In addition, companies outside the United States must consider the US export laws when planning authentication interoperability. These laws prohibit the export of software that uses encryption key lengths longer than 56 bits. The standard MIT Kerberos V5, which is available on US Web sites for UNIX platforms, uses 128-bit-length keys and isn't exportable. Win2K Kerberos is available in a domestic, nonexportable version, which uses 128-bit-length keys and an international, exportable version, which uses 56-bit-length keys. You can discover what version of Win2K you're running by looking at the properties of one of the following system files: schannel.dll, rsabase.dll, or ndiswan.sys.

In addition, although Microsoft implemented Kerberos as a Security Support Provider Interface (SSPI) plug-in, Kerberos supports the GSS_API token formats, which RFC 1964 defines. As a result, a UNIX application that supports GSS_API and a Win2K application can use Kerberos to mutually authenticate.

Looking Ahead
Microsoft has extended Win2K's authentication process by implementing Kerberos. Kerberos has symmetric cryptography roots that make it a typical LAN- and intranet-oriented authentication protocol. However, the inclusion of PKINIT is the first step toward increasing Kerberos' public-key-based authentication functionality and a wider application of Kerberos.

• "Kerberos in Win2K" stated that if you want your Windows 9x client to use Kerberos for authentication, you must install the Directory services client. The Directory services client doesn't provide Kerberos support for Win9x; however, it comes with build-in support for NT LAN Manager (NTLM) version 2. For information on enabling NTLM version 2 authentication on these systems, see Microsoft Support Online article "How to Enable NTLM 2 Authentication for Windows 95/98 Clients" . We apologize for any inconvenience this error might have caused.