|1| Chapter 13, Administering a Security Configuration

|2| Chapter 13, Lesson 1

Security Configuration Overview

1. Overview

A. A security configuration consists of security settings applied to each security area supported by Microsoft Windows 2000.

|3| B. The following security areas may be configured for a nonlocal GPO:

1. Account policies

2. Local policies

3. Event log

4. Restricted groups

5. System services

6. Registry

7. File system

8. Public key policies

9. IP security policies

2. Account Policies

|4| A. Overview

1. The account policies security area applies to user accounts.

2. Windows 2000 allows only one domain account policy, which is the account policy applied to the root domain of the domain tree.

3. The domain account policy becomes the default account policy of any Windows 2000 workstation or server that is a member of the domain.

a. Exception: When another account policy is defined for an OU, the OU’s account policy settings will affect the local policy on any computers contained in the OU, as is the case with a Domain Controllers OU

|5| B. Attributes

1. Password Policy: For domain or local user accounts, determines settings for passwords, such as enforcement and lifetimes

2. Account Lockout Policy: For domain or local user accounts, determines when and for whom an account will be locked out of the system

3. Kerberos Policy: For domain user accounts, determines Kerberos-related settings, such as ticket lifetimes and enforcement

Note Account policies should not be configured for OUs that do not contain any computers, because OUs that contain only users will always receive account policy from the domain.

3. Local Policies

|6| A. Overview

1. The local policies security area pertains to the security settings on the computer used by an application or user.

2. Local policies are based on the computer to which a user logs on and the rights the user has on that particular computer.

3. Local policies are local to a computer, by definition.

4. When imported to a GPO in Active Directory, local policies affect the local security settings of any computer accounts to which that GPO is applied.

|7| B. Audit Policy

1. Determines which security events are logged into the security log on the computer

2. Part of the Event Viewer console

3. Logs successful attempts, failed attempts, or both

C. User Rights Assignment

1. Determines which users or groups have logon or task privileges on the computer

D. Security Options

1. Enables or disables security settings for the computer

2. Security settings include such things as digital signing of data, Administrator and Guest account names, floppy drive and CD-ROM access, driver installation, and logon prompts.

|8| 4. Event Log

A. The event log security area defines attributes related to the Application, Security, and System event logs:

1. Maximum log size

2. Access rights for each log

3. Retention settings and methods

B. The event log size and log wrapping should be defined to match the business and security requirements.

|9| C. Event log settings should be implemented at the site, domain, or OU level to take advantage of group policy settings.

5. Restricted Groups

|10| A. Overview

1. The restricted groups security area provides an important new security feature that acts as a governor for group membership.

a. Automatically provides security memberships for default Windows 2000 groups that have predefined capabilities

b. Any groups considered sensitive or privileged to the Restricted Groups security list can be added later.

|11| B. Configuring

1. Configuring the restricted groups security area ensures that group memberships are set as specified.

2. Groups and users not specified in restricted groups are removed from the specific group.

3. The reverse membership configuration option ensures that each restricted group is a member of only those groups specified in the Member Of column.

4. Restricted groups should be used primarily to configure membership of local groups on workstation or member servers.

6. System Services

|12| A. Overview

1. The system services security area is used to configure security and startup settings for services running on a computer.

2. Security properties for the service determine what user or group accounts have the following:

a. Read/Write/Delete/Execute permissions

b. Inheritance settings

c. Auditing

d. Ownership permission

3. If choosing an Automatic startup, adequate testing must be performed to verify that the services can start without user intervention.

4. System services used on a computer should be tracked.

5. Unnecessary or unused services should be set to Manual.

B. Startup settings

1. Automatic: Starts a service automatically at system start time.

2. Manual: Starts a service only if manually started.

3. Disabled: A service is disabled so it cannot be started.

|13| 7. Registry and File System Areas

A. The registry security area is used to configure security on registry keys.

B. The file system security area is used to configure security on specific file paths.

C. The Security properties of the registry key or file path can be edited to determine what user or group accounts have Read/Write/Delete/Execute permissions, as well as inheritance settings, auditing, and ownership permission.

|14| 8. Policies

A. Public key policies: Used to configure encrypted data recovery agents, domain roots, and trusted certificate authorities

B. IP security policies: Used to configure network IP security

|15| Chapter 13, Lesson 2

Auditing

|16| 1. Understanding Auditing

A. Auditing is the process of tracking both user activities and Windows 2000 activities, called events.

B. Auditing is used to specify which events are written to the security log.

C. An audit entry in the security log contains the following information:

1. The action that was performed.

2. The user who performed the action.

3. The success or failure of the event and when the event occurred.

|17| 2. Using an Audit Policy

A. Overview

1. An audit policy defines the categories of events that Windows 2000 records in the security log on each computer.

2. The security log allows specified events to be tracked.

3. Windows 2000 writes an event to the security log on the computer where the event occurs.

B. Actions performed by an audit policy

1. Track the success and failure of events

2. Eliminate or minimize the risk of unauthorized use of resources

C. Event Viewer

1. Used to view events that Windows 2000 has recorded in the security log

2. Used to archive log files, to track trends over time

3. Audit Policy Guidelines

|18| A. General guidelines

1. Determine the computers on which to set up auditing.

a. Auditing is turned off by default.

2. Plan the events to audit on each computer.

3. Determine whether to audit the success of events, failure of events, or both.

a. Tracking successful events identifies which users gained access to specific files, printers, or objects, which is information that can be used for resource planning.

b. Tracking failed events may alert the administrator of possible security breaches.

|19| B. Other guidelines

1. Determine whether trends of system usage need to be tracked.

a. If so, plan to archive event logs.

b. Shows how usage changes over time and when to increase system resources before they become a problem

2. Review security logs frequently.

a. Set a schedule to regularly review security logs

b. Configuring auditing alone does not alert the administrator of security breeches.

3. Define an audit policy that is useful and manageable.

a. Always audit sensitive and confidential data.

b. Only audit events that provide meaningful information about the network environment.

(1) Minimizes the usage of server resources and makes essential information easier to locate

(2) Auditing too many types of events can create excess overhead for Windows 2000.

4. Audit resource access by the Everyone group instead of the Users group.

a. Ensures the auditing of anyone who can connect to the network, not just users for whom user accounts have been created in the domain

5. Audit resource access failures by the Everyone group.

6. Audit all administrative tasks by the administrative groups.

a. Ensures the auditing of any additions or changes made by all administrators

4. Configuring Auditing

|20| A. Overview

1. An audit policy is implemented based on the role of the computer in the Windows 2000 network.

