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

This chapter focuses on two building blocks of Windows Server 2003 operating system security: security authorities and security principals. Among the concepts discussed are security principal, domain, security identifier, domain controller, logon name, LSA, and LSA policy.

2.1 Security authorities

To illustrate the fundamental role of trust in the Windows Server 2003 operating system and to make the link with Chapter 1 on trusted security infrastructures (TSIs), we will first discuss the concept of Windows OS security authorities. In Windows OSs we have to deal with two types of security authorities: the local security authority (LSA) and the domain security authority. A security authority reigns over a kingdom of resources (represented by the ellipse in Figure 2.1) and has its proper database to store security-related information. We will reuse these representations as other Windows security concepts are introduced throughout this chapter.

Figure 2.1: Security authority.

2.1.1 The local security authority

The LSA is a Windows machine’s local security authority. The LSA is available on all kinds of Windows machines: both stand-alone machines and machines that are a member of a Windows domain.

Physically the LSA is a protected OS subsystem (visible in the task manager as the lsass.exe process) that is running in OS user mode. The lsass process hosts a set of other important security processes [implemented as dynamic link libraries (dlls)] that are illustrated in Figure 2.2: the LSA authority process (lsasrv.dll), the SAM process (samsrv.dll), the AD process (ntdsa.dll), the Netlogon process (netlogon.dll), and a set of authentication packages [the NTLM authentication package (msv1_0.dll) and/or the Kerberos authentication package (Kerberos.dll)]. The Netlogon process is only available on Windows domain controllers. The AD process is only available on Windows 2000 and later domain controllers. I will come back to the Netlogon process and the authentication packages in Chapter 4 on Windows authentication.

Figure 2.2: LSA process and subprocesses available on Windows domain controllers.

The LSA and its subprocesses play a crucial role in the authentication and authorization security processes. Among their tasks are security principal credential validation and access token generation. The LSA also enforces the local security policy, including the auditing policy, memory quotas, user logon rights, and privileges.

The LSA has its proper database, which is referred to as the LSA database. It holds system-specific security policy information. The information stored in the LSA database is known as the LSA policy. The objects stored in the LSA policy are known as policy objects. Physically the LSA security policy database is a secured part of the system registry.

The Security Accounts Manager (SAM) and Active Directory (AD) LSA subprocesses govern access to the local and domain credential databases. These databases contain security information about local or domain security principals. The SAM is used in all Windows versions to store local or domain security principal Hinformation. The Active Directory is used from Windows 2000 on to store domain security principal-related security information on domain controllers. The concepts of domain and security principal will be explained in greater detail later in this chapter.

The LSA database

The LSA security policy database holds different types of policy objects: policy, account, and private data objects.

• A policy object determines who can access the LSA database. It also contains global system information such as system memory quota and auditing settings. Every system has a single policy object.

• An account object contains information that is specific to a user or group (e.g., special user logon rights, privileges, and quotas).

• A private data object is used to store confidential information such as system or service account passwords. LSA private data objects are also known as LSA secrets.

There is a limit on the number of LSA secrets that can be stored in the LSA database. In Windows Server 2003 this limit is 4,096. LSA secrets are encrypted using a system-specific key and stored in the HKEY_LOCAL_MACHINE\security container of the system registry.

LSA secrets can be one of the following types: local, global, or machine LSA secrets. Local LSA secrets can only be read locally from the machine that stores them; global LSA secrets are replicated between domain controllers; and machine LSA secrets can only be accessed by the operating system. Microsoft uses special naming conventions to store these special LSA secret types in the security key of the registry: “L$” for local, “G$” for global, and “M$” or “NL$” for machine LSA secrets.

To look at the LSA secrets stored on a Windows machine, you can use regedt32.exe or the lsadump2.exe command-line tool. Either method will reveal the LSA secrets’ names and content in an encrypted format. Remember that LSA secrets are critical NT system data. After you obtain a listing, handle the listing with care and do not distribute it freely.

To use the registry editor to look at the LSA secrets, you must first change the permissions on the registry Security subkey and all its subkeys so that your account has full control access. The Security key is in the HKEY_LOCAL_MACHINE registry hive. Note that you should never change these permissions on a production system—always use a test system. Changing the permissions will reveal a new list of registry subkeys, including the Policy key. Underneath the Policy key you can find a list of LSA secrets.

