Security

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 organizations 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 computers 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 MicrosoftWindows 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.8 Password Policy

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

Table 13.9 Account Lockout Policy

Local Policies

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

Table 13.10 Audit Policy

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

Table 13.11 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.12 Security Options Policy

Public Key Policies

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

Table 13.13 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.14 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.

Comparison of Group Capabilities

What can an Administrator do that a Power User cant? 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 cant? 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_MACHINE\Software 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_MACHINE\System.

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