WINDOWS 1002000 PROFESSIONAL RESOURCE KIT [Electronic resources] نسخه متنی

Security Policy

A Security Policy object contains an extensive profile of security permissions that apply primarily to the security settings of a domain, computer, or computer desktop (rather than to users). A single Security Policy object can be applied to all of the computers in an organizational unit. Security Policy is applied when an individual computer starts up, and is periodically refreshed if changes are made without restarting.

How Security Policy Works

Stand-alone computers have Security Policy associated with them that can be modified by users with the appropriate rights. When a computer joins a domain, the domain Security Policy is applied to the local computer. Domain Security Policy will override any changes made to Security Policy at the desktop level.

For information about Security Policy and Group Policy for computers in a domain, see the Deployment Planning Guide and Windows 2000 Help.

Security Policy is to computers as security groups are to users. Security Policy lets you apply a single security profile to multiple computers, just as security groups let you grant a standardized set of rights to a group of users. It enforces consistency and provides easy administration.

Security Policy objects contain permissions and parameters that implement multiple types of security strategies.

Prerequisites for Implementing Local Security Policy

Security Policy is installed by default on local computers. However, Active Directory must be installed on a server before you can edit and apply domainwide Security Policy objects.

How to Implement Security Policy

To apply local Security Policy, see Windows 2000 Professional Help.

In a domain, to view a sample Security Policy, open the Group Policy snap-in in the MMC and navigate to the Security Settings container:

Local Computer Policy
Computer Configuration
Windows Settings
Security Settings

Under Security Settings there are nine subdirectories of security policy settings. These nine groups are described later in this chapter.

Implementing Security Policy consists of creating a new Group Policy object (or modifying an existing one), enabling appropriate settings within the object, and then linking the Group Policy object to an organizational unit that contains computers in the domain.

Group Policy Considerations

Minimize the number of Group Policy objects, including Security Policy objects, that apply to users and computers. Do this first, because each computer and user Group Policy object must be loaded to a computer during startup and to user profiles at logon. Multiple Group Policy objects increase computer startup and logon time. Second, applying multiple Group Policy objects can create policy conflicts that are difficult to troubleshoot.

In general, Group Policy can be passed down from parent to child sites, domains, and organizational units. If you have assigned a specific Group Policy to a high-level parent, that Group Policy applies to all organizational units beneath the parent, including the user and computer objects in each container. For more information about inheritance of Group Policy settings, see "Defining Client Administration and Configuration Standards" in the Deployment Planning Guide.

Security templates (described later in this chapter) are useful as models of security settings appropriate for different types of Group Policy.

Security Policy Settings

The following are the nine groups of Security Policy features mentioned previously. They are containers located in the Security Settings node of a Group Policy object. Although there are some differences regarding whether you are managing Security Policy for a domain or for a local computer, in general Security Policy includes much the same thing. For a local Security Policy, find the following:

Password Policy

Account Lockout Policy

Kerberos Authentication Policy

Audit Policy

User Rights Assignment

Security Options

Encrypted Data Recovery Agent

Internet Protocol Security Policies

Some of the policy areas apply only to the scope of a domain; that is, the policy settings are domainwide. Account policies, for example, apply uniformly to all user accounts in the domain. If you cannot define different account policies for different organizational units in the same domain, the policy will affect only the account policies on member workstations and servers contained within the organizational unit (OU).

Account Policies

Account policies are the first subcategory of Security Settings. The Account policies include the following:

Password Policy You can modify password policy to meet your organization's security needs. For example, you can specify minimum password length and maximum password age. You can also require complex passwords and prevent users from reusing passwords or simple variations of passwords. Note that password policy can be applied in Active Directory as well as in your local computer's security policy. If multiple policies are set, the most restrictive policy is used.

Account Lockout Policy You can force users to be locked out after a specified number of failed logon attempts. You can also specify the period of time that accounts are frozen.