Lsadump2 is a freeware tool that you can download from BindView’s Razor security team download page (http://razor.bindview.com/tools/desc/ lsadump2_readme.html). Lsadump2 lets you look at a machine’s LSA secrets from the command prompt. To run Lsadump2, your account must have debug privileges on the machine. By default, this privilege is given only to administrator accounts. Again, do not run this tool on your production systems—use a test system.

2.1.2 The domain security authority

As was explained in Chapter 1, bringing multiple resources together in a kingdom that is ruled by a trusted third party facilitates security policy enforcement and provides ease of use to both users and administrators. In Windows Server 2003 a kingdom is called a domain and a trusted third party is called a domain controller (DC).

The domain concept

As in NT4 and Windows 2000, a Windows Server 2003 domain in the first place defines a management boundary. It is an administrative grouping of users, machines, and resources.

From Windows 2000 on a domain is also an Active Directory name- space partition. Because the namespace within the Active Directory is hierarchical, the domain structure in Windows 2000 and Windows Server 2003 is made up of a series of parent-child relationships between the different domains. Windows 2000 and Windows Server 2003 allow you to build AD domain trees and forests. Figure 2.3 shows an AD forest made up of several AD trees (hp.com, compaq.com, and tandem.com). In every AD tree there are multiple hierarchical parent-child domain relationships. Domains are linked using trust relationships (explained later in this chapter) and DNS domain names. Within the different domain trees in Figure2.3, the DNS namespace is contiguous. Between domain trees there is a noncontiguous DNS namespace.

Figure 2.3: Windows Server 2003 AD domains, trees, and an AD forest.

To a certain extent, a domain is also a security boundary: it can be linked to a specific security policy that is only valid within the domain. The introduction of the forest concept in Windows 2000, however, fundamentally changed the Windows security boundaries as they existed in earlier Windows versions. From Windows 2000 on, the notion of referring to a domain as a security boundary is not completely valid anymore: The true security boundary is the forest. Domain administrators must always have a certain level of trust in the forest enterprise administrators. The latter have power in all domains in a forest.

Even though the concept of Windows Server 2003 domains, trees, and forests is completely different from the concept of a DNS domain,^[1] both concepts are closely intertwined in the context of an AD infrastructure. AD uses DNS to name and locate AD domains and objects, and every Windows Server 2003 domain is identified by its DNS domain name. In fact, the AD namespace is contained within the DNS namespace. Every AD domain tree can be mapped to a DNS domain hierarchy, and every AD domain corresponds to a DNS domain.

Domain functionality levels

The most important property of a Windows 2000 domain was its mode. The most important property of a Windows Server 2003 domain is its functionality level.

A Windows 2000 domain can be in one of the following states: mixed or native mode. A mixed-mode Windows 2000 domain provides backward compatibility with Windows NT4 or earlier DCs. A native-mode Windows 2000 domain provides additional AD functionality. In a native-mode Windows 2000 domain, all DCs are Windows 2000 DCs.

In Windows Server 2003, Microsoft provides a new set of AD functions that are only available if all the DCs are Windows Server 2003 DCs. This forced Microsoft to introduce more domain modes in order to link the correct AD functionality to a domain and its homogeneous or heterogeneous DC population. The Windows Server 2003 domain modes must be capable of differentiating between domains that are holding only Windows Server 2003 DCs and domains that contain a mixture of Windows Server 2003, Windows 2000, and NT DCs.

To deal with the domain-mode problem in Windows Server 2003 once and for all, Microsoft introduced the concept of functionality levels. It is just another name for a portable version management system that can be used in current and future versions of the Windows OS. Windows Server 2003 functionality levels not only apply to DCs and domains, but they are also applicable to forests. They allow the domain and forest functionality levels to be increased when all DCs in the domain or forest have reached the appropriate level.

Domain controllers

A domain controller (DC) is a domain’s trusted authority. It hosts the domain security database and authenticates security principals for domain resource access. A domain can contain multiple DCs. All DCs hold a copy of the same domain security database. The security database contains the identifiers and authentication credentials of the different domain security principals. The use of a centralized security database simplifies centralized security administration.

The domain security database of Windows 2000 and Windows Server 2003 is the Active Directory. It replaces the SAM that was used in Windows NT 4.0. In Windows 2000 and Windows Server 2003, every domain controller contains a read-write copy of the domain directory database. This is different from Windows NT4 where the Primary Domain Controller (PDC) was the only one to host a read-write copy. All other Windows NT4 domain controllers held a read-only copy of the domain database and served as Backup Domain Controllers (BDCs). The NT4 domain security database replication model is referred to as a single-master replication model. The Windows 2000 and Windows Server 2003 models are referred to as a multi-master replication model.

Domain controller FSMO roles

Windows Server 2003 DCs can have (just like Windows 2000 DCs) special roles in a Windows Server 2003 domain or forest. These roles are called Flexible Single Master of Operations (FSMO) roles. FSMO roles exist because some of the AD services must operate in a single-master mode— even though the bulk of the AD services are built on a multimaster model. Table 2.4 gives an overview of the different FSMO roles. The PDC emulator, RID master, and infrastructure master FSMO roles are security-related.

^[1]An AD domain stores objects; a DNS domain stores resource records.