2. The event categories on a domain controller are identical to those on a computer that is not a domain controller.

|21| B. Auditing is configured differently depending on the computer’s role.

1. For member or stand-alone servers and computers running Windows 2000 Professional

a. An audit policy is set for each individual computer

b. Events are audited by configuring a local group policy for that computer

2. Domain controllers

a. An audit policy is set for all domain controllers in the domain.

b. Events are audited by configuring the audit policy in a nonlocal GPO for the domain, which applies to all domain controllers and is accessible through the Domain Controllers OU.

|22| C. Auditing requirements

1. The Manage Auditing And Security Log user right for the computer is necessary to configure an audit policy or review an audit log.

2. Files and folders to be audited must be on Microsoft Windows NTFS volumes.

|23| D. Setting up auditing

1. Set the audit policy: Enables the auditing of objects but does not activate the auditing of specific types

2. Enable the auditing of specific resources: The specific events to track for files, folders, printers, and Active Directory objects must be identified; Windows 2000 then tracks and logs the specified events

5. Setting Up an Audit Policy

|24| A. Overview

1. Categories of events that Windows 2000 audits are selected.

2. Configuration settings indicate whether to track successful or failed attempts for each event category to be audited.

3. Audit policies are set in the Group Policy snap-in.

4. The security log is limited in size.

5. The events to be audited must be selected carefully.

6. The amount of disk space to devote to the security log must be considered.

|25| B. Types of events

1. Account logon: A domain controller received a request to validate a user account

2. Account management: An administrator created, changed, or deleted a user account or group

3. Directory service access: A user gained access to an Active Directory object

4. Logon events: A user logged on or off, or a user made or canceled a network connection to the computer

5. Object access: A user gained access to a file, folder, or printer

6. Policy change: A change was made to the user security options, user rights, or audit policies

7. Privilege use: A user exercised a right, such as changing the system time

8. Process tracking: A program performed an action

9. System events: A user restarted or shut down the computer, or an event occurred that affects Windows 2000 security or the security log

C. To set an audit policy for a domain controller

1. Open Active Directory Users and Computers

2. In the console tree, right-click Domain Controllers and then click Properties

3. In the Group Policy tab, click the policy in which to set the audit policy and then click Edit

4. In the Group Policy snap-in, in the console tree, click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then double-click Audit Policy

5. In the details pane, right-click the event category to audit and then click Security

6. In the Security Policy Setting dialog box, click Define These Policy Settings and then click one or both of the following:

a. Success: Audits successful attempts for the event category.

b. Failure: Audits failed attempts for the event category.

7. Click OK

8. Because the changes made to the computer’s audit policy take effect only when the policy is propagated to the computer, do one of the following to initiate policy propagation:

a. Type secedit /refreshpolicy machine_policy at the command prompt and then press Enter.

b. Restart the computer.

c. Wait for automatic policy propagation, which occurs at regular, configurable intervals (eight hours, by default).

D. To set an audit policy on a computer that does not participate in a domain

1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy

2. In Local Security Settings, in the console tree, double-click Local Policies and then double-click Audit Policy

3. In the details pane, right-click the event category to audit and then click Security

4. In the Local Security Policy Setting dialog box, click one or both of the following:

a. Success: Audits successful attempts for the event category

b. Failure: Audits failed attempts for the event category

Note The Effective Policy Setting box shows the security setting value currently enforced on the system. If an audit policy has already been set at the domain or OU level, it overrides the local audit policy.

5. Click OK

6. Because the changes made to the computer’s audit policy take effect only when the policy is propagated to the computer, do one of the following to initiate policy propagation:

a. Type secedit /refreshpolicy machine_policy at the command prompt and then press Enter.

b. Restart the computer.

c. Wait for automatic policy propagation, which occurs at regular, configurable intervals (eight hours, by default).

E. To set an audit policy on a member server or workstation

1. Create an OU for the remote computer and add the desired machine account to the OU

2. Using Active Directory Users and Computers, create an audit policy to enable security auditing using the same procedure for setting an audit policy for a domain controller

Note Security auditing for workstations, member servers, and domain controllers can be enabled remotely only by domain and enterprise administrators.

6. Auditing Access to Files and Folders

|26| A. Overview

1. If security breaches are an issue for a organization, auditing should be set up for files and folders on NTFS partitions.

2. To audit user access to files and folders, the Audit Object Access event category is set in the audit policy.

3. After Audit Object Access is set in the audit policy, auditing for specific files and folders is enabled, specifying which types of access to audit, either by users or by groups

B. To set up auditing for specific files and folders

1. In Windows Explorer, right-click the file or folder to audit and then click Properties

2. In the Security tab in the Properties dialog box for a file or folder, click Advanced

3. In the Access Control Settings For dialog box for the file or folder, in the Auditing tab, click Add, select the users and groups for whom to audit file and folder access, and then click OK

|27| 4. In the Auditing Entry For dialog box for the file or folder, select the Successful check box, the Failed check box, or both check boxes for the events that are to be audited

Note See “User events and what triggers them” following step 8.

5. In the Apply Onto list (available only for folders), specify where objects are audited. By default, this box is set to This Folder, Subfolders And Files, so any auditing changes made to the parent folder also apply to all child folders and all files in the parent and child folders

Note Where objects are audited depends on the selection in the Apply Onto list and whether the Apply These Auditing Entries To Objects And/Or Containers Within This Container Only check box is cleared. Table 13.3 on page 474 of the textbook provides the results of clearing this check box.

6. Click OK to return to the Access Control Settings For dialog box for the file or folder

7. To prevent changes made to a parent folder from applying to the currently selected file or folder, clear the Allow Inheritable Auditing Entries From Parent To Propagate To This Object check box

Note If the check boxes under Access are shaded in the Auditing Entry For dialog box for the file or folder, or if the Remove button is unavailable in the Access Control Settings For dialog box for the file or folder, then auditing has been inherited from the parent folder.

8. Click OK

|28| C. User events and what triggers them

1. Traverse Folder/Execute File: Moving through folders to reach other files or folders, even if the user has no permissions for traversed folders or running program files

2. List Folder/Read Data: Viewing file names and subfolder names within a folder or viewing data in files

3. Read Attributes and Read Extended Attributes: Displaying the attributes of a file or folder

4. Create Files/Write Data: Creating files within a folder or changing the contents of a file

5. Create Folders/Append Data: Creating folders within a folder or making changes to the end of the file but not changing, deleting, or overwriting the existing data

6. Write Attributes and Write Extended Attributes: Changing attributes of a file or folder