Kerberos Authentication Policy You can modify the default Kerberos settings for each domain. For example, you can set the maximum lifetime of a user ticket. Kerberos Authentication Policy is only applicable at a domain level, so no Kerberos Authentication Policy settings are available for local security policy.

The policies you choose affect the level of help desk support required for users as well as the vulnerability of your network to security breaches and attacks. For example, specifying a restrictive account lockout policy increases the potential for denial of service attacks, and setting a restrictive password policy results in increased help desk calls from users who cannot log on to the network.

In addition, specifying restrictive password policy can actually reduce the security of the network. For example, if you require passwords longer than seven characters, most users have difficulty remembering them. They might write their passwords down and leave them where an intruder can easily find them.

Local Computer Policies

The second subcategory of Security Settings is Local Computer policies. Local Computer policies include the following:

Audit Policy Windows 2000 can record a range of security event types, from a systemwide event, such as a user logging on, to an attempt by a particular user to read a specific file. Both successful and unsuccessful attempts to perform an action can be recorded.

User Rights Assignment You can control the rights assigned to user accounts and security groups for local computers. You can specify users and security groups who have rights to perform a variety of tasks affecting security. For example, you can control access to computers from the network, who can log on locally, or who can shut down the system. You can specify who has rights to perform critical administrative tasks on the computer, such as backing up and restoring files and directories, taking ownership of files and objects, and forcing shutdown from a remote system.

Security Options You can control a wide variety of security options for local computers. For example, you can specify policies that force users to log off when logon hours expire, disable CTRL+ALT+DEL for logon (to force smart card logon), and force computers to halt if unable to audit.

Public Key Policies

This subdivision of security settings lets you add a new Encrypted Data Recovery Agent and set up Automatic Certificate Requests. You can also manage your lists of trusted certification authorities.

Internet Protocol Security Policies

The policies in this section describe how to handle a variety of requests for Internet Protocol security (IPSec) communications. You can require secure communication, permit secure communication, or communicate without using IPSec. The predefined policies are not intended for immediate use. They provide examples of behavior for testing purposes. Network security administrators need to carefully design and assign their own custom IPSec policy to computers. For more information about working with Internet Protocol security policies, see "Internet Protocol Security" later in this chapter, or see the Deployment Planning Guide, the Microsoft® Windows® 2000 Server Resource Kit Distributed Systems Guide, or the Internetworking Guide.

Security Settings by Policy

The following tables list the default security settings by policy.

Account Policies

Default settings for Password Policies on a local computer are described in Table 13.9.

Table 13.9 Password Policy

Default settings for Account Lockout Policies on a local computer are described in Table 13.10.

Table 13.10 Account Lockout Policy

Local Policies

Default settings for Audit Policies on a local computer are described in Table 13.11.

Table 13.11 Audit Policy

Default settings for User Rights Assignment Policies on a local computer are described in Table 13.12.

Table 13.12 User Rights Assignment Policy

NOTE

---

To permit users to log on to a computer, grant the user or group of users the Log on locally right listed above.

Default settings for Security Options Policies on a local computer are described in Table 13.13.

Table 13.13 Security Options Policy

Public Key Policies

Default settings for the Encrypted Data Recovery Agent Policy are described in Table 13.14.

Table 13.14 Encrypted Data Recovery Agent Policy

Internet Protocol Security Policies on Local Computer

Default settings for Internet Protocol Security Policies on a local computer are described in Table 13.15.

Table 13.15 Internet Protocol Security Policies on Local Computer

Security Settings by Policy Setting

The following section lists the policies which are enabled, disabled, or not set.

Enabled

The following policies are enabled by default when you install Windows 2000 Professional on a stand-alone computer:

Allow system to be shut down without having to log on.

Automatically log off users when logon time expires (local).

Digitally sign client communication (when possible).

Secure channel: Digitally encrypt secure channel data (when possible).

Secure channel: Digitally sign secure channel data (when possible).

Strengthen default permissions of global system objects (for example, Symbolic Links).

Disabled

The following policies are disabled by default when you install Windows 2000 Professional on a stand-alone computer:

