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.

The Microsoft Management Console (MMC) Active Directory Users and Computers snap-in (which Figure 1 shows) is the most advanced account-administration tool available as part of the base OS. It provides support for features such as template accounts (which you can use to generate new accounts based on the predefined template) and saved AD queries. (In Windows XP and Win2K Professional, this snap-in is available only when you've installed Administrative Tools.)

You can use the Ds commands to administer AD objects. This series of commands includes Dsadd (to add objects), Dsmod (to modify objects), Dsget (to list objects), Dsquery (to query AD), Dsrm (to remove objects), and Dsmove (to move objects). For example, to add user Joe to the Brussels organizational unit (OU) in the HP.net domain database, I'd type

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.

You can use the User Accounts dialog box (in XP Pro) or Users and Passwords dialog box (in Windows 2003 or Win2K). On a Windows 2003 or Win2K standalone machine, you can access the Users and Passwords dialog box from the Control Panel Users and Passwords applet. In Windows 2003 or XP, you can reach the dialog boxes by opening the Run dialog box and typing

control userpasswords2

You can open the MMC and add the Local Users and Groups snap-in. You can also access this snap-in by clicking Advanced on the Advanced tab of the User Accounts dialog box.

You can use the Net User command to administer user accounts in the SAM or AD. However, when dealing with domain accounts from the command line, the Ds series of commands is more powerful because those commands use the AD APIs (the Net User command uses the NT4 APIs).

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:

Don't use the Administrator account as an everyday account. Doing so can result in malicious code executing with Administrator privileges on a local machine. Users should always use accounts that have fewer privileges than the Administrator account does. When users need to perform security-related maintenance or administrative tasks, they can switch to the security context of an Administrator account by using tools such as runas.exe.

Choose a strong password for the Administrator account.

Rename the Administrator account. To do so, open the User Accounts dialog box, go to the Users tab, select the Administrator account, click Properties, then edit the User name text box, which Figure 2 shows. Or, you can use Group Policy Object (GPO) or Local Security Policy settings. To do so, use the Accounts: Rename the Administrator account option. Be aware that this step isn't enough by itself; the account can still be recognized by its SID, which always ends in 500.

If you have another account with administrative privileges on your Windows 2003 or XP system, you can disable the Administrator account. The Administrator account can't be disabled in Win2K, but you can prevent it from logging on by giving it the Deny logon locally user right.

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:

If you don't need to use the account, confirm that it is disabled.

Rename the Guest account.

Prevent Guest account network logon. Make sure that the Guest account is given the Deny access to this computer from the network user right.

Prevent the Guest account from being able to shut down the system. By default, the account is prohibited from doing so, but double-check to be sure that the Guest account doesn't have the Shut down the system user right and that systems can't be shut down by accounts that haven't logged on. To do so, be sure that the Shutdown: Allow system to be shut down without having to log on security option isn't enabled in the local security policy or Group Policy settings.

Prevent the Guest account from accessing the Application and System logs. To do so, open the HKEY_LOCAL_MACHINE\SystemCurrentControlSet\Services\Eventlog registry subkey, then make sure that each of the Application and System subkeys contains the RestrictGuestAccess REG_DWORD entry and that the entry's value is set to 1. (Be sure to back up your registry before making any changes and proceed with extreme caution.) You don't need to follow this procedure for the Security log because the Guest account is prohibited by default from accessing that log.

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_MACHINE\Software\Microsoft\Windows NT\CurrentVersionWinlogon\SpecialAccounts\UserList 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_ MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System 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.