4.3 Authentication authentication architecture

This section explains the Windows authentication architecture. As you will notice, the architecture used in Windows Server 2003 is not much different from the one used in earlier Windows versions.

4.3.1 Terminology

In a Windows environment, a user bootstraps the authentication process by pressing CTRL+ALT+DEL [this is known as the Secure Attention Sequence (SAS)] to log on to a machine or a domain. Microsoft calls this method of authenticating a user to the Windows system an interactive logon feature or local logon feature. A valid interactive logon feature results in a “logon session.” If a user wants to access a resource that is located on another machine during its logon session, another authentication process will be started: This authentication process is referred to as a noninteractive logon method or network logon method. A valid noninteractive logon method results in a “network logon session.”

Besides interactive and noninteractive logon methods, Windows also supports two other logon methods: the batch logon method and the service logon method. The batch logon method is used by task schedulers (e.g., the “at” or “WINat” service); the service logon method is used by services. All of them have slightly different architectures.

Every entity that authenticates to a Windows system is called a “principal.” A principal is identified by its Security Identifier (SID); to prove its identity during an authentication process, a principal uses credentials. Credentials allow principals to be distinguished from one another and to identify them. Examples of credentials are a principal’s account name and its password. If the operating system accepts this type of credentials for authentication, the fact that the principal knows its account name and password is regarded by the operating system as a proof of its identity. Do not confuse principal and account: An account is a record in an authentication authority’s database; a principal is an entity that can be identified by a Windows system. These concepts were explained in great detail in Chapter 2.

The authentication authority differs depending on what you are logging on to. If you log on locally to a machine, it is the Local Security Authority (LSA) on the machine itself, but if you log on to a domain, authentication is performed against the LSA of a domain controller. To be able to validate a principal’s identity, the authentication authority needs a copy of a principal’s credentials, which are stored in the authentication database.

A Windows Server 2003 authentication process can use different authentication protocols: NTLM (NT LAN Manager), Kerberos, and SSL (TLS). The way support for these protocols is embedded in the Windows Server 2003 authentication architecture is explained in Section 4.3.2.

4.3.2 Architecture

Since its early days, one of the most important design principles of NT has been modularity. NT’s authentication architecture is an excellent example of a modular architecture built on different abstraction layers. In Windows Server 2003, this architecture is basically the same as the one used in Windows 2000 and NT4. Ninety percent of the changes that Microsoft incorporated can be described as plugging in supplementary security modules. In the following sections we discuss the authentication architectures for inter- active (local) and non-interactive (network) logon.

Architecture for interactive authentication

The architecture for interactive authentication is illustrated in Figure 4.2. An interactive authentication sequence starts whenever a user initiates an SAS sequence. This makes the Winlogon service call the GINA module. GINA stands for Graphical Identification and Authentication. Winlogon is the OS component that provides interactive authentication. GINA is the component responsible for displaying the logon interface, extracting the user’s credentials, and passing them to the LSA.

Figure 4.2: Interactive authentication architecture.

The LSA is an OS kernel component that can act as a local authentication authority: It interacts with local and remote authenticaton databases, and authentication packages. When logging on locally to a machine it will interact with the local authentication database. When logging on to a domain it will interact with the domain authentication database (which can be on the local or a remote machine).

Authentication packages are software packages that implement different authentication protocols. In NT4 the only available authentication package was MSV1_0. MSV1_0 was the package that performed a pass-through authentication if there was no credential store (a SAM database) available locally to validate the user’s credentials. Software vendors can implement their own authentication package to support other authentication protocols. The MSV1_0 authentication package is still supported in Windows 2000, Windows XP and Windows Server 2003.

You can find out which authentication package dlls are available at your machine by looking into the following registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Authentication Packages.

The authentication database stores secured copies of the credentials needed during the authentication process. NT4 machines, Windows XP, Windows 2000 Professional workstations, and Windows 2000 and Windows Server 2003 member servers store credentials in the SAM database. In this case the SAM database contains local user accounts that can be used to log on locally to a machine. A Windows 2000 and Windows Server 2003 domain controller stores credentials in the Active Directory. The Active Directory database contains domain user accounts that can be used to log on to a Windows domain.

Architecture for noninteractive authentication

