Building blocks of an impenetrable network

Consider the adage "A chain is only as strong as its weakest link." You might be surprised to discover that the weakest link in your organization's high-tech security chain is an imperfect understanding of Windows NT security basics. Even if you're migrating to Windows 2000, a comprehensive understanding of NT security is invaluable because it provides the foundation for a deeper understanding of Win2K. That foundation might not be as rock-steady as you think.

Several popular misconceptions persist regarding NT's "centralized" security capabilities. Many people think that an NT domain's PDC completely controls security for the entire domain, but that idea couldn't be further from the truth. NT security is woefully decentralized. NT security is a complex combination of tightly integrated control areas, such as account policy, user rights, audit policy, ACLs, audit control lists, administrative authority, and system services. The mix becomes even more complicated when you factor in domains and trust relationships. Although domain-level security affects each system in the domain, each NT workstation or server that isn't a domain controller (DC) also functions independently with regard to security. Furthermore, you can control local security on each machine at several levels (e.g., the system level, the object level).

To fully protect your entire domain, you need to understand the interaction between domain-level security and each system's independent security. You also need a complete understanding of how each host-level security control area works. At every level, important configuration tips can help you keep your computers locked down against the bad guys.

Local Security at the System Level
Each NT computer maintains a local SAM database under the HKEY_LOCAL_MACHINE\SAM registry subkey. The local SAM stores the computer's local user accounts, groups, rights assignments, and account policy. The user accounts in a computer's local SAM are also known as machine local accounts because they permit users to log on to and access resources on only the local computer. Likewise, the user groups in a computer's local SAM are known as machine local groups and can access objects only on the local system. (In contrast, domain users and domain groups can access objects on any computer in a domain.)

To view and maintain a computer's machine local accounts and machine local groups, log on at the computer and open User Manager (under Administrative Tools). This tool maintains everything in the local SAM, including account policies, user rights, and audit policy.

Account policy. Select Policies, Account from User Manager's menu bar to open the Account Policy dialog box, which Figure 1 shows. The password and lockout specifications in this dialog box govern the computer's machine local accounts. You can require users to select passwords that meet a minimum length, force users to change their passwords on a regular basis, and prevent users from reusing passwords. You can also implement an account lockout policy to slow down attackers who try to access the system by guessing passwords.

User rights. Select Policies, User Rights from User Manager's menu bar to open the User Rights Policy dialog box. A user right (which NT sometimes refers to as a privilege) is the authorization to perform some type of system-level function. For example, to log on at the local console, you need the Logon locally right. The User Rights Policy dialog box lists the local computer's user rights assignments.

Audit policy. Select Policies, Audit from User Manager's menu bar to open the Audit Policy dialog box, which Figure 2 shows. This policy determines the types of security events that NT will log in the computer's local Security log. NT provides seven audit categories that let you monitor such events as logon activity, file access, program execution, security policy changes, and user accounts changes. You can instruct NT to record failed or successful events for each category. (For a list of articles about auditing and the NT Security log, see "Related Articles in Previous Issues.")

To view the local Security log, open the NT Event Viewer (under Administrative Tools) and select Log, Security from the menu bar. To configure the log, select Log, Log Settings to open the Event Log Settings dialog box.

You can configure a maximum size for the Security log and specify what the computer should do when the log reaches that size. You can choose to have the system overwrite events as necessary; the computer will overwrite the oldest events in the log as it records new events. You can configure the system to overwrite events that are older than a specific number of days; when the log fills, the computer will discard events older than the specified number of days. (If no events meet the expiration criteria, the system stops logging events until older events expire.) Or you can tell the system not to overwrite events; in that case, you'll need to clear the log manually on a regular basis because the system will simply stop logging events when the log is full. (Increasing the size of a full log doesn't restart logging; you must clear events from the log to make space for new events.)

Other Local Security Control Areas
Whereas you can configure the account policy, user rights, and audit policy control areas at the system level through the SAM, several other control areas—ACLs, audit control lists, administrative authority, and system services—operate independently of the SAM.

ACLs. You can use object-level permissions to access objects such as files and folders. Each object has a list of permissions, called an ACL, that defines the users and groups that can access the object and how they can access it. Don't confuse permissions with rights; these are entirely different animals in NT. You assign rights at the system level through User Manager, as I described earlier. You define permissions at the object level through ACLs.

To view a file's ACL, open Windows Explorer, right-click the file, then select Properties. Go to the Security tab and click Permissions. NT grants a user cumulative access according to the user's group memberships. For example, Figure 3 shows the ACL of a sample file called budget.doc. Members of the SalesReps group have Change (i.e., Read and Write) access to budget.doc. However, users who are also members of the RestrictedUsers group can't access the file because the file's ACL specifies No Access for that group. No Access overrides permissions from other group memberships.

Audit control lists. Each object also has an audit control list that defines the types of object access that NT should record in the local Security log. For each type of access (e.g., Read, Write, Delete), you can specify whether NT should record successful or failed events. For example, to log instances of users trying to read a confidential document to which they don't have access, enable auditing for that document so that NT records failed Read attempts by members of the Everyone group. To track changes to a file, enable auditing for that file so that NT records successful Write attempts. (To learn more about object auditing and audit control lists, see "Interpreting the NT Security Log," April 2000.)

