Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

This chapter focuses on the Kerberos authentication protocol, the default authentication protocol of Windows Server 2003. We will look at how the protocol is works, how it has been implemented in Windows Server 2003, and some advanced Kerberos topics.

5.1 Introducing Kerberos

In Greek mythology Kerberos is a three-headed dog guarding the entrance to the underworld. In the context of this book Kerberos refers to the authentication protocol developed as part of the MIT Athena project.^[1]

Microsoft introduced Kerberos as the new default authentication protocol for enterprise environments in Windows 2000. Every Windows 2000, Windows XP, and Windows Server 2003 OS platform includes a client Kerberos authentication provider. Neither Windows 2000 nor Windows Server 2003 includes Kerberos support for other legacy Microsoft platforms. Your NT4, Windows 95 or 98 clients will not be able to authenticate using Kerberos—you’ll need to upgrade these workstations to either Windows 2000 Professional or Windows XP. In the early days of Windows 2000, Microsoft promised to include Kerberos support for Windows 95 and 98 in the “Directory Services Client” (dsclient.exe), an add-on for Windows 95 and 98 that can be found on the Windows 2000 Server CD.

A little more about the dog’s three heads: They stand for authentication, authorization, and auditing. The basic Kerberos protocol (Version 5, as defined in RFC 1510) only deals with authentication. Microsoft’s implementation of the protocol also includes extensions for authorization. So far, no Kerberos implementation covers auditing. Kerberos can also offer more than the three A’s: Later in this chapter we will explain how one of the secret keys exchanged during the Kerberos authentication sequence can be used for packet authentication, integrity, and confidentiality services.

Another analogy to the dog’s three heads is the number of basic entities the Kerberos protocol is dealing with. There are always three: two entities that want to authenticate to one another (e.g., a user and a resource server) and an entity that mediates between the two, a trusted third party, or, in Kerberos terminology, the key distribution center (KDC).

5.1.1 Kerberos advantages

In this section, we will explain the key differences between the NTLM and the Kerberos authentication protocols and the advantages that Kerberos brings to the Windows 2000, Windows XP, and Windows Server 2003 operating systems and their users. Many of the terms used in this section will be explained in greater detail later on in this chapter.

Faster authentication

The Kerberos protocol uses a unique ticketing system that provides faster authentication:

• Every authenticated domain entity can request tickets from its local Kerberos KDC to access other domain resources.

• The tickets are considered as access permits by the resource servers.

• The ticket can be used more then once and can be cached on the client side.

When a resource server or the KDC gets a Kerberos ticket and a Kerberos authenticator from the client, the server has enough information to authenticate the client. The NTLM authentication protocol requires resource servers that are not domain controllers, to contact a domain contoller in order to validate a user’s authentication request (this process is known as pass-through authentication). Thanks to its ticketing system, Kerberos does not need pass-through authentication. This is why Kerberos accelerates the authentication process. A downside to the ticketing system is that it puts a greater workload on the client. On the other hand, it offloads the resource servers; they must not bother about pass-through authentication anymore.

Mutual authentication

Kerberos supports mutual authentication. This means that the client authenticates to the service that is responsible for the resource and that the service also authenticates to the client. This is a big difference from NTLM. The NTLM challenge-response provides only client authentication: The server challenges the client, the client calculates a response, and the server validates that response. Using NTLM, users might provide their credentials to a bogus server.

Kerberos is an open standard

Microsoft based its Kerberos implementation on the standard defined in RFC 1510 (this is Kerberos Version 5). This is why Kerberos can provide single sign-on (SSO) between Windows Server 2003 and other OSs supporting an RFC 1510-based Kerberos implementation. RFC 1510 can be dowloaded from the Internet Engineering Task Force (IETF) at http://www.ietf.org.

Over the past years, Microsoft has been actively involved in the Kerberos standardization process. Microsoft software engineers participated in the creation of several Kerberos-related Internet drafts (see also http:// www.ietf.org).

Support for authentication delegation

Authentication delegation can be looked at as the next step after impersonation: Thanks to impersonation, a service can access local resources on behalf of a user; thanks to delegation, a service can access remote resources on behalf of a user. What delegation really means is that user A can give rights to an intermediary machine B to authenticate to an application server C as if machine B was user A. This means that application server C will base its authorization decisions on user A’s identity rather than on machine B’s account. Delegation is also known as authentication forwarding. In Kerberos terminology this basically means that user A forwards a ticket to intermediary machine B, and that machine B then uses user A’s ticket to authenticate to application server C.

You can use delegation for authentication in multitier applications; an example of such an application is database access using a Web front end. In such a setup the browser, the Web server, and the database server are all running on different machines. In a multitier application, authentication happens on different tiers. In such application if you want to set authorization on the database using the user’s identity, you should be capable of using the user’s identity for authentication both on the web server and the database server. This is impossible if you use NTLM for authentication on every link, simply because NTLM does not support delegation. We will come back to delegation in greater detail later on in this chapter.

Support for the smart card logon feature

Through the Kerberos PKINIT extension, both Windows 2000 and Windows Server 2003 include support for the smart card logon feature. The smart card logon feature provides much stronger authentication than the password logon feature does because it relies on a two-factor authentication: To log on, a user needs to possess a smart card and know its PIN code. The smart card logon feature also offers other security advantages; for example, it can block Trojan horse attacks that try to grab a user’s password from the system memory.

* Remember from the previous chapter that Kerberos can only be used for domain logon to a Windows 2000 or Windows Server 2003 domain.

† This was the case for NTLM version 1; this problem has been resolved in NTLM version 2.

5.1.2 Comparing Kerberos to NTLM

Table 5.1 compares Kerberos, the default authentication protocol of Windows 2000 and Windows Server 2003, to NTLM, the default authentication protocol of NT4. It also lists the main features of both protocols introduced in the previous sections.

^[1]More historical information on the MIT Athena project is available from the following URL: http://www-tech.mit.edu/ V119/N19/history_of_athe.19f.html.