Passwords must meet complexity requirements.

Store password using reversible encryption for all users in the domain.

Account lockout threshold.

Audit the access of global system objects.

Audit use of Backup and Restore privilege.

Clear virtual memory pagefile when system shuts down.

Digitally sign client communication (always).

Digitally sign server communication (always).

Digitally sign server communication (when possible).

Do not display last user name on logon screen.

Prevent system maintenance of computer account password.

Prevent users from installing printer drivers.

Recovery Console: Allow automatic administrative logon.

Recovery Console: Allow floppy copy and access to all drives and all folders.

Restrict CD-ROM access to locally logged-on user only.

Restrict floppy access to locally logged-on user only.

Secure channel: Digitally encrypt or sign secure channel data (always).

Secure channel: Require strong (Windows 2000 or later) session key.

Send unencrypted password to connect to third-party SMB servers.

Shut down system immediately if unable to log security audits.

Additional restrictions for anonymous connections.

Message text for users attempting to log on.

Message title for users attempting to log on.

Smart card removal behavior.

Audit account logon events.

Audit account management.

Audit logon events.

Audit object access.

Audit policy change.

Audit privilege use.

Audit process tracking.

Audit system events.

Not Defined

By default, the following policies are not defined. This does not mean that values are not set for these parameters on the system. It just means that there is no local policy defined for these parameters.

Account lockout duration.

Reset account lockout counter after.

Audit directory service access.

Allow server operators to schedule tasks (domain controllers only).

Disable CTRL+ALT+DEL requirement for logon.

Rename administrator account.

Rename guest account.

Unsigned driver installation behavior.

Unsigned non-driver installation behavior.

Not Granted

By default, the following policies are not granted to any particular group when you clean-install Windows 2000 Professional on a stand-alone computer:

Act as part of the operating system.

Add workstations to domain.

Create a token object.

Create permanent shared objects.

Deny access to this computer from the network.

Deny logon as a batch job.

Deny logon as a service.

Deny logon locally.

Enable computer and user accounts to be trusted for delegation.

Generate security audits.

Lock pages in memory.

Log on as a batch job.

Log on as a service.

Replace a process level token.

Synchronize directory service data.

What can an Administrator do that a Power User can't? By default, a member of the Administrators group can:

Install the operating system.

Install or configure hardware device drivers, although Power Users are allowed to install printer drivers.

Install system services.

Install Service Packs and Windows Updates.

Upgrade the operating system.

Repair the operating system.

Install applications that modify Windows system files.

Configure password policy.

Configure audit policy.

Manage security logs.

Create administrative shares.

Create administrative accounts.

Modify groups or accounts created by other users.

Remotely access the registry.

Stop or start any service.

Configure services.

Increase quotas.

Increase execution priorities

Remotely shut down the system.

Take ownership of arbitrary objects.

Assign rights to members of the Users group.

Override a locked computer.

Format a hard disk drive.

Modify systemwide environment variables

Access the private data of members of the Users group.

Back up and restore files.

What can a Power User do that a User can't? By default, a member of the Power Users group can:

Create local users and groups.

Modify users and groups that they have created.

Create and delete nonadministrator file shares.

Create, manage, delete, and share local printers.

Change system time (default user right).

Stop or start non-auto-started services.

By default, members of the Power Users group are granted the following permissions:

Modify access to the Program Files directory.

Modify access to many locations within the HKEY_LOCAL_MACHINESoftware registry hive.

Write access to most system directories including %windir% and %windir%system32.

These permissions allow members of the Power Users group to:

Perform per-computer installation of many applications. For example, applications that do not modify Windows system files or do not modify HKEY_LOCAL_MACHINESystem.

Run legacy applications that improperly store per-user data in per-computer locations (without receiving error messages).

Unfortunately, these permissions also allow members of the Power Users group to:

Plant Trojan horses that, if executed by administrators or other users, can compromise system and data security.

Make systemwide operating system and application changes that affect other users of the system.