What Is Kerberos Authentication?

[Previous] [Next]

Kerberos authentication is the default authentication protocol used by Windows 2000 for a Windows 2000 domain. Unlike many other implementations of the protocol, it's completely transparent to your users. As far as your users need to be concerned, they're just logging on to computers running Windows 2000 by using the usual logon techniques available in prior versions of the operating system.

Kerberos was originally developed at Massachusetts Institute of Technology (MIT), and the protocol is defined in RFC 1510, making use of security tokens defined in RFC 1964. Microsoft has implemented the PKINIT protocol to support smartcard-based logon. This is currently an Internet Engineering Task Force (IETF) draft: draft-ietf-cat-kerberos-pk-init.

Kerberos Supports Mutual Authentication

Unlike the previous default authentication scheme in Windows, NTLM, Kerberos authenticates the client and the server. This feature of Kerberos is referred to as mutual authentication. NTLM authenticates the user only. Because of this, when using NTLM a user accessing a server cannot guarantee that the server is the one it claims to be. Kerberos authenticates servers as well so that users can be confident that the server they are accessing is not an imposter.

NTLM is still supported by Windows 2000 for backward compatibility with prior versions of Windows, including Microsoft Windows NT, Windows 95, and Windows 98.

NOTE

---

If you're completely new to Kerberos and want a lighthearted introduction to the protocol, see "Designing an Authentication System: a Dialogue in Four Scenes" at http://web.mit.edu/kerberos/www/dialogue.html and "The Moron's Guide to Kerberos" at http://www.isi.edu/gost/brian/security/kerberos.html.

Kerberos Supports Delegation

A feature of Kerberos used to great advantage in Windows 2000 is the concept of delegation, or the ability of a process to delegate a user's identity to another process possibly executing on another computer. The remote process can then act on behalf of the user, with the privileges associated with the user. This is somewhat similar in principle to the Windows NT notion of impersonation. The big difference is that a delegated identity can flow from machine to machine, assuming they are configured correctly. An impersonated account cannot leave a computer and access a remote resource as the impersonated user.

Figure 14-1 shows the difference between impersonation and delegation in Windows 2000.

Figure 14-1. The main difference between impersonation and delegation is how far the client's identity can "reach."

Note that even in Windows 2000 delegation will not succeed if a Windows 2000 domain cannot be accessed, if the application acting on behalf of the user is not trusted to act as a delegate (that is, trusted for delegation), or if the user specifically requests that his identity never be delegated.

For example, COM+ applications default to impersonation rather than delegation when they take client requests. You can ask the operating system to provide a delegable identity when using remote procedure calls (RPCs) and calling the RpcBindingSetAuthInfoEx function. A named pipes client can also set the impersonation level in the call to CreateFile when it opens a remote pipe.