Figure 4.3 provides a simplified overview of the noninteractive authentication architecture used in a distributed application consisting of a client and a server component. A good example of a distributed application is an Out- look client accessing an Exchange mailbox. This architecture introduces two new important concepts: the Security Support Provider Interface (SSPI) and Security Support Providers (SSPs).

Figure 4.3: Noninteractive authentication architecture.

The communication between the client and the server component happens via communication protocols. These protocols can be typical LAN communication protocols such as SMB and RPC, or typical Internetoriented communication protocols such as HTTP, POP3, NNTP, and LDAP.

The SSPI is an Application Programming Interface (API), sitting between the communication protocols and the security protocols. It has two important functions:

• Its primary function is to abstract the commonalities of different authentication protocols and to hide their implementation details. For example, Kerberos and NTLM both use the concept of a master key; NTLM, however, uses a challenge-response mechanism, while Kerberos relies on a ticketing system.

• Abstract communication protocols from security protocols. A security protocol should be available to any communication protocol, or, in other words, the implementation of a security protocol should not contain any communication-protocol–specific code.

An SSP is a software module that implements a security protocol. SSPs can be plugged into the SSPI. Out-of-the-box Windows Server 2003 supports the following SSPs: MSV1_0 (supporting both NTLM versions 1 and2), Kerberos, SChannel (secure channel support using the SSL and TLS protocols), and Digest Authentication. NTLM is the default authentication protocol of NT4—it is explained in more detail later in this chapter. Digest Authentication is a challenge-response-based protocol that can be used in Web environments (for more information, see Chapter 6). Software vendors can also implement their own SSPs to provide other security models.

To get an overview of the SSPs supported on your machine, have a look at the following registry key: HKEY_LOCAL_MACHINE\System\Current- ControlSet\Control\Lsa\Security Packages.

Notice in Figure 4.3 that SSPs access authentication packages via the LSA. This figure also shows that the LSA communicates with the authentication database; remember from an earlier section that the LSA validates credentials by comparing them with the entries in its authentication database. One thing that Figure 4.3 does not show is that most SSPs rely on Cryptographic Service Providers (CSPs), modules that provide basic cryptographic functions, for example, encryption using the Data Encryption Standard (DES), signing using RSA, or hashing using Message Digest 4 (MD4). SSPs can call on different CSPs thanks to another abstraction layer that was introduced in NT4: the CryptoAPI (or CAPI). We will come back to CAPI in Chapter 13.

Because the model shown in Figure 4.3 contains multiple authentication protocols (SSPs), there has to be some kind of negotiation between the client and the server before the actual authentication can take place. To enable the negotiation, Microsoft included a special SSP called “Negotiate.” Its operation is illustrated in Figure 4.4. This package is based on the SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) Inter- net draft (RFC 2478: The Simple and Protected GSS-API Negotiation Mechanism). In order to negotiate an authentication protocol, the Negotiate package has to know how to communicate with the corresponding authentication package. So far, the Negotiate SSP can only deal with the Kerberos and NTLM package.

Figure 4.4: Role of the Negotiate SSPI.

So how does this negotiation work? The first SSP called by the SSPI when a call for authentication comes in is the Negotiate SSP. The client Negotiate package then sends a list of available SSPs to the server. Finally, the server Negotiate package picks an SSP based on its locally available SSPs and communicates it to the client. Although this negotiation clearly adds some communication overhead, it offers much more flexibility.

In Windows 2000, Windows XP, and Windows Server 2003, the Negotiate SSP’s first choice for authentication is Kerberos. It will fall back to NTLM if:

• The Kerberos KDC service in their domain is unavailable.^[1]

• A service’s Service Principal Name (SPN) is not registered (SPNs were explained in Chapter 2). For example, when a user tries to access a file share on a server whose “Host” SPN is not registered, the user will be authenticated using NTLM.

An excellent tool to get a deeper understanding of how the SSPI really works is the “SSPI workbench” tool (see Figure 4.5). It is written by Keith Brown from DevelopMentor and can be downloaded for free from http://www.develop.com/kbrown/security/samples.htm. More information on the tool is available at http://www.develop.com/kbrown/security/sample_sspibench.htm.

Figure 4.5: Using SSPI Workbench.

^[1]Kerberos only works in a domain environment—it cannot be used to logon locally to a workstation or member server. This is because the Kerberos KDC service is only available on a domain controller.