7. Delete Subfolders And Files: Deleting a file or subfolder in a folder

8. Delete: Deleting a file or folder

9. Read Permissions: Viewing permissions of the file owner for a file or folder

10. Change Permissions: Changing permissions for a file or folder

11. Take Ownership: Taking ownership of a file or folder

7. Auditing Access to Active Directory Objects

|29| A. Overview

1. Similar to auditing file and folder access

2. An audit policy must be configured and then auditing for specific objects must be set by specifying which types of access, and by whom, to audit.

3. Active Directory objects are audited to track access to them.

4. The Audit Directory Service Access event category is set in the audit policy to enable the auditing of user access to AD objects.

B. To set up auditing for specific Active Directory objects

1. In Active Directory Users and Computers, click View and then click Advanced Features

2. Select the object to audit, click Properties on the Action menu, click the Security tab, and then click the Advanced button

3. In the Access Control Settings For dialog box for the object, in the Auditing tab, click Add, select the users or groups for whom to audit file and folder access, and then click OK

|30| 4. In the Auditing Entry For dialog box for the object, select the Successful check box, the Failed check box, or both check boxes for the events to audit

5. In the Apply Onto list, specify where objects are audited; by default, this box is set to This Object And All Child Objects, so any auditing changes made to a parent object also apply to all child objects

6. Click OK to return to the Access Control Settings For dialog box for the object

7. To prevent changes that are made to a parent folder from applying to the currently selected file or folder, clear the Allow Inheritable Auditing Entries From Parent To Propagate To This Object check box

8. Click OK

|31| C. Some Active Directory object events and what triggers them

1. Full Control: Performing any type of access to the audited object

2. List Contents: Viewing the objects within the audited object

3. Read All Properties: Viewing any attribute of the audited object

4. Write All Properties: Changing any attribute of the audited object

5. Create All Child Objects: Creating any object within the audited object

6. Delete All Child Objects: Deleting any object within the audited object

7. Read Permissions: Viewing the permissions for the audited object

8. Modify Permissions: Changing the permission for the audited object

9. Modify Owner: Taking ownership of the audited object

8. Auditing Access to Printers

|32| A. Overview

1. Use auditing to track access to sensitive printers.

2. Set the Audit Object Access event category in the audit policy, which includes printers.

3. Enable the auditing for specific printers and specify the types of access, and by whom, to audit.

4. Use the same procedure used to set up auditing on files and folders.

B. To set up auditing on a printer

1. Click Start, point to Settings, and then click Printers

2. In the Printers system folder, right-click the printer to audit and then click Properties

3. In the Properties dialog box for the printer, click the Security tab and then click Advanced

4. In the Access Control Settings For dialog box for the printer, in the Auditing tab, click Add, select the appropriate users or groups for whom to audit printer access, click Add, and then click OK

|33| 5. In the Auditing Entry For dialog box for the printer, select the Successful check box, the Failed check box, or both check boxes for the events needed

Note See “Printer events and what triggers them” following step 7.

6. In the Apply Onto list, select where the auditing setting applies

7. Click OK in the appropriate dialog boxes to exit

C. Printer events and what triggers them

1. Print: Printing a file

2. Manage Printers: Changing printer settings, pausing a printer, sharing a printer, or removing a printer

3. Manage Documents: Changing job settings; pausing, restarting, moving, or deleting documents; sharing a printer; or changing printer properties

4. Read Permissions: Viewing printer permissions

5. Change Permissions: Changing printer permissions

6. Take Ownership: Taking printer ownership

|34| 9. Auditing Practices

A. Auditing failure for logon/logoff monitors the potential threat of a random password hack.

B. Auditing success for logon/logoff monitors the potential threat of a stolen-password break-in.

C. Auditing success for user rights, user and group management, security change policies, restart, shutdown, and system events monitors the potential threat of misuse of privileges.

D. Auditing success and failure for file access and object access events monitors the potential threat of improper access to sensitive files.

E. Auditing File Manager success and failure of Read/Write by suspect users or groups for the sensitive files monitors the potential threat of improper access to sensitive files.

F. Auditing success and failure for file-access printers and object-access events monitors the potential threat of improper access to printers.

G. Auditing Print Manager success and failure for print access by suspect users or groups for the printers monitors the potential threat of improper access to printers.

H. Auditing success and failure for write access for program files monitors the potential threat of a virus outbreak.

I. Auditing success and failure for process tracking monitors the potential threat of a virus outbreak.

|35| Chapter 13, Lesson 3

Using Security Logs

|36| 1. Overview

A. The security log contains information on security events specified in the audit policy.

B. To view the security log, the Event Viewer console is used.

C. Event Viewer also allows specific events within the log files to be found, the events shown in log files to be filtered, and security log files to be archived.

2. Understanding Windows 2000 Logs

|37| A. Overview

1. Three logs are available to view in Event Viewer by default.

2. All users can view application and system logs.

3. Security logs are accessible only to system administrators.

4. Security logging is turned off by default.

5. Group policy must be used at the appropriate level to set up an audit policy.

Note If additional services are installed, they might add their own event log. For example, DNS Service logs events that this service generates in the DNS server log.

|38| B. Logs maintained by Windows 2000

1. Application log

a. Contains errors, warnings, or information that programs, such as a database program or an e-mail program, generate

b. The program developer presets which events to record.

2. Security log

a. Contains information about the success or failure of audited events

b. The events Windows 2000 records are a result of the audit policy.

3. System log

a. Contains errors, warnings, and information that Windows 2000 generates

b. Windows 2000 presets which events to record.

3. Viewing Security Logs

|39| A. Overview

1. The security log contains information about events monitored by an audit policy, such as failed and successful logon attempts.

2. Windows 2000 records events in the security log on the computer at which the event occurred.

3. Events can be viewed from any computer with assigned administrative privileges for the computer where the events occurred.

B. To view the Security Log

1. Click Start, point to Programs, point to Administrative Tools, and then click Event Viewer

2. In the console tree, select Security Log

|40| 3. In the details pane, Event Viewer displays a list of log entries and summary information for each item

a. Successful events appear with a key icon and unsuccessful events appear with a lock icon.

b. The category indicates the event category, such as object access, account management, directory service access, or logon events.

4. To view additional information for any event, double-click the event

C. To view the Security Log on a remote computer

1. Ensure that security auditing has been enabled on a remote machine

2. Click Start, point to Programs, point to Administrative Tools, and then click Event Viewer

3. Right-click the Event Viewer node and select Connect To Another Computer

