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.
Register