To view a file's or folder's audit control list, open Windows Explorer, right-click the object, then choose Properties. Go to the Security tab and click Auditing. To view a registry key's audit control list, open regedt32, select the key, then select Security, Permissions or Security, Auditing from the menu bar.

Administrative authority. NT's built-in Administrators and Power Users groups give you the means to control administrative authority. Members of the Administrators group can share directories and printers, create and manage machine local accounts and machine local groups in the computer's local SAM, assign user rights, and set audit policy. Members of the Power Users group can share directories and printers and create and manage machine local accounts and machine local groups.

System services. Services are doorways into your NT system for access from over the network, so you need to identify all the services running on each computer and determine whether you should disable any of those services. To view a local system's services, open the Control Panel Services applet. To view a remote system's services, open Server Manager (under Administrative Tools), select the desired computer, then select Computer, Services from the menu bar. (If you don't find Server Manager on your system, simply copy srvmgr.exe to your system from a DC.)

Domain-Level Security
Although NT systems can function independently and securely without the benefit of a domain, relying solely on host-level security has drawbacks when your network has many users who need access to resources on several servers. When a computer isn't a member of a domain, users must use a machine local account in the computer's SAM to log on to that computer. Without a domain, each user needs multiple user accounts—one for each server that he or she needs to access. Multiple accounts per user mean multiple problems. Users are burdened with the chore of synchronizing passwords for each account. And when employees depart from the company, you must find and delete each of their accounts. You can easily miss one account and wind up with a residual access problem (i.e., users who can still get into your network long after they've left the company). To easily relieve all these headaches, create a domain and give each user one domain account that's valid for all the servers the user needs to access.

When a workstation or member server joins a domain, it doesn't lose any of its computer-specific security settings; rather, it gains additional domain functionality. After a server or workstation joins a domain, the machine trusts the domain's DCs to authenticate domain users. Therefore, users can log on by using a machine local account or a domain account. After a computer joins a domain, you can also add domain users and domain groups to the ACLs of files and other objects on the computer. NT automatically adds the domain's Domain Admins group to the computer's local Administrators group. (This action explains why members of Domain Admins have administrator access to every computer in the domain. For information about implementing custom administrative control, see "NT Security: Establishing Custom Administrative Control," http://www.win2000mag.com, InstantDoc ID 4871.)

Whereas member servers' or workstations' SAMs are specific and limited to one computer, a DC's SAM isn't. A PDC's SAM is the SAM for the entire domain, and User Manager for Domains automatically opens the PDC's SAM. When you create a user or group or change a policy in User Manager for Domains, the utility records the change in the PDC's SAM. Minutes later, the PDC replicates that change to each BDC's SAM. Therefore—taking latency between replication cycles into consideration—all the DCs in a given domain share a duplicate SAM and have the same user accounts, groups, and policies. For example, when you activate auditing in User Manager for Domains, you turn on auditing for the PDC. As replication occurs, NT activates auditing on each BDC.

Domain vs. Local Control
As well as gaining additional domain functionality, an NT computer's security configuration functions independently after you add the computer to a domain. Changes that you make through User Manager for Domains have no effect on the policies or user rights of member servers and workstations. For example, when you use User Manager for Domains to assign the Logon locally right to Peter, you authorize him to log on at the consoles of every DC in the domain. However, if he needs to log on at a member server in the domain, you need to log on at that server and grant Peter the right locally through User Manager.

Account policy and audit policy that you specify at a DC have nothing to do with the locally defined account and audit policy on member servers and workstations. For example, suppose you log on to a DC, open User Manager for Domains, and configure a minimum password length. This action has no effect on the machine local accounts defined in a member server's or workstation's SAM, so if your local account policies are lax, you have a dangerous situation. Attackers aren't picky: They're just as happy to use a local account to invade a system as they are to use a domain account.

Thus, you should avoid creating many machine local accounts. Instead, give each user one domain account, which is valid for every computer in the domain. If you run into a situation in which an administrator has created machine local accounts on a member server or workstation, you can reconfigure the member server's or workstation's local SAM from over the network. Simply copy User Manager for Domains (usrmgr.exe) from any NT server to your workstation. Open the program and select User, Select Domain, but don't enter a domain name. Instead, enter two backslashes and the name of a remote computer (e.g., if you want to configure the SAM on a computer named kramer, type \\kramer). To verify that you're looking at the remote system's SAM as opposed to the domain SAM, look at the window's title bar, which will include two backslashes.

NT domain security isn't as centralized as it might seem. Each computer has a discrete configuration of hundreds of security options that require your attention. Even in a domain environment, only user accounts and user groups are truly centralized—and only if you avoid creating machine local accounts on member servers. Therefore, complete knowledge of basic NT security options is a cornerstone of a secure network.

Related Articles in Previous Issues
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com.

RANDY FRANKLIN SMITH
"Archiving and Analyzing the NT Security Log," August 2000, InstantDoc ID 9043
"Protecting the NT Security Log," July 2000, InstantDoc ID 8785
"Monitoring Privileges and Administrators in the NT Security Log," June 2000, InstantDoc ID 8696
"Interpreting the NT Security Log," April 2000, InstantDoc ID 8288
"Introducing the NT Security Log," March 2000, InstantDoc ID 8056