4. In the Select Computer dialog box, click Another Computer and type the network name, IP address, or DNS address for the computer for which Event Viewer will display a security log; also browse for a computer name

5. Click OK

4. Locating Events

|41| A. Overview

1. Event Viewer automatically displays all events recorded in the security log when it’s first started.

2. The Find command is used to search for specific events.

B. To find events

1. Start Event Viewer, click the security log, and then click Find on the View menu

|42| 2. On the Find In dialog box for the security log, configure the options.

|43| C. Options on the Find In dialog box

1. Event Types: Check boxes that indicate the types of events to find; the security log contains only audit events because others are not recorded.

2. Event Source: A list that indicates the software or component driver that logged the event

3. Category: A list that indicates the event category, such as a logon or logoff attempt or a system event

4. Event ID: An event number to identify the event; helps product-support representatives track events

5. User: A user logon name

6. Computer: A computer name

7. Description: Text that is in the description of the event

8. Search Direction: The direction in which to search the log

9. Find Next: Finds and selects the next occurrence defined by the Find settings.

5. Filtering Events

|44| A. Overview

1. The Filter command displays specific events that appear in the security log.

2. The Filter command is used to narrow down the displayed events.

B. To filter events

1. Start Event Viewer, click the security log, and then click Filter on the View menu

2. In the Security Log Properties dialog box, in the Filter tab, configure the options

|45| C. Options on the Filter tab of the Security Log Properties dialog box

1. Event Types: Check boxes that indicate the types of events to filter; filter using audit events

2. Event Source: A list that indicates the software or component driver that logged the event

3. Category: A list that indicates the type of event, such as a logon or logoff attempt or a system event

4. Event ID: An event number to identify the event; helps track events

5. User: A user logon name

6. Computer: A computer name

7. From: Beginning of the range of events to be filtered

8. To: End of the range of events to be filtered

6. Configuring Security Logs

|46| A. Overview

1. Security logging begins when an audit policy is set for the domain controller or local computer.

2. Security logging stops when the security log becomes full and cannot overwrite itself; an error may be written to the application log.

3. A full security log is avoided by logging only key events.

4. The properties of each individual audit log can be configured.

B. To configure the settings for security logs

1. Open Event Viewer

2. Right-click the security log in the console tree and then click Properties

3. In the Security Log Properties dialog box, in the General tab, configure the options

C. Options on the General tab of the Security Log Properties dialog box

1. Display Name: Name of the log view

2. Log Name: Name and location of the log file

3. Maximum Log Size: The size of each log, which ranges from 64 KB to 4 GB; default size is 512 KB

4. Overwrite Events As Needed: Specifies whether all new events will be written to the log, even when the log is full

5. Overwrite Events Older Than X Days: Specifies the number of days (1–365) that a log file will be retained before writing over it; new events will not be added if the maximum log size is reached and there are no events older than this period

6. Do Not Overwrite Events: Specifies whether existing events will be retained when the log is full; new events are discarded if the maximum log size is reached (requires manually clearing the log)

7. Using A Low Speed Connection: Specifies whether the log file is located on another computer and whether a low-speed device, such as a modem, connects the computer to it

D. Security log

|47| 1. Overview

a. When the security log is full and no more events can be logged, the log can be freed by manually clearing it.

b. Clearing the log erases all events permanently.

c. Reducing the amount of time that an event log is kept frees the log if it allows the next record to be overwritten.

2. To manually clear the security log

a. Open Event Viewer

b. Right-click the security log in the console tree and then click Clear All Events

c. On the Event Viewer message box:

(1) Click Yes to archive the log before clearing.

(2) Click No to permanently discard the current event records and start recording new events.

d. If Yes was clicked, in the Save As dialog box, in the File Name list, enter a name for the log file to be archived

e. In the Save As Type list, click a file format and then click Save

7. Archiving Security Logs

|48| A. Overview

1. Archiving maintains a history of security-related events.

2. Archived logs are often kept for a specified period to track security-related information over time.

3. The entire log is saved, regardless of filtering options.

4. Event Viewer is used to reopen a log archived in a log-file format.

|49| 5. Logs saved as event log files (.evt) retain the binary data for each event recorded.

6. Logs archived in text or comma-delimited format (.txt and .csv, respectively) can be reopened in other programs, such as word processing or spreadsheet programs.

7. Logs saved in text or comma-delimited format do not retain the binary data.

8. An archived log file is removed from the system by deleting the file in Windows Explorer.

B. To archive a security log

1. Open Event Viewer

2. Right-click the security log in the console tree and then click Save Log File As

3. In the Save As dialog box, in the File Name list, enter a name for the log file to be archived

4. In the Save As Type list, click a file format and then click Save

C. To view an archived security log

1. Open Event Viewer

2. Right-click the security log in the console tree and then click Open Log File

3. In the Open dialog box, click the file to open; a search may need to be made for the drive or folder that contains the document

4. In the Log Type list, select Security for the type of log to be opened

5. In the Display Name box, enter the name of the file as it is to appear in the console tree and then click Open

|50| Chapter 13, Lesson 4

User Rights

1. Overview

|51| A. User rights

1. Specific rights can be assigned to group accounts or to individual user accounts.

2. Authorize users to perform specific actions

3. Differ from permissions, because user rights apply to user accounts, whereas permissions are attached to objects

4. Because user rights are part of a GPO they can be overridden, depending on the GPO affecting the user.

|52| B. Administration

1. User rights define the capabilities of a user at a local level.

2. User rights can be applied to individual user accounts, but are best administered on a group account basis.

a. Ensures that a user logging on as a member of a group automatically inherits the rights associated with that group

b. Simplifies user account administration by associating user rights to groups rather than to individual users

|53| C. Assignment

1. User rights assigned to a group are applied to all members of the group while they remain members.

2. User rights are cumulative when a user is a member of multiple groups.

3. A user can have more than one set of rights.

4. Possible conflicts of user rights may occur in the case of certain logon rights.

5. Generally, user rights assigned to one group do not conflict with the rights assigned to another group.

6. To remove rights from a user, the user is removed from the group.

7. The two types of user rights are privileges and logon rights.

2. Privileges

|54| A. Overview

1. Privileges specify allowable user actions on the network.

2. Some privileges can override permissions set on an object.

2. A user right takes precedence over all file and directory permissions.

B. Act As Part Of The OS privilege

1. Allows a process to authenticate as any user and therefore gain access to the same resources as any user

2. Required only by low-level authentication services

3. Potential access is not limited to what is associated with the user by default.

a. The calling process may request that arbitrary additional accesses be put in the access token.

