Some of the main topics in this chapter are
This chapter explores policy management in Window NT. Three policies are explored in this chapter. First, the System Policy is configured with the System Policy Editor. A System Policy is a combination of user and computer settings that control a user's working environment. Second, the Account Policy is used to administer user accounts. You also learn how to implement audit policies, which tracks what users do on the server. And, finally, the User Rights Policy controls the actions users and groups can perform. In addition, you will learn about trust relationships because they are part of policy management.
Windows NT Server 4.0 contains a utility called the System Policy Editor that enables you to edit the System Policy. A System Policy is a combination of user and computer settings that controls a user's working environment. In effect, system policies combine a user profile with a computer profile. Just like a user profile, the user policy overwrites the settings in the current user branch in the Registry. The computer policy overwrites the settings for the current local machine branch of the Registry.
The System Policy is stored in a file named NTConfig.pol, located in the Netlogon folder of the primary domain controller (PDC). When a user logs on, Windows NT checks the Netlogon folder for NTConfig.pol and, if the file exists, uses its contents to overwrite the current user and local machine portions of the user's Registry. Because it is applied to all users who log on to the domain, the System Policy provides a means of ensuring a consistent and uniform policy for all users. If you need to further customize the policy, you can adapt the System Policy for specific users, computers, and groups.
At the time of install, the System Policy Editor is installed into the Windows NT's root directory. To run this program, click Start, Programs, Administrative Tools, System Policy Editor. Figure 27.1 shows the System Policy Editor, which enables you to create and maintain the System Policy.
This is the System Policy Editor main window from which you open or create system policies.
The System Policy can contain settings for all users (Default User), all computers (Default Computer), and entries for specific users, computers, and groups. When you first start the System Policy Editor, it is empty. To add the Default User and Default Computer objects to the policy, choose File, New Policy. System Policy Editor adds icons for the Default Computer and Default User to document the area of the editor.
NOTE: You don't have to add the Default Computer and Default User settings to the System Policy. Instead, you can simply add custom settings for specific users, groups, and computers. The users' profiles will then be used to define their working environments, rather than the System Policy.
To modify user settings that apply to all users, double-click the Default User icon, or select the Default User icon and press Enter or choose Edit, Properties. System Policy Editor displays a Default User Properties page, as illustrated in Figure 27.2.
The Policies page of the Default User Properties sheet enables you to control settings that affect all users' operating environments.
To view or change a setting, expand or collapse the branches in the Policies page. Each branch contains check boxes that control various settings. Some check boxes work alone, and others work in conjunction with other controls, such as text boxes and sliders. When you select a check box, these additional controls appear at the bottom of the Policies property page.
The six branches on the Policies page are:
Double-clicking the Default Computer icon displays a Policies page containing settings that control the computer's hardware. Figure 27.3 shows this screen.
The setting for Default Computer overrides the Registry settings.
The branches of this dialog box enable you to alter the operation of the computer and the computer's hardware, even beyond the settings in the computer's Registry.
The seven branches on the computer Policies page are:
After you specify the desired settings, you can add other computers, users, or groups. By adding specific users, groups, and computers to the System Policy, you can override the Default User and Default Computer settings for specific users. This capability gives you great flexibility in customizing the System Policy while still maintaining consistency where desired.
To add other users, groups, or computers, choose Edit, Add User; Edit, Add Computer; or Edit, Add Group. System Policy Editor displays a dialog box that enables you to type the name of the entity or browse for the name. When you add an entity, an icon for it appears in the document portion of the System Policy Editor window. As with the Default User and Default Computer icons, you can double-click the icon for the entity to change its settings. The settings for a user correspond to the settings for the Default User explained previously. The settings for a computer correspond to the settings for the Default Computer explained previously. Settings for a group correspond to user settings (such as the Default User).
After you apply settings as desired, save the System Policy in an appropriate location (choose File, Save As). If you're creating a System Policy to apply across a domain, create a Netlogon folder in the root of the replication export server, and then save the System Policy as NTConfig.pol in the Netlogon folder. If you're using manual update mode (described in the next section), save the System Policy into whichever folder you will be specifying for the manual update.
When a user logs on, the System Policy is taken from that user's logon domain instead of the domain in which the computer resides. This can cause potential problems. For example, user sandra has her account in domain A. Occasionally, she logs on from domain B, which has a trust relationship with domain A. Even though she is logging on from domain B, her System Policy comes from domain A.
Further, domain B doesn't use system policies. When sandra logs on, the System Policy from domain A overwrites the computer profile settings on the local computer. sandra then logs off, and user cassie, whose account resides in domain B, logs on. The computer profile settings are not updated; the settings from the domain A System Policy still remain in effect. This could result in potential problems or inconsistent logon for cassie and other domain B users who log on to the same computer.
To overcome this problem, you can implement system policies on all domains. When a user logs on, the System Policy from his own domain overrides the policy in place from the last user. If you don't want to use system policies on all domains, instead you can use manual update mode for the System Policy. Using manual update mode ensures that the System Policy is read from a specific server, regardless of who logs on or where her account and default System Policy resides. In doing this, basically you are assigning a specific System Policy to the computer.
To use manual update mode, follow these steps:
2. Choose File, Open Registry to open the Registry on the local computer.
The Local Computer and Local User icons appear in the document area to indicate you're
editing the local Registry.
3. Double-click the Local Computer icon to open its property sheet.
4. Expand the Network branch and the System policies update sub-branch to display the Remote Update setting (see Figure 27.4).
Use the scroll bar to view all of the settings for remote update.
6. In the Settings area of the page, set the update mode to Manual.
7. In the Path text box, type the path in which the System Policy file
will be stored.
8. Choose OK, and close the System Policy Editor, choosing Yes to store changes to the Registry.
NOTE: The settings for Remote Update include two check boxes. The Display Error Messages check box, when enabled, causes error messages to be displayed when the System Policy can't be applied. The Load Balancing check box, when enabled, allows computers running Windows NT to read the System Policy from more than one logon server, which can avoid a bottleneck on large networks in which many users access the same System Policy file. Load Balancing enables an overloaded logon server to pass logon requests on to another logon server. This enables faster network logon.
The Account Policy determines how passwords are handled for all user accounts and controls global logon parameters. Account Policy coupled with the System Policy provides complete control over login behavior.
The Account Policy enables the administrator to implement a policy for all the user accounts in the server's accounts database. As an administrator, you can use the Account Policy to enforce password restrictions and lockout accounts and to force time limit account logoffs.
To administer the Account Policy, launch User Manager for Domains, and choose Policies, Account. (You must be logged on as an Administrator user to access the Policies menu.) Figure 27.5 shows the Account Policy screen, which has the following settings:
This figure shows the Account Policy screen that results from the previous steps.
NOTE:
The administrator account that was created during the installation of Windows NT Server is immune to account lockout. This ensures that at least one user account is able to unlock other accounts.
By default, user rights are defined by Windows NT developers for the built-in groups. User rights apply to the whole computer or domain and are different from permissions that represent usage policies for a resource such as a directory or file. Normally, you don't need to change the user policy for these built-in groups unless you have a particular security plan you are trying to implement.
NOTE: To change the User Rights Policy for several users, it is better to assign a group to the User Right and then add users to the group. This would obviously save you time rather than changing the setting for each individual user.
Table 27.1 lists all the User Rights.
| Right | Policy Description | Domains | Servers/Workstations |
| Manage auditing and security log of file and object security | Specifies type of access security | Administrators | Administrators |
| Backup of files and directories | Enables users without access to an NTFS volume to perform backup and restore functions | Administrators Server and Backup | Administrators Backup Operators Operators |
| Log on locally using keyboard and mouse | Enables users to log on interactively | Administrators Server, Backup, Print and Account Operators | Administrators Backup Operators |
| Change system time. | Enables the changing of the Windows system time | Backup Operators Administrators | Server and Backup Operators Administrator |
| Access this computer from the network. | Log on or connect the computer through the network | Administrators Everyone | Administrators Everyone Power Users |
| Shutdown the the system | Capability to shut down the computer | Administrators Backup Operators | Administrators Power Users Users and Guests Server Operators Backup Operators Account Operators Print Operators |
| Add workstations to a domain | Enables a user who is not part of the Administrators group to add new computer to the domain | none | n/a |
| Take ownership of files and other objects | Enables a user to take ownership of files and directories | Administrators | Administrators |
| Force shutdown from a remote system | Gives users right to shut down a remote system | Administrators Server Operators | Administrators Power Users |
| Load and change device drivers | Enables users to unload device drivers | Administrators | Administrators |
Table 27.2 contains the Advanced User Rights that can be modified in Windows NT. Windows NT differentiates between User Rights and Advanced User Rights.
| Right | Description of the Policy | Domains | Servers/Workstations |
| Act as part of the operating system | The user can perform operations as a secure trustedpart of the NT operating system. | none | none |
| Bypass traverse checking | The user can traverse directory trees. | Everyone | Everyone |
| Create a pagefile | The user can create a pagefile. | Administrator | Administrators |
| Create a token object | Used to create the user token on login. Only the LSA Local Security Authority can perform this function. | none | none |
| Create permanent shared object | Used to create special permanent resources representing devices such as \\Device. This is used internally in Windows NT. | none | none |
| Debug programs | Enables users to debug low-level objects | Administrators | Administrators |
| Generate security audits | Used for generating security audit log. | none | none |
| Increase quotas | Used for increasing object quotas | Administrators | Administrators |
| Increase | Used to increase the scheduling priority of a process. | Administrators | Administrators |
| Load and unload device drivers | Enables users to load and unload device drivers. | Administrator | Administrators Power Users |
| Lock pages in memory | Enables user to lock pages in memory so they cannot be paged out of the PAGEFILE.SYS. | none | none |
| Log on as a batch job | The user can log on using a batch queue facility. | none | none |
| Log on as a service | Enables the user to log on as a service that runs in the background. | none | none |
| Modify firmware environment variables | Enables user to modify system environment variables. | Administrators | Administrators |
| Profile single process | Enables user to use profiling capabilities on a process for measuring system performance. | Administrators Power Users | Administrators |
| Profile system performance | Enables users to use profiling capabilities to measure system performance. | Administrators | Administrators |
| Replace a process level token | Used to modify a process's security access token. | none | none |
To modify User Rights Policy, you must first log on to the Windows NT domain as a Administrator. Then follow these steps:
2. Choose Policies, User Rights. Figure 27.6 shows the User Rights Policy screen.
Edit the User Rights Policy in this screen.
The Audit Policy enables you to track the activities of users by auditing security events and create security log entries. You can also use the Audit Policy to determine the types of security events that will be logged in the security log.
When administering domains, remember that the Audit Policy affects the security logs of the domain controller and of all servers in that domain. All the domains share the same Audit Policy. When you're administering a computer running Windows NT Workstation or a Windows NT Server that is not a domain controller, however, this policy affects only the security log of that computer.
Because the security log is limited in size, carefully click events to be logged. The maximum size of each computer's security log is defined in Event Viewer. The entries in a security log can be reviewed by using Event Viewer.
To modify the Audit Policy, follow these steps:
2. Choose Policies, Account. Figure 27.7 shows the screen that you use to modify a domain's Audit Policy.
A trust relationship is used to enable one domain to trust the security settings of another domain. You can also set up a two-way trust relationship in which both domains trust each other. As soon as a trust relationship is set up, all the users of one domain have the same level of access in the new domain.
Edit the Audit Policy from this screen.
Use the Trust Relationships dialog box to add domain names to and remove domain names from the list of trusted domains and trusting domains.
To reach the Trust Relationships dialog box, launch User Manager for Domains, and choose Policies, Trust Relationships. The dialog box shown in Figure 27.8 appears.
From this dialog box, you can edit the trust relationship.
To establish a trust relationship, you have to perform two separate steps in two different domains:
2. For the trusting domain, add the first domain to the list of trusted domains.
Establishing a two-way trust relationship requires that both steps be performed twice (once in each of the domains).
You might find it necessary to remove trust relationships between domains when security issues call for it. Here are the steps:
2. The trusting domain must remove the first domain from its list of trusted domains.
© Copyright, Macmillan Computer Publishing. All rights reserved.