A Matter of Trust

Windows security authorities embody the concept of trust that lies at the center of the OS's security model. Security authorities reign over shared resources and use a database to store the security-related information that's needed to allow or deny access to those resources. Users trust security authorities to adequately protect such access. Sound theoretical? Believe it or not, understanding these concepts and the principles by which they operate is key to building a secure Windows environment. Let's take a look at several fundamental security building blocks, how they interact, and how you can maximize their effectiveness.

Know Your Boundaries: Domains and Domain Controllers
Bringing multiple resources (e.g., files, printers, applications) together under the rule of a security authority facilitates security-policy enforcement and enhances ease of use for both users and administrators. A Windows domain is an administrative grouping of users, machines, and shared resources that can be managed by different administrators.

In Windows NT 4.0 and earlier, the domain is more than a management boundary, it's also a security boundary. However, the introduction of the forest in Windows 2000 changed that. In Win2K and later, the forest is the true security boundary, and the domain functions as an Active Directory (AD) namespace replication partition. AD is the LDAP- and X.500-based directory that Microsoft introduced in Win2K. An AD namespace replication partition defines a subset of the data that resides in AD and that's replicated and synchronized between AD copies on different domain controllers (DCs). The most important AD replication partitions are forest-wide replication and domain-only replication. In forest-wide replication, AD data (e.g., site-configuration data) is replicated among all the DCs in an AD forest. In domain-only replication, a subset of AD objects (e.g., user accounts and their password hashes) are replicated among the DCs in a domain.

A forest is made up of one or more domain trees. In a domain tree, domains are linked together through parent-child domain trust relationships, and all domains have a contiguous DNS namespace. When a forest is made up of multiple domain trees, the trees are linked together through peer-to-peer trust relationships that are set up between the domain trees' top-level domains, and the trees have a non-contiguous DNS namespace. Domain administrators must have a certain level of trust in their enterprise's forest administrators as well as in the other domain administrators in the forest; the latter have access to the AD database such that they can add, delete, or change objects elsewhere in the forest. (For more information about trust relationships, see "To Trust or Not to Trust," April 2005, InstantDoc ID 45553.)

Even when you have only one file server, you should incorporate it in a domain. Domains ease security administration and close possible security holes. For example, suppose a user needs to access multiple application servers. When you include these servers in a domain, you need define the user only once (in the domain database) instead of having to define the user on each application server. You also reduce the attack surface of your Windows servers (as well as the chance that your resources will be accessed by unauthorized users) when you build your security infrastructure on a single security database—the domain database—instead of relying on the multiple databases—one for each application server—necessary in a standalone-server setup.

A DC is a domain's security authority. The DC hosts the domain's security database, authenticates security principals (i.e., the entities that want to use the resources) and secures access to the resources that are part of the domain—a process known as access control.A domain can hold multiple DCs, each of which hosts a copy of the same AD domain security database. This database contains identifiers (e.g., usernames) and authentication credentials (e.g., secured copies of user passwords) of domain security principals. The AD domain security database in Windows Server 2003 and Win2K replaces the SAM database used in NT 4.0. Whereas in NT 4.0, only the PDC hosts a read-write copy of the domain database and all other DCs hold a read-only copy and serve as BDCs, every Windows 2003 or Win2K DC contains a read/write copy of the domain directory database.

Windows also supports another type of security authority: the Local Security Authority, or LSA. The LSA is available on every domain and standalone Windows machine. Even DCs have an LSA, which is activated only when the DC boots in Recovery Console mode. One of the LSA's tasks is to validate local logons.

Using Resources: Security Principals and Accounts
Security principals are entities that want to use the resources (e.g., files, printers), applications, or services that a Windows computer hosts. A security principal can be a user, a computer, a service, or an application. Each security principal has a unique identifier. Unique identification makes it possible to distinguish security principals from one another and lets you give them different levels of access to resources. The unique identifiers that Windows uses to refer to security principals are logon names and SIDs. Logon names are user- and administrator-friendly identifiers that are easy to read and remember. SIDs are unique alphanumerical identifiers that the OS's internal security processes use to refer to a principal. To find out the SID that's associated with your security principal, open a command prompt and type

whoami /logonid

if you're using the Whoami tool that comes with Windows 2003; type

whoami /user /sid

if you're using the version that comes with the Microsoft Windows 2000 Server Resource Kit.