b. The calling process can build an anonymous token that can provide any and all accesses, which is reason for concern.

c. The anonymous token does not provide a primary identity for tracking events in the audit log.

4. Processes requiring this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned.

C. Add Workstations To Domain privilege

1. Allows the user to add a computer to a specific domain

2. The user specifies the domain through an administrative user interface on the computer being added, creating an object in the Computer container of Active Directory.

3. Behavior is duplicated in Windows 2000 by another access control mechanism.

D. Back Up Files And Directories privilege

1. Allows the user to circumvent file and directory permissions to back up the system

2. Similar to granting the following permissions on all files and folders on the local computer:

a. Traverse Folder/Execute File

b. List Folder/Read Data

c. Read Attributes

d. Read Extended Attributes

e. Read Permissions

3. See also the Restore Files And Directories privilege.

E. Bypass Traverse Checking privilege

1. Allows the user to pass through directories to which the user otherwise has no access while navigating an object path in any Windows file system or in the registry

2. Does not allow the user to list the contents of a directory, only to traverse directories

F. Change The System Time privilege

1. Allows the user to set the time for the internal clock of the computer

G. Create A Pagefile privilege

1. Allows the user to create and change the size of a pagefile

2. Allows the user to specify a paging file size for a given drive in the System Properties Performance Options

H. Create A Token Object privilege

1. Allows a process to create a token that it can then use to get access to any local resources when the process uses NtCreateToken() or other token-creation APIs

2. Recommended that processes requiring this privilege use the LocalSystem account rather than a separate user account with this privilege specially assigned

3. LocalSystem already includes this privilege.

I. Create Permanent Shared Objects privilege

1. Allows a process to create a directory object in the Windows 2000 object manager

2. Useful to kernel-mode components that plan to extend the Windows 2000 object namespace

3. Already assigned to components running in kernel mode; thus, not necessary to specifically assign this privilege

J. Debug Programs privilege

1. Allows the user to attach a debugger to any process, which provides powerful access to sensitive and critical operating system components

K. Enable Computer And User Accounts To Be Trusted For Delegation privilege

1. Allows the user to set the Trusted For Delegation setting on a user or computer object

2. The user or object granted this privilege must have write access to the account control flags on the user or computer object.

3. A server process either running on a computer trusted for delegation or run by a user who is trusted for delegation can access resources on another computer.

4. Uses a client’s delegated credentials, as long as the client account does not have the Account Cannot Be Delegated account control flag set

5. Misuse of this privilege or the Trusted For Delegation settings could make the network vulnerable to sophisticated attacks using Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources.

L. Force Shutdown From A Remote System privilege

1. Allows a user to shut down a computer from a remote location on the network

2. See also the Shut Down The System privilege.

M. Generate Security Audits privilege

1. Allows a process to make entries in the security log for object access auditing

2. The process can also generate other security audits.

3. The security log is used to trace unauthorized system access.

4. See also the Manage Auditing And Security Log privilege.

N. Increase Quotas privilege

1. Allows a process with write property access to another process to increase the processor quota assigned to that other process

2. Useful for system tuning

3. Can be abused, as in a denial-of-service attack

O. Increase Scheduling Priority privilege

1. Allows a process with write property access to another process to increase the execution priority of that other process

2. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.

P. Load and Unload Device Drivers privilege

1. Allows a user to install and uninstall Plug and Play device drivers; device drivers that are not Plug and Play are not affected by this privilege and can be installed only by administrators.

2. Because device drivers run as trusted programs, this privilege could be misused to install hostile programs and give these programs destructive access to resources.

Q. Lock Pages In Memory privilege

1. Allows a process to keep data in physical memory, preventing the system from paging the data to virtual memory on disk

2. Exercising this privilege could significantly affect system performance.

3. Is obsolete and therefore never checked

R. Manage Auditing And Security Log privilege

1. Allows a user to specify object access auditing options for individual resources, such as files, Active Directory objects, and registry keys

2. Object access auditing is not actually performed unless it has been enabled in the computer-wide audit policy settings under group policy or under group policy defined in Active Directory.

3. Does not grant access to the computer-wide audit policy

4. A user with this privilege can also view and clear the security log from the Event Viewer.

S. Modify Firmware Environment Values privilege

1. Allows modification of the system environment variables either by a user through the System Properties or by a process

T. Profile Single Process privilege

2. Allows a user to use Windows NT and Windows 2000 performance-monitoring tools to monitor the performance of nonsystem processes

Note By default, this privilege is assigned to Administrators and Power Users.

U. Profile System Performance privilege

2. Allows a user to use Windows NT and Windows 2000 performance-monitoring tools to monitor the performance of system processes

Note By default, this privilege is assigned to Administrators.

V. Remove Computer From Docking Station privilege

1. Allows a user to undock a computer using the Windows 2000 interface

W. Replace A Process Level Token privilege

1. Allows a process to replace the default token associated with a subprocess that has been started

X. Restore Files And Directories privilege

1. Allows a user to circumvent file and directory permissions when restoring backed up files and directories, and to set any valid security principal as the owner of an object

2. See also the Back Up Files And Directories privilege.

Y. Shut Down The System privilege

1. Allows a user to shut down the local computer

Z. Synchronize Directory Service Data privilege

1. Allows a process to provide directory synchronization services

2. Relevant only on domain controllers

3. Assigned to the Administrator and LocalSystem accounts on domain controllers by default

AA. Take Ownership Of Files Or Other Objects privilege

1. Allows a user to take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads

4. Logon Rights

|55| A. Overview

1. Logon rights specify the ways in which a user can log on to a system.

2. The special user account LocalSystem has almost all privileges and logon rights assigned to it because all processes running as part of the OS are associated with this account.

3. OS processes require a complete set of user rights.

|56| B. Access This Computer From The Network logon right

1. Allows a user to connect to the computer over the network

2. Granted to Administrators, Everyone, and Power Users

C. Deny Access To This Computer From the Network logon right

1. Prohibits a user or group from connecting to the computer from the network

2. By default, no one is denied this right.

D. Deny Logon As A Batch Job logon right

1. Prohibits a user or group from logging on through a batch-queue facility

2. By default, no one is denied this right.

E. Deny Logon As A Service logon right

1. Prohibits a user or group from logging on as a service

2. By default, no one is denied this right.

F. Deny Logon Locally logon right

1. Prohibits a user or group from logging on locally

2. By default, no one is denied this right.

G. Log On As A Batch Job logon right

1. Allows a user to log on using a batch-queue facility

2. By default, this privilege is granted to Administrators.

H. Log On As A Service logon right

1. Allows a security principal to log on as a service, as a way of establishing a security context

2. The LocalSystem account always retains the right to log on as a service.

3. Any service that runs under a separate account must be granted this right.

4. By default, this right is not granted to anyone.

I. Log On Locally logon right

1. Allows a user to log on at the computer’s keyboard

2. By default, this right is granted to

a. Administrators

b. Account Operators

c. Backup Operators

d. Print Operators

e. Server Operators

5. Assigning User Rights

|57| A. Overview

1. Assigning user rights eases the task of user account administration by assigning user rights primarily to group accounts rather than to individual user accounts.

3. Assigning rights to a group account automatically assigns those rights to users when they become a member of that group.

Note The rule to keep in mind is “Allow a set, and then deny a subset.” Reversing the order can be disastrous. For example, Susan might want to allow no one but herself to log on locally. If she allows herself the right to log on locally and denies the Users group the right to log on locally, she will be unpleasantly surprised to find that she has locked herself out of the computer. Susan, after all, is a member of the Users group, so the deny right she assigned to the Users group would take precedence over the allow right she assigned to herself.

B. To assign user rights

1. Access the Group Policy snap-in for a GPO

2. In the Group Policy snap-in, click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then double-click User Rights Assignment

3. In the details pane, right-click the user right to be set and then click Security

4. In the Templates Security Policy Setting dialog box, click the Define These Policy Settings check box and then click Add

5. In the Add User Or Group dialog box, add the users and/or groups to be affected by this user right and then click OK

6. Click OK twice when finished adding users and/or groups

7. A list of users and/or groups appears in the Computer Setting column in the details pane

|58| Chapter 13, Lesson 5

Using Security Templates

|59| 1. Overview

A. Windows 2000 provides a centralized method of defining security using security templates.

B. A security template is a physical representation of a security configuration, a single file in which a group of security settings is stored.

C. Locating all security settings in one place streamlines security administration.

D. Each template is saved as a text-based .inf file, which allows some or all of the template attributes to be copied, pasted, imported, or exported.

E. All security attributes can be contained in a security template, except IP Security and Public Key policies.

2. Uses

|60| A. Overview

1. The security settings in the local GPO are the initial settings applied to a computer.

2. The local security settings can be exported to a security template file to preserve initial system security settings, which enables the restoration of the initial security settings at any later point.

|61| B. Importing

1. A security template file can be imported to a local or nonlocal GPO.

2. Any computer or user accounts in the site, domain, or OU to which the GPO is applied will receive the security template settings.

3. Importing a security template to a GPO eases domain administration by configuring security for multiple computers at once.

|62| C. Exporting

1. The local security settings are exported to a security template file to preserve initial system security settings.

2. Both local and effective security settings can be exported to a security template.

3. Initial system settings are preserved.

4. Local security settings are available for restoration later because domain-based GPOs override the local GPO.

5. By exporting the effective security settings to a security template, the settings can be imported into a security database, new templates can be overlaid, and potential conflicts can be analyzed.

3. Predefined Security Templates

|63| A. Overview

1. Windows 2000 includes a set of predefined security templates.

2. Each predefined template is based on the role of a computer and common security scenarios, from security settings for low-security domain clients to highly secure domain controllers.

3. Predefined templates can be used as provided, can be modified, or can serve as a basis for creating custom security templates.

4. By default, predefined security templates are stored in the systemroot\Security\Templates folder.

Note Do not apply predefined security templates to production systems without testing to ensure that the right level of application functionality is maintained for the network and system architecture.

B. Predefined security templates

1. BASICDC.INF: Default domain controller security settings

2. BASICSV.INF: Default server security settings

3. BASICWK.INF: Default workstation security settings

4. COMPATWS.INF: Compatible workstation or server security settings

5. DC SECURITY.INF Default security settings updated for domain controllers

6. HISECDC.INF: Highly secure domain controller security settings

7. HISECWS.INF: Highly secure workstation or server security settings

8. NOTSSID.INF: Removes the Terminal Server User SID from Windows 2000 server

9. OCFILESS.INF: Optional Component File Security for server

10. OCFILESW.INF: Optional Component File Security for workstation

11. SECUREDC.INF: Secure domain controller security settings

12. SECUREWS.INF: Secure workstation or server security settings

13. SETUP SECURITY.INF: Out of the box default security settings

|64| C. Security levels

1. Basic: BASIC*.INF

a. The basic configuration templates are provided as a means to reverse the application of a different security configuration.

b. The basic configurations apply the Windows 2000 default security settings to all security areas except those pertaining to user rights.

(1) Rights are not modified in the basic templates because application setup programs commonly modify user rights to enable successful use for the application.

(2) It is not the intent of the basic configuration files to undo such modifications.

2. Compatible: COMPAT*.INF

a. By default, Windows 2000 security is configured such that members of the local Users group have ideal security settings and members of the local Power Users group have security settings that are compatible with Windows NT 4.0 users.

b. The default configuration enables the development of applications to a standard definition of a secure Windows environment while still allowing existing applications to run successfully under the less secure Power User configuration.

c. All users authenticated by Windows 2000 are members of the Power Users group by default.

(1) May be too unsecure for some environments

(2) Having users, by default, be members of only the Users group might be preferable, which is how the compatible templates are designed.

d. By lowering security levels on specific files, folders, and registry keys that are commonly accessed by applications, the compatible templates allow most applications to run successfully.

e. All members of the Power Users group are removed.

3. Secure: SECURE*.INF

a. The secure templates implement recommended security settings for all security areas except files, folders, and registry keys.

b. Files, folders, and registry keys are not modified, because file system and registry permissions are configured securely by default.

4. Highly Secure: HISEC*.INF

a. The highly secure templates define security settings for Windows 2000 network communications.

b. Security areas are set to require maximum protection for network traffic and protocols used between computers running Windows 2000.

c. Computers configured with a highly secure template can communicate only with other Windows 2000 computers and are unable to communicate with computers running Windows 95, Windows 98, or Windows NT.

4. Managing Security Templates

|65| A. Overview of management tasks

1. Accessing the Security Templates console

2. Customizing a predefined security template

3. Defining a new security template

4. Importing a security template to a local and nonlocal GPO

5. Exporting security settings to a security template

B. To access the Security Templates console

1. Decide whether to add the Security Templates console to an existing console or to create a new console

a. To create a new console, click Start, click Run, type mmc, and then click OK.

b. To add the Security Templates console to an existing console, open the console and then proceed to step 2.

2. On the Console menu, click Add/Remove Snap-In and then click Add