Security principals can be used in the context of both an LSA and a DC. A security principal's entry in an LSA's or DC's security database (i.e., the SAM or AD) is referred to as an account. Local accounts can be used to secure access to a machine's local resources (e.g., files, folders, printers, applications, services); domain accounts can be used to secure access to resources on any computer in the account's domain or a trusting domain. Different tools are available to create, delete, and modify domain accounts in Win2K and later.

dsadd user "cn=Joe,ou=  Brussels,DC=HP,DC=Net

To administer local machine accounts on domain-joined machines, you can use the following tools. All these tools manipulate user account data in the LSA database or SAM.

control userpasswords2

Protecting Resources: Securing Key Accounts
Every Windows installation has a set of predefined accounts that are automatically generated when the OS is installed. The most important of these are the Administrator account and the Guest account.

Securing the Administrator account. The Administrator account is the most privileged account on a Windows system. In the context of a local machine, the administrator has full control over local resources and has permission to create, modify, or delete other local accounts. The same is true for a domain administrator regarding domain resources and domain accounts. Because the Administrator account offers the key to the kingdom, so to speak, the account is a favorite hacker target. Security's most fundamental principle is defense in depth, which means you shouldn't rely on a single solution but rather on a combination of solutions to achieve maximum security. To secure the Administrator account:

Securing the Guest account. The Guest account is a low-privilege Windows account that can be used by users who don't have a defined account and who need occasional access to a Windows system. Users logging on with the Guest account can access local data and applications but can't install software or hardware. Even though the Guest account has a limited set of privileges, malicious anonymous users can use it to access system resources. The Guest account is disabled by default, but you still need to take steps to secure it. Hackers who gain Administrator access can easily enable the Guest account, but their attacks will be more difficult to carry out if they need to change multiple security settings. To secure the Guest account:

Enter with Care: Logging on
Logging on to Windows is a necessary process that can open up some security holes. Windows XP users can log on to a standalone Windows machine from the Welcome screen or by using the classic Windows logon sequence. The classic Windows logon sequence is the only option when logging on to a Windows 2003 or Win2K system or a domain-joined XP system. In a classic Windows logon sequence, a user can bootstrap the logon process by pressing Ctrl+Alt+Del (aka secure logon or the Secure Attention Sequence—SAS) to log on to a machine or a domain. The Welcome screen lets users bootstrap the logon process by clicking their user account on the Welcome screen.

Two important security disadvantages of using the Welcome screen are that it displays user account names and can give password hints for local accounts. One thing you can do to make the Welcome screen more secure is hide local user accounts from it. To do so, you can create a special local group, add to this group the local user accounts you want to hide, then make sure these accounts aren't members of the built-in Administrators, Guests, Power Users, or Users groups. By default, the Welcome Screen only displays accounts that are members of these groups. Or, you can edit the registry: open the HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogonSpecialAccountsUserList registry subkey, create a new REG_DWORD entry, set its name to the username of the local user account you want to hide, and set the entry's value to 0.

Another option is to prevent the use of the Welcome screen for logging on to a standalone Windows XP machine. To enforce the use of secure logon, you can select the Require users to press Ctrl+Alt+Delete check box on the Advanced tab in the User Accounts dialog box (as Figure 3 shows). You can also clear the Use the Welcome screen check box in the Control Panel User Accounts applet's Select logon and logoff options page. Or, you can set the LogonType registry entry (under the HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystem subkey) to 1.

Logging on—locally or to the domain—from the Welcome screen or through a secure logon is referred to as an interactive logon or local logon. A valid interactive logon results in a logon session. When a user wants to access a resource on another machine during a logon session, another authentication process, called a non-interactive logon or network logon must occur. A valid non-interactive logon results in a network logon session.

When logging on to a standalone Windows 2003, XP, or Win2K computer, user authentication is an option. The Windows security authority can be configured to give the user access to resources without verifying the user's identity by using a set of credentials. This feature is referred to as autologon. (Authentication is always required when logging on to a Windows domain.) To prevent autologon, select the Users must enter a user name and password to use this computer check box in the User Accounts dialog box.

To authenticate users, Windows can use different types of authentication credentials. The credentials can be simple passwords, or they can be based on smart cards or biometric data. Out of the box, Windows 2003, XP, and Win2K support password- and smart card­based authentication. Support for other authentication methods can be added by using third-party software.

Crucial Fundamentals
Some of the most fundamental Windows security concepts seem somewhat basic and theoretical, but it's vital that you understand their roles and features. Doing so can save you a great deal of time by preventing Windows security problems.