3. In the Add Standalone Snap-In dialog box, select Security Templates, click Add, click Close, and then click OK

4. On the Console menu, click Save

5. Enter the name to assign to this console and click Save

6. The console appears on the Administrative Tools menu.

C. To customize a predefined security template

|66| 1. In the Security Templates console, double-click Security Templates

2. Double-click the default path folder, right click the predefined template to modify, and then click Save As

3. In the Save As dialog box, in the File Name box, specify a file name for the new security template and then click Save

4. In the console tree, right-click the new security template and then select Set Description

5. In the Security Template Description dialog box, enter a description for the new security template and then click OK

6. In the console tree, double-click the new security template to display the security policies and double-click the security policy to modify

7. Click the security policy to customize and then double-click the security setting to modify

8. On the Template Security Policy Setting dialog box, click the Define This Policy Setting In The Template check box to allow configuration and then configure the security setting

9. Click OK

10. Configure other security settings as needed

11. Close the Security Templates console

12. In the Save Security Templates dialog box, click Yes to save the new security template file

D. To define a new security template

1. In the Security Templates console, double-click Security Templates

2. Right-click the template path folder in which to store the new template and click New Template

3. In the dialog box for the templates folder, enter the name and description for the new security template and then click OK

4. In the console tree, right-click the new security template and then select Set Description

5. In the Security Template Description dialog box, enter a description for the new security template and then click OK

6. In the console tree, double-click the new security template to display the security policies and double-click the security policy to define

7. Click the security policy to define and then double-click the security setting to define

8. In the Template Security Policy Setting dialog box, click the Define This Policy Setting In The Template check box to allow configuration and then configure the security setting

9. Click OK

10. Configure other security settings as needed

11. Close the Security Templates console

12. In the Save Security Templates dialog box, click Yes to save the new security template file

E. To import a security template to a GPO

1. In a console from which local or nonlocal group policy settings are managed, click the GPO to which to import the security template

2. In the console tree, right-click Security Settings and then click Import Policy

3. In the Import Policy From dialog box, click the security template to import and then click Open

4. Because the security settings are applied when the group policy is propagated to the computer, do one of the following to initiate policy propagation:

a. Type secedit /refreshpolicy machine_policy at the command prompt and then press Enter.

b. Restart the computer.

c. Wait for automatic policy propagation, which occurs at regular, configurable intervals.

d. Policy propagation occurs every eight hours by default.

F. To export security settings to a security template

1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy

2. In the console tree, right-click Security Settings, click Export Policy, and select Local Policy or Effective Policy

3. In the Export Policy To dialog box, enter the name of the security template to which to export security settings and then click Save

|67| Chapter 13, Lesson 6

Security Configuration and Analysis

|68| 1. Overview

A. Security Configuration and Analysis is a tool that offers the ability to configure security, analyze security, view results, and resolve any discrepancies revealed by analysis.

B. This tool is located on the Security Configuration and Analysis console.

|69| 2. How the Security Configuration and Analysis Console Works

A. The console uses a database to perform configuration and analysis functions.

B. The database is a computer-specific data store.

C. The database architecture allows the use of personal databases, security template import and export, and the combination of multiple security templates into one composite security template that can be used for analysis or configuration.

D. New security templates can be incrementally added to the database to create a composite security template.

E. Overwriting a template is also an option.

F. Personal databases can be created for storing customized security templates.

|70| 3. Security Configuration

A. The Security Configuration and Analysis console can be used to configure local system security.

B. Security templates created with the Security Templates console can be imported and applied to the GPO for the local computer.

C. System security is immediately configured with the levels specified in the template.

|71| 4. Security Analysis

A. The state of the OS and applications on a computer is dynamic.

B. Changes made to meet specific needs may not be reversed when the requirement is finished.

1. The computer may no longer meet the requirements for enterprise security.

C. The Security Configuration and Analysis console allows administrators to perform a quick security analysis.

D. In the analysis, recommendations are presented alongside current system settings; icons or remarks are used to highlight any areas where the current settings do not match the proposed level of security.

|72| E. The Security Configuration and Analysis console offers the ability to resolve any discrepancies revealed by analysis.

F. Regular analysis enables an administrator to track and ensure an adequate level of security on each computer as part of an enterprise risk management program.

G. Analysis is highly specified, and information about all system aspects related to security is provided in the results.

1. Enables an administrator to tune the security levels and to detect any security flaws that may occur in the system over time

|73| 5. Using Security Configuration and Analysis

A. Tasks

1. Access the Security Configuration and Analysis console.

2. Set a working security database.

3. Import a security template into a security database.

4. Analyze system security.

5. View security analysis results.

6. Configure system security.

7. Export security database settings to a security template.

B. To access the Security Configuration and Analysis console

1. Do one of the following:

a. Add the Security Configuration and Analysis console to a new console, click Start, click Run, type mmc, and then click OK.

b. Add the Security Configuration and Analysis console to an existing console.

2. On the Console menu, click Add/Remove Snap-In and then click Add

3. In the Add Standalone Snap-In dialog box, select Security Configuration And Analysis and click Add

4. Click Close, and then click OK

5. On the Console menu, click Save

6. Enter the name to assign to this console and click Save

7. The console appears on the Administrative Tools menu

C. To set a working security database

1. In the Security Configuration and Analysis console, right-click Security Configuration And Analysis

2. Click Open Database

3. In the Open Database dialog box, choose an existing personal database or type a file name to create a new personal database, and then click Open

a. If an existing personal database is chosen, this database is now the working security database.

b. If a new personal database is created, the Import Template dialog box appears.

4. Select the security template to load into the security database and then click Open

5. This database is now the working security database.

D. Importing a security template into a security database

|74| 1. Overview

a. Several different templates can be merged into one composite template that can be used for analysis or configuration of a system by importing each template into a working database.

b. The database will merge the various templates to create one composite template, resolving conflicts in order of import; the last template imported takes precedence when there is contention.

c. Templates will not be merged into a composite template if overwrite is chosen.

d. Once the templates are imported to the selected database, the system can be analyzed or configured.

2. To import a security template into a security database

a. In the Security Configuration and Analysis console, right-click Security Configuration And Analysis

b. Open or create a working security database

c. Select Import Template

d. Select a security template file and then click Open

e. Repeat the previous step for each template to merge with previous templates into the database

Note To replace the template rather than merge it into the stored template, click the Clear This Database Before Importing check box in the Import Template dialog box.

E. Analyzing system security

|75| 1. Overview

a. The Security Configuration and Analysis console compares the current state of system security against a security template that has been imported to a personal database.

b. This template is the database configuration that contains the preferred or recommended security settings for that system.

c. Security Configuration and Analysis queries the system’s security settings for all security areas in the database configuration.

(1) Values found are compared to the database configuration.

(2) If the current system settings match the database configuration settings, they are assumed to be correct.

(3) The policies in question are displayed as potential problems that need investigation.

2. To analyze system security

a. In the Security configuration and Analysis console, set a working database

b. Right-click Security Configuration And Analysis and then click Analyze Computer Now

c. In the Perform Analysis dialog box, verify the path for the log file location and then click OK

d. The different security areas are displayed as they are analyzed

e. Once this is complete, check the log file or review the results

F. Viewing security analysis results

|76| 1. Overview

a. The Security Configuration and Analysis console displays the analysis results organized by security area with visual flags to indicate problems.

b. The current database and computer configuration settings are displayed for each security policy in the security area.

2. To view security analysis results

a. In the Security Configuration and Analysis console, click Security Configuration And Analysis

b. Double-click a security policies node and then click the security area for which to view the results

|77| c. In the details pane, the Policy column indicates the policy name for the analysis results, the Database Setting column indicates the security value in the template, and the Computer Setting column indicates the current security level in the system

(1) A red X indicates a difference from the database configuration.

(2) A green check mark indicates consistency with the database configuration.

(3) No icon indicates that the security policy was not included in the template and therefore not analyzed.

G. Configuring system security

|78| 1. Overview

a. The Security Configuration and Analysis console offers the ability to resolve any discrepancies revealed by analysis.

(1) Accept or change some or all of the values flagged or not included in the configuration if the local system security levels are valid due to the context of that computer

(2) Configure the system to the original database configuration values if the system is not in compliance with valid security levels

(3) Import a more appropriate template into the database as the new database configuration and apply it to the system

b. The import process can be repeated and multiple templates can be loaded.

(1) The database will merge the various templates to create one composite template, resolving conflicts in order of import.

(2) The last template imported takes precedence when there is contention.

c. After the templates are imported to the database, choosing Configure System Now applies the stored template to the system.

Note These changes are made to the stored template in the database, not to the security template file. The security template file is modified only if either a return is made to Security Templates and that template is edited or the stored configuration is exported to the same template file.

d. Using the Security Configuration and Analysis console is not recommended when analyzing security for domain-based clients because going to each client individually would be necessary.

e. When analyzing security for domain-based clients, it is best to return to the Security Templates console, modify the template, and reapply it to the appropriate GPO.

2. To configure system security

a. In the Security Configuration and Analysis console, set a working database

b. Right-click Security Configuration And Analysis and then click Configure Computer Now

c. In the Configure System dialog box, click OK to use the default analysis log or enter a file name and valid path

d. The different security areas are displayed as they are configured; once this is complete, check the log file or analyze system security and view the results

3. To edit the database security configuration

a. In the Security Configuration and Analysis console, click Security Configuration And Analysis

b. Double-click a security policies node and then click a security area

c. In the details pane, double-click the security attribute to edit

d. Click the Define This Policy In The Database check box to allow editing

e. Enter a new value for the security policy and then click OK

f. Repeat the previous four steps for each security policy to edit

4. To view security configuration results

a. In the console from which group policy is managed, double-click the GPO

b. In the console tree, click Security Settings

c. Double-click a security policy node and then click a security area

d. Double-click the security attribute to view

H. Exporting Security Templates

|79| 1. Overview

a. The export feature provides the ability to save a security database configuration as a new template file that can be imported into other databases, used as is to analyze or configure a system, or even defined with the Security Templates console.

2. To export security database settings to a security template

a. In the Security Configuration and Analysis console, right-click Security Configuration and Analysis.

b. Click Export Template if a composite security template was created by importing multiple templates into one database and the composite template was saved as a separate template file

c. In the Export Template To dialog box, type a valid file name in the File Name box, type a path to where the template should be saved in the Save In list, select the type of file to save in the Save As Type list, and then click Save.

|80| Chapter 13, Lesson 7

Troubleshooting a Security Configuration

1. Security Configuration Troubleshooting Scenarios

|81| A. Symptom: The user received an error message such as “Event Message: Event ID 1202, Event Source: scecli, Warning (0x%x) Occurs To Apply Security Policies”

1. Cause: Group policy was not refreshed after changes were made

2. Solution: Trigger another application of group policy settings or local policy refresh by using the Secedit command-line tool to refresh security settings

|82| B. Symptom: The user received an error message such as “Failed To Open The Group Policy Object”

1. Cause: The most likely causes for this error are network-related

2. Solution: Check the DNS configuration for the following:

a. Make sure no stale entries exist in the DNS database.

b. Resolve local DNS servers and ISP DNS server entries.

|83| C. Symptom: Modified security settings are not taking effect

1. Causes:

a. Any policies configured locally may be overridden by like policies specified in the domain.

b. If the setting shows up in local policy but not in effective policy, it implies that a policy from the domain is overriding the setting.

c. As group policy changes are applied periodically, it is likely that the policy changes made in the directory have not yet been refreshed in the computer.

2. Solution: Manually do a policy refresh by typing the following at the command line: secedit /refreshpolicy machine_policy

|84| D. Symptom: Policies do not migrate from Windows NT 4.0 to Windows 2000

2. Cause: Windows NT 4.0 policies cannot be migrated to Windows 2000

Note In Windows NT 4.0, system policies were stored in one .pol file with group information embedded; no method is available to translate that information to the Windows 2000 Active Directory structure. Groups are handled very differently in Windows 2000.

2. Solutions:

a. Windows NT 4.0 clients accessing a Windows 2000 Server computer, and Windows 2000 Professional clients accessing a Windows NT 4.0 Server computer, will use the Netlogon share.

b. With Windows 2000 Server, when a Windows NT 4.0 client is upgraded to Windows 2000, it will get only Active Directory–based group policy settings and not Windows NT 4.0–style policies.

c. Although Windows NT 4.0–style policies may be enabled if the administrator chooses to do so, this practice is strongly discouraged.

d. Because Windows NT 4.0–style policies are applied only during the logon process, both computer and user settings are processed; this is not optimal behavior for the following reasons:

(1) The Windows NT 4.0–style computer settings override the group policy settings that have already been applied to the computer during startup.

(2) During the group policy settings refresh cycle, the group policy settings change any conflicting settings back, creating an indeterminate state.

(3) Windows NT 4.0–style policies result in persistent settings in the registry.

Note Terminal Server cannot allow computer settings to be set based on a user logon.