Security setting descriptions

To locate this security setting in the console tree in Microsoft Management Console (MMC), see Computer Configuration\Windows Settings\Security Settings

Security area | Description
Account Policies | Password policy, Account lockout policy, and Kerberos policy
Local Policies | Auditing policy, User rights assignment, and Security options
Event Log | Application, system, and security Event Log settings
Restricted Groups | Membership of security-sensitive groups
System Services | Startup and permissions for system services
Registry | Permissions for registry keys
File System | Permissions for folders and files

You can configure the security settings that are described in this section on one computer, or on many computers, by using the Security Configuration Manager tools. The Security Configuration Manager tools consist of:

  • Security Templates
  • Security Configuration and Analysis
  • The Secedit.exe command-prompt tool
  • Local Security Policy
  • The Security Settings Extension to Group Policy

To set or to modify individual security settings on individual computers, use Local Security Policy. To define security settings that are enforced on any number of computers, use the Security Settings Extension to Group Policy. To apply several settings in a batch, use Security Templates to define the settings, and then apply those settings by using Security Configuration and Analysis or Secedit.exe, or import the template that contains your settings into Local Policy or Group Policy.


Account policies

All security policies are computer-based policies. Account policies are defined on computers, yet they affect how user accounts can interact with the computer or domain. Account policies contain three subsets:

  • Password policy
  • Account lockout policy
  • Kerberos policy

For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain policy, and it is enforced by the domain controllers that make up the domain. A domain controller always obtains the account policy from the Default Domain Policy Group Policy object (GPO), even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (such as member computers) will also receive the same account policy for their local accounts. However, local account policies can be different from the domain account policy, such as when you define an account policy specifically for the local accounts.

For more information, see Account and local policies.


Password policy

Password policies are used for domain accounts or local user accounts. They determine settings for passwords, such as enforcement and lifetimes. This section covers:

  • Enforce password history
  • Maximum password age
  • Minimum password age
  • Minimum password length
  • Passwords must meet complexity requirements
  • Store passwords using reversible encryption


Enforce password history

Description

This security setting determines the number of unique new passwords that have to be associated with a user account before an old password can be reused. The value must be between 0 and 24 passwords.

This policy enables administrators to enhance security by ensuring that old passwords are not reused continually.

Default:

  • 24 on domain controllers.
  • 0 on stand-alone servers.

Note

  • By default, member computers follow the configuration of their domain controllers.

To maintain the effectiveness of the password history, do not allow passwords to be changed immediately after they were just changed by also enabling the Minimum password age security policy setting. For information about the minimum password age security policy setting, see Minimum password age.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

For specific instructions about how to configure password policy settings, see To apply or modify password policy.

For more information, see:

  • Best practices for passwords
  • Password policy
  • Security Configuration Manager Tools


Maximum password age

Description

This security setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If the maximum password age is between 1 and 999 days, the Minimum password age must be less than the maximum password age. If the maximum password age is set to 0, the minimum password age can be any value between 0 and 998 days.

Note

  • It is a security best practice to have passwords expire every 30 to 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to crack a user's password and have access to your network resources.

Default: 42.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

For specific instructions about how to configure password policy settings, see To apply or modify password policy.

For more information, see:

  • Best practices for passwords
  • Password policy


Minimum password age

Description

This security setting determines the period of time (in days) that a password must be used before the user can change it. You can set a value between 1 and 998 days, or you can allow changes immediately by setting the number of days to 0.

The minimum password age must be less than the Maximum password age, unless the maximum password age is set to 0, indicating that passwords will never expire. If the maximum password age is set to 0, the minimum password age can be set to any value between 0 and 998.

Configure the minimum password age to be more than 0 if you want Enforce password history to be effective. Without a minimum password age, users can cycle through passwords repeatedly until they get to an old favorite. The default setting does not follow this recommendation, so that an administrator can specify a password for a user and then require the user to change the administrator-defined password when the user logs on. If the password history is set to 0, the user does not have to choose a new password. For this reason, Enforce password history is set to 1 by default.

Default:

  • 1 on domain controllers.
  • 0 on stand-alone servers.

Note

  • By default, member computers follow the configuration of their domain controllers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

For specific instructions about how to configure password policy settings, see To apply or modify password policy.

For more information, see:

  • Best practices for passwords
  • Password policy


Minimum password length

Description

This security setting determines the least number of characters that a password for a user account may contain. You can set a value of between 1 and 14 characters, or you can establish that no password is required by setting the number of characters to 0.

Default:

  • 7 on domain controllers.
  • 0 on stand-alone servers.

Note

  • By default, member computers follow the configuration of their domain controllers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

For specific instructions about how to configure password policy settings, see To apply or modify password policy.

For more information, see:

  • Best practices for passwords
  • Password policy


Password must meet complexity requirements

Description

This security setting determines whether passwords must meet complexity requirements.

If this policy is enabled, passwords must meet the following minimum requirements:

  • Not contain all or part of the user's account name
  • Be at least six characters in length
  • Contain characters from three of the following four categories:
    • English uppercase characters (A through Z)
    • English lowercase characters (a through z)
    • Base 10 digits (0 through 9)
    • Non-alphabetic characters (for example, !, $, #, %)

Complexity requirements are enforced when passwords are changed or created.

To create custom password filters, see the Microsoft Platform Software Development Kit and TechNet on the Microsoft Web site.(http://www.microsoft.com/)

Default:

  • Enabled on domain controllers.
  • Disabled on stand-alone servers.

Note

  • By default, member computers follow the configuration of their domain controllers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

For specific instructions about how to configure password policy settings, see To apply or modify password policy.

For more information, see:

  • Strong Passwords
  • Best practices for passwords
  • Password policy


Store passwords using reversible encryption

Description

This security setting determines whether the operating system stores passwords using reversible encryption.

This policy provides support for applications that use protocols that require knowledge of the user's password for authentication purposes. Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information.

This policy is required when using Challenge-Handshake Authentication Protocol (CHAP) authentication through remote access or Internet Authentication Services (IAS). It is also required when using Digest Authentication in Internet Information Services (IIS).

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

For specific instructions about how to configure password policy settings, see To apply or modify password policy.

For more information, see:

  • Best practices for passwords
  • Password policy


Account lockout policy

Account lockout policies are used for domain accounts or local user accounts. They determine the circumstances and length of time that an account will be locked out of the system. This section covers:

  • Account lockout duration
  • Account lockout threshold
  • Reset account lockout counter after


Account lockout duration

Description

This security setting determines the number of minutes a locked-out account remains locked out before automatically becoming unlocked. The available range is from 0 minutes through 99,999 minutes. If you set the account lockout duration to 0, the account will be locked out until an administrator explicitly unlocks it.

If an account lockout threshold is defined, the account lockout duration must be greater than or equal to the reset time.

Default: None, because this policy setting only has meaning when an Account lockout threshold is specified.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\

For specific instructions about how to configure account lockout policy settings, see To apply or modify account lockout policy.

For more information, see:

  • Best practices for account lockout policy
  • Account lockout policy


Account lockout threshold

Description

This security setting determines the number of failed logon attempts that causes a user account to be locked out. A locked-out account cannot be used until it is reset by an administrator or until the lockout duration for the account has expired. You can set a value between 0 and 999 failed logon attempts. If you set the value to 0, the account will never be locked out.

Failed password attempts against workstations or member servers that have been locked using either CTRL+ALT+DELETE or password-protected screen savers count as failed logon attempts.

Default: 0.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\

For specific instructions about how to configure account lockout policy settings, see To apply or modify account lockout policy.

For more information, see:

  • Best practices for account lockout policy
  • Account lockout policy


Reset account lockout counter after

Description

This security setting determines the number of minutes that must elapse after a failed logon attempt before the failed logon attempt counter is reset to 0 bad logon attempts. The available range is 1 minute to 99,999 minutes.

If an account lockout threshold is defined, this reset time must be less than or equal to the Account lockout duration.

Default: None, because this policy setting only has meaning when an Account lockout threshold is specified.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\

For specific instructions about how to configure account lockout policy settings, see To apply or modify account lockout policy.

For more information, see:

  • Best practices for account lockout policy
  • Account lockout policy


Kerberos policy

Kerberos policies are used for domain user accounts. They determine Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in Local Computer Policy. This section covers:

  • Enforce user logon restrictions
  • Maximum lifetime for service ticket
  • Maximum lifetime for user ticket
  • Maximum lifetime for user ticket renewal
  • Maximum tolerance for computer clock synchronization


Enforce user logon restrictions

Description

This security setting determines whether the Kerberos V5 Key Distribution Center (KDC) validates every request for a session ticket against the user rights policy of the user account. Validation of each request for a session ticket is optional, because the extra step takes time and it may slow network access to services.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Kerberos policy
  • To configure Kerberos policy


Maximum lifetime for service ticket

Description

This security setting determines the maximum amount of time (in minutes) that a granted session ticket can be used to access a particular service. The setting must be greater than 10 minutes and less than or equal to the setting for Maximum lifetime for user ticket.

If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 Key Distribution Center (KDC). Once a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the session ticket that is used to authenticate the connection expires during the connection.

Default: 600 minutes (10 hours).

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Kerberos policy
  • To configure Kerberos policy


Maximum lifetime for user ticket

Description

This security setting determines the maximum amount of time (in hours) that a user's ticket-granting ticket (TGT) may be used. When a user's TGT expires, a new one must be requested or the existing one must be "renewed."

Default: 10 hours.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Kerberos policy
  • To configure Kerberos policy


Maximum lifetime for user ticket renewal

Description

This security setting determines the period of time (in days) during which a user's ticket-granting ticket (TGT) may be renewed.

Default: 7 days.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Kerberos policy
  • To configure Kerberos policy


Maximum tolerance for computer clock synchronization

Description

This security setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller running Windows Server 2003 that provides Kerberos authentication.

To prevent "replay attacks," Kerberos V5 uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible. In other words, both computers must be set to the same time and date. Because the clocks of two computers are often out of sync, administrators can use this policy to establish the maximum acceptable difference to Kerberos V5 between a client clock and domain controller clock. If the difference between a client clock and the domain controller clock is less than the maximum time difference that is specified in this policy, any time stamp that is used in a session between the two computers is considered to be authentic.

Important

  • This setting is not persistent. If you configure this setting and then restart the computer, this setting reverts to the default value. For more information, see the Microsoft Knowledge Base (http://www.microsoft.com/).

Default: 5 minutes.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Kerberos policy
  • To configure Kerberos policy


Local policies

These policies apply to computers, and they contain these subsets:

  • Auditing policy. Determines whether security events are logged into the Security log on the computer. Also determines whether to log successful attempts, failed attempts or both. (The Security log is part of Event Viewer.)
  • User rights assignment. Determines which users or groups have logon rights or privileges on the computer.
  • Security options. Enables or disables security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD-ROM access, driver installation, and logon prompts.


Auditing policy

Before you implement auditing policy, you must decide which event categories you want to audit. The auditing settings that you choose for the event categories define your auditing policy. On member servers and workstations that are joined to a domain, auditing settings for the event categories are undefined by default. On domain controllers, auditing is turned off by default. By defining auditing settings for specific event categories, you can create an auditing policy that suits the security needs of your organization.

The event categories that you can choose to audit are:

  • Audit account logon events
  • Audit account management
  • Audit directory service access
  • Audit logon events
  • Audit object access
  • Audit policy change
  • Audit privilege use
  • Audit process tracking
  • Audit system events

For more information about auditing, see Auditing security events.


Audit account logon events

Description

This security setting determines whether to audit each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. Account logon events are generated when a domain user account is authenticated on a domain controller. The event is logged in the domain controller's security log. Logon events are generated when a local user is authenticated on a local computer. The event is logged in the local security log. Account logoff events are not generated.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when an account logon attempt succeeds. Failure audits generate an audit entry when an account logon attempt fails.

To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

If success auditing for account logon events is enabled on a domain controller, an entry is logged for each user who is validated against that domain controller, even though the user is actually logging on to a workstation that is joined to the domain.

Default: Success.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

Account Logon Events
672 | An authentication service (AS) ticket was successfully issued and validated.
673 | A ticket granting service (TGS) ticket was granted.
674 | A security principal renewed an AS ticket or TGS ticket.
675 | Preauthentication failed. This event is generated on a Key Distribution Center (KDC) when a user types in an incorrect password.
676 | Authentication ticket request failed. This event is not generated in XOX or in the Windows Server 2003 family.
677 | A TGS ticket was not granted. This event is not generated in XOX or in the Windows Server 2003 family.
678 | An account was successfully mapped to a domain account.
681 | Logon failure. A domain account logon was attempted. This event is not generated in XOX or in the Windows Server 2003 family.
682 | A user has reconnected to a disconnected terminal server session.
683 | A user disconnected a terminal server session without logging off.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Audit logon events
  • Auditing policy
  • Best practices for auditing


Audit account management

Description

This security setting determines whether to audit each event of account management on a computer. Examples of account management events include:

  • A user account or group is created, changed, or deleted.
  • A user account is renamed, disabled, or enabled.
  • A password is set or changed.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when any account management event succeeds. Failure audits generate an audit entry when any account management event fails. To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Default:

  • Success on domain controllers.
  • No auditing on member servers

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

Account Management Events
624 | A user account was created.
627 | A user password was changed.
628 | A user password was set.
630 | A user account was deleted.
631 | A global group was created.
632 | A member was added to a global group.
633 | A member was removed from a global group.
634 | A global group was deleted.
635 | A new local group was created.
636 | A member was added to a local group.
637 | A member was removed from a local group.
638 | A local group was deleted.
639 | A local group account was changed.
641 | A global group account was changed.
642 | A user account was changed.
643 | A domain policy was modified.
644 | A user account was auto locked.
645 | A computer account was created.
646 | A computer account was changed.
647 | A computer account was deleted.
648 | A local security group with security disabled was created. Note: SECURITY_DISABLED in the formal name means that this group cannot be used to grant permissions in access checks.
649 | A local security group with security disabled was changed.
650 | A member was added to a security-disabled local security group.
651 | A member was removed from a security-disabled local security group.
652 | A security-disabled local group was deleted.
653 | A security-disabled global group was created.
654 | A security-disabled global group was changed.
655 | A member was added to a security-disabled global group.
656 | A member was removed from a security-disabled global group.
657 | A security-disabled global group was deleted.
658 | A security-enabled universal group was created.
659 | A security-enabled universal group was changed.
660 | A member was added to a security-enabled universal group.
661 | A member was removed from a security-enabled universal group.
662 | A security-enabled universal group was deleted.
663 | A security-disabled universal group was created.
664 | A security-disabled universal group was changed.
665 | A member was added to a security-disabled universal group.
666 | A member was removed from a security-disabled universal group.
667 | A security-disabled universal group was deleted.
668 | A group type was changed.
684 | Set the security descriptor of members of administrative groups. Note: Every 60 minutes on a domain controller a background thread searches all members of administrative groups (such as domain, enterprise, and schema administrators) and applies a fixed security descriptor on them. This event is logged.
685 | Name of an account was changed.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Auditing policy
  • Best practices for auditing


Audit directory service access

Description

This security setting determines whether to audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.

By default, this value is set to no auditing in the Default Domain Controller Group Policy object (GPO), and it remains undefined for workstations and servers where it has no meaning.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has a SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a SACL specified. To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Note that you can set a SACL on an Active Directory object by using the Security tab in that object's Properties dialog box. This is the same as Audit object access, except that it applies only to Active Directory objects and not to file system and registry objects.

Default:

  • Success on domain controllers.
  • Undefined for a member computer.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

There is only one directory service access event, which is identical to the Object Access security event message 566.

Directory service access events
566 A generic object operation took place.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Auditing policy
  • Best practices for auditing


Audit logon events

Description

This security setting determines whether to audit each instance of a user logging on to or logging off from a computer.

Account logon events are generated on domain controllers for domain account activity and on local computers for local account activity. If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on the workstation or server, and they generate an account logon event on the domain controller. Additionally, interactive logons to a member server or workstation that use a domain account generate a logon event on the domain controller as the logon scripts and policies are retrieved when a user logs on. For more information about account logon events, see Audit account logon events.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit entry when a logon attempt fails.

To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Default: Success.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

Logon Events
Event ID | Description
528 | A user successfully logged on to a computer. For information about the type of logon, see the Logon Types table below.
529 | Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password.
530 | Logon failure. A logon attempt was made user account tried to log on outside of the allowed time.
531 | Logon failure. A logon attempt was made using a disabled account.
532 | Logon failure. A logon attempt was made using an expired account.
533 | Logon failure. A logon attempt was made by a user who is not allowed to log on at this computer.
534 | Logon failure. The user attempted to log on with a type that is not allowed.
535 | Logon failure. The password for the specified account has expired.
536 | Logon failure. The Net Logon service is not active.
537 | Logon failure. The logon attempt failed for other reasons. Note: In some cases, the reason for the logon failure may not be known.
538 | The logoff process was completed for a user.
539 | Logon failure. The account was locked out at the time the logon attempt was made.
540 | A user successfully logged on to a network.
541 | Main mode Internet Key Exchange (IKE) authentication was completed between the local computer and the listed peer identity (establishing a security association), or quick mode has established a data channel.
542 | A data channel was terminated.
543 | Main mode was terminated. Note: This might occur as a result of the time limit on the security association expiring (the default is eight hours), policy changes, or peer termination.
544 | Main mode authentication failed because the peer did not provide a valid certificate or the signature was not validated.
545 | Main mode authentication failed because of a Kerberos failure or a password that is not valid.
546 | IKE security association establishment failed because the peer sent a proposal that is not valid. A packet was received that contained data that is not valid.
547 | A failure occurred during an IKE handshake.
548 | Logon failure. The security ID (SID) from a trusted domain does not match the account domain SID of the client.
549 | Logon failure. All SIDs corresponding to untrusted namespaces were filtered out during an authentication across forests.
550 | Notification message that could indicate a possible denial-of-service attack.
551 | A user initiated the logoff process.
552 | A user successfully logged on to a computer using explicit credentials while already logged on as a different user.
682 | A user has reconnected to a disconnected terminal server session.
683 | A user disconnected a terminal server session without logging off. Note: This event is generated when a user is connected to a terminal server session over the network. It appears on the terminal server.
When event 528 is logged, a logon type is also listed in the event log. The following table describes each logon type.
Logon type | Logon title | Description
2 | Interactive | A user logged on to this computer.
3 | Network | A user or computer logged on to this computer from the network.
4 | Batch | Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.
5 | Service | A service was started by the Service Control Manager.
7 | Unlock | This workstation was unlocked.
8 | NetworkCleartext | A user logged on to this computer from the network. The user's password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext).
9 | NewCredentials | A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.
10 | RemoteInteractive | A user logged on to this computer remotely using Terminal Services or Remote Desktop.
11 | CachedInteractive | A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Auditing policy
  • Best practices for auditing


Audit object access

Description

This security setting determines whether to audit the event of a user accessing an object—for example, a file, folder, registry key, printer, and so forth—that has its own system access control list (SACL) specified.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an object that has an appropriate SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an object that has a SACL specified.

To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Note that you can set a SACL on a file system object using the Security tab in that object's Properties dialog box.

Default: No auditing.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

Object Access Events
560 | Access was granted to an already existing object.
562 | A handle to an object was closed.
563 | An attempt was made to open an object with the intent to delete it. Note: This is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile().
564 | A protected object was deleted.
565 | Access was granted to an already existing object type.
567 | A permission associated with a handle was used. Note: A handle is created with certain granted permissions (Read, Write, and so on). When the handle is used, up to one audit is generated for each of the permissions that was used.
568 | An attempt was made to create a hard link to a file that is being audited.
569 | The resource manager in Authorization Manager attempted to create a client context.
570 | A client attempted to access an object. Note: An event will be generated for every attempted operation on the object.
571 | The client context was deleted by the Authorization Manager application.
572 | The administrator manager initialized the application.
772 | The certificate manager denied a pending certificate request.
773 | Certificate Services received a resubmitted certificate request.
774 | Certificate Services revoked a certificate.
775 | Certificate Services received a request to publish the certificate revocation list (CRL).
776 | Certificate Services published the certificate revocation list (CRL).
777 | A certificate request extension was made.
778 | One or more certificate request attributes changed.
779 | Certificate Services received a request to shutdown.
780 | Certificate Services backup started.
781 | Certificate Services backup completed.
782 | Certificate Services restore started.
783 | Certificate Services restore completed.
784 | Certificate Services started.
785 | Certificate Services stopped.
786 | The security permissions for Certificate Services changed.
787 | Certificate Services retrieved an archived key.
788 | Certificate Services imported a certificate into its database.
789 | The audit filter for Certificate Services changed.
790 | Certificate Services received a certificate request.
791 | Certificate Services approved a certificate request and issued a certificate.
792 | Certificate Services denied a certificate request.
793 | Certificate Services set the status of a certificate request to pending.
794 | The certificate manager settings for Certificate Services changed.
795 | A configuration entry changed in Certificate Services.
796 | A property of Certificate Services changed.
797 | Certificate Services archived a key.
798 | Certificate Services imported and archived a key.
799 | Certificate Services published the CA certificate to Active Directory.
800 | One or more rows have been deleted from the certificate database.
801 | Role separation enabled.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Audit directory service access
  • Auditing policy
  • Best practices for auditing


Audit policy change

Description

This security setting determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies is successful. Failure audits generate an audit entry when a change to user rights assignment policies, audit policies, or trust policies fails.

To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Default:

  • Success on domain controllers.
  • No auditing on member servers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

Policy Change Events
608 | A user right was assigned.
609 | A user right was removed.
610 | A trust relationship with another domain was created.
611 | A trust relationship with another domain was removed.
612 | An audit policy was changed.
613 | An Internet Protocol security (IPSec) policy agent started.
614 | An IPSec policy agent was disabled.
615 | An IPSec policy agent changed.
616 | An IPSec policy agent encountered a potentially serious failure.
617 | A Kerberos policy changed.
618 | Encrypted Data Recovery policy changed.
620 | A trust relationship with another domain was modified.
621 | System access was granted to an account.
622 | System access was removed from an account.
623 | Per user auditing policy was set for a user. For information about per user selective auditing, see Per-user selective auditing.
625 | Per user audit policy was refreshed.
768 | A collision was detected between a namespace element in one forest and a namespace element in another forest. Note: When a namespace element in one forest overlaps a namespace element in another forest, it can lead to ambiguity in resolving a name belonging to one of the namespace elements. This overlap is also called a collision. Not all parameters are valid for each entry type. For example, fields such as DNS name, NetBIOS name, and SID are not valid for an entry of type 'TopLevelName'.
769 | Trusted forest information was added. Note: This event message is generated when forest trust information is updated and one or more entries are added. One event message is generated per added, deleted, or modified entry. If multiple entries are added, deleted, or modified in a single update of the forest trust information, all the generated event messages have a single unique identifier called an operation ID. This allows you to determine that the multiple generated event messages are the result of a single operation. Not all parameters are valid for each entry type. For example, parameters such as DNS name, NetBIOS name and SID are not valid for an entry of type "TopLevelName".
770 | Trusted forest information was deleted. Note: See note for event 769.
771 | Trusted forest information was modified. Note: See note for event 769.
805 | The event log service read the security log configuration for a session.

For more information about security events, see Security Events in the Microsoft Windows Resource Kits on the Microsoft Web site (http://www.microsoft.com/).

For more information, see:

  • Auditing policy
  • Best practices for auditing


Audit privilege use

Description

This security setting determines whether to audit each instance of a user exercising a user right.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit this type of event at all. Success audits generate an audit entry when the exercise of a user right succeeds. Failure audits generate an audit entry when the exercise of a user right fails.

To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Default: No auditing.

Audits are not generated for use of the following user rights, even if success audits or failure audits are specified for Audit privilege use. Enabling auditing of these user rights tend to generate many events in the security log which may impede your computer's performance. To audit the following user rights, enable the FullPrivilegeAuditing registry key.

  • Bypass traverse checking
  • Debug programs
  • Create a token object
  • Replace process level token
  • Generate security audits
  • Back up files and directories
  • Restore files and directories

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

Privilege use events
576 | Specified privileges were added to a user's access token. Note: This event is generated when the user logs on.
577 | A user attempted to perform a privileged system service operation.
578 | Privileges were used on an already open handle to a protected object.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Auditing policy
  • Best practices for auditing


Audit process tracking

Description

This security setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate an audit entry when the process being tracked fails.

To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Default: No auditing

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

Detailed Tracking Events
592 | A new process was created.
593 | A process exited.
594 | A handle to an object was duplicated.
595 | Indirect access to an object was obtained.
596 | A data protection master key was backed up. Note: The master key is used by the CryptProtectData and CryptUnprotectData routines, and Encrypting File System (EFS). The master key is backed up each time a new one is created. (The default setting is 90 days.) The key is usually backed up to a domain controller.
597 | A data protection master key was recovered from a recovery server.
598 | Auditable data was protected.
599 | Auditable data was unprotected.
600 | A process was assigned a primary token.
601 | A user attempted to install a service.
602 | A scheduler job was created.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Auditing policy
  • Best practices for auditing


Audit system events

Description

This security setting determines whether to audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a system event is executed successfully. Failure audits generate an audit entry when a system event is attempted unsuccessfully.

To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.

Default:

  • Success on domain controllers.
  • No auditing on member servers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

For specific instructions about how to configure auditing policy settings, see To define or modify auditing policy settings for an event category.

System Event Messages
512 | Windows is starting up.
513 | Windows is shutting down.
514 | An authentication package was loaded by the Local Security Authority.
515 | A trusted logon process has registered with the Local Security Authority.
516 | Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages.
517 | The audit log was cleared.
518 | A notification package was loaded by the Security Accounts Manager.
519 | A process is using an invalid local procedure call (LPC) port in an attempt to impersonate a client and reply or read from or write to a client address space.
520 | The system time was changed. Note: This audit normally appears twice.

For more information about security events, see Security Events (http://www.microsoft.com/) on the Microsoft Windows Resource Kits Web site.

For more information, see:

  • Auditing policy
  • Best practices for auditing


User rights assignment

This section covers:

  • Access this computer from the network
  • Act as part of the operating system
  • Add workstations to domain
  • Adjust memory quotas for a process
  • Allow log on locally
  • Allow log on through Terminal Services
  • Back up files and directories
  • Bypass traverse checking
  • Change the system time
  • Create a pagefile
  • Create a token object
  • Create global objects
  • Create permanent shared objects
  • Debug programs
  • Deny access to this computer from the network
  • Deny log on as a batch job
  • Deny log on as a service
  • Deny log on locally
  • Deny log on through Terminal Services
  • Enable computer and user accounts to be trusted for delegation
  • Force shutdown from a remote system
  • Generate security audits
  • Impersonate a client after authentication
  • Increase scheduling priority
  • Load and unload device drivers
  • Lock pages in memory
  • Log on as a batch job
  • Log on as a service
  • Manage auditing and security log
  • Modify firmware environment variables
  • Perform volume maintenance tasks
  • Profile single process
  • Profile system performance
  • Remove computer from docking station
  • Replace a process level token
  • Restore files and directories
  • Shut down the system
  • Synchronize directory service data
  • Take ownership of files or other objects


Access this computer from the network

Description

This user right determines which users and groups are allowed to connect to the computer over the network. Terminal Services are not affected by this user right.

Default:

  • On workstations and servers:
    • Administrators
    • Backup Operators
    • Power Users
    • Users
    • Everyone
  • On domain controllers:
    • Administrators
    • Authenticated Users
    • Everyone

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Act as part of the operating system

Description

This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user.

Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned. If your organization only uses servers that are members of the Windows Server 2003 family, you do not need to assign this privilege to your users. However, if your organization uses servers running Windows 2000 or Windows NT 4.0, you might need to assign this privilege to use applications that exchange passwords in plaintext.

Caution

  • Assigning this user right can be a security risk. Only assign this user right to trusted users.

Default: Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and opening the following folder in the console tree: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Add workstations to domain

Description

This security setting determines which groups or users can add workstations to a domain.

This security setting is valid only on domain controllers. By default, any authenticated user has this right and can create up to 10 computer accounts in the domain.

Adding a computer account to the domain allows the computer to participate in Active Directory–based networking. For example, adding a workstation to a domain enables that workstation to recognize accounts and groups that exist in Active Directory.

Default: Authenticated Users on domain controllers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Note

  • Users who have the Create Computer Objects permission on the Active Directory computers container can also create computer accounts in the domain. The distinction is that users with permissions on the container are not restricted to the creation of only 10 computer accounts. In addition, computer accounts that are created by means of Add workstations to domain have Domain Administrators as the owner of the computer account, while computer accounts that are created by means of permissions on the computers container have the creator as the owner of the computer account. If a user has permissions on the container and also has the Add workstations to domain user right, the computer is added, based on the computer container permissions rather than on the user right.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Adjust memory quotas for a process

Description

This privilege determines who can change the maximum memory that can be consumed by a process.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Note

  • This privilege is useful for system tuning, but it can be misused, for example, in a denial-of-service attack.

Default: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Allow log on locally

Description

This logon right determines which users can interactively log on to this computer. Logons initiated by pressing CTRL+ALT+DEL sequence on the attached keyboard requires the user to have this logon right. Additionally this logon right may be required by some service or administrative applications that can log on users. If you define this policy for a user or group, you must also give the Administrators group this right.

Default:

  • On workstations and servers: Administrators, Backup Operators, Power Users, Users, and Guest.
  • On domain controllers: Account Operators, Administrators, Backup Operators, Print Operators, and Server Operators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Deny log on locally
  • User rights assignment
  • To assign user rights for your local computer


Allow log on through Terminal Services

Description

This security setting determines which users or groups have permission to log on as a Terminal Services client.

Default:

  • On workstation and servers: Administrators, Remote Desktop Users.
  • On domain controllers: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This setting does not have any effect on Windows 2000 computers that have not been updated to Service Pack 2.

For more information, see:

  • Deny logon through Terminal Services
  • User rights assignment
  • To assign user rights for your local computer


Back up files and directories

Description

This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system.

Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:

  • Traverse Folder/Execute File
  • List Folder/Read Data
  • Read Attributes
  • Read Extended Attributes
  • Read Permissions

Caution

  • Assigning this user right can be a security risk. Since there is no way to be sure that a user is backing up data, stealing data, or copying data to be distributed, only assign this user right to trusted users.

Default: Administrators and Backup Operators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Restore files and directories
  • User rights assignment
  • To assign user rights for your local computer


Bypass traverse checking

Description

This user right determines which users can traverse directory trees even though the user may not have permissions on the traversed directory. This privilege does not allow the user to list the contents of a directory, only to traverse directories.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default:

  • On workstations and servers:
    • Administrators
    • Backup Operators
    • Power Users
    • Users
    • Everyone
  • On domain controllers:
    • Administrators
    • Authenticated Users

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Change the system time

Description

This user right determines which users and groups can change the time and date on the internal clock of the computer. Users that are assigned this user right can affect the appearance of event logs. If the system time is changed, events that are logged will reflect this new time, not the actual time that the events occurred.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default:

  • On workstations and servers:
    • Administrators
    • Power Users
  • On domain controllers:
    • Administrators
    • Server Operators

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Create a pagefile

Description

This user right determines which users and groups can call an internal application programming interface (API) to create a page file. This user right is used internally by the operating system and usually does not need to be assigned to any users.

For information about how to specify a paging file size for a given drive, see To change the size of the virtual memory paging file.

Default: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Create a token object

Description

This security setting determines which accounts can be used by processes to create a token that can then be used to get access to any local resources when the process uses an internal application programming interface (API) to create an access token.

This user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than Local System.

Caution

  • Assigning this user right can be a security risk. Do not assign this user right to any user, group, or process that you do not want to take over the system.

Default: Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Create global objects

Description

This user right is required for a user account to create global objects during Terminal Services sessions. Users can still create session-specific objects without being assigned this user right.

Caution

  • Assigning this user right can be a security risk. Assign this user right only to trusted users.

Default:

  • Administrators
  • Local System
  • Services

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Create permanent shared objects

Description

This user right determines which accounts can be used by processes to create a directory object in the Windows 2000 Server, Windows 2000 Professional, XOX, and Windows Server 2003 family object manager.

This user right is used internally by the operating system and is useful to kernel-mode components that extend the Windows 2000 Server, Windows 2000 Professional, XOX, and Windows Server 2003 family object namespace. Because components that are running in kernel mode already have this user right assigned to them, it is not necessary to specifically assign it.

Default: Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Debug programs

Description

This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications to not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.

Caution

  • Assigning this user right can be a security risk. Only assign this user right to trusted users.

Default:

  • Administrators
  • Local System

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Deny access to this computer from the network

Description

This security setting determines which users are prevented from accessing a computer over the network. This policy setting supersedes the Access this computer from the network policy setting if a user account is subject to both policies.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Deny log on as a batch job

Description

This security setting determines which accounts are prevented from being able to log on as a batch job. This policy setting supersedes the Log on as a batch job policy setting if a user account is subject to both policies.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Deny log on as a service

Description

This security setting determines which service accounts are prevented from registering a process as a service. This policy setting supersedes the Log on as a service policy setting if an account is subject to both policies.

Note

  • This security setting does not apply to the System, Local Service, or Network Service accounts.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Deny log on locally

Description

This security setting determines which users are prevented from logging on at the computer. This policy setting supersedes the Allow log on locally policy setting if an account is subject to both policies.

Important

  • If you apply this security policy to the Everyone group, no one will be able to log on locally.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Deny log on through Terminal Services

Description

This security setting determines which users and groups are prohibited from logging on as a Terminal Services client.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This setting does not have any effect on Windows 2000 computers that have not been updated to Service Pack 2.

For more information, see:

  • Allow logon through Terminal Services
  • User rights assignment
  • To assign user rights for your local computer


Enable computer and user accounts to be trusted for delegation

Description

This security setting determines which users can set the Trusted for Delegation setting on a user or computer object.

The user or object that is granted this privilege must have write access to the account control flags on the user or computer object. A server process running on a computer (or under a user context) that is trusted for delegation can access resources on another computer using delegated credentials of a client, as long as the client account does not have the Account cannot be delegated account control flag set.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Caution

  • Misuse of this user right, or of the Trusted for Delegation setting, 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.

Default: Administrators on domain controllers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Allow a computer to be trusted for delegation
  • Allow a user to be trusted for delegation
  • User rights assignment
  • To assign user rights for your local computer


Force shutdown from a remote system

Description

This security setting determines which users are allowed to shut down a computer from a remote location on the network. Misuse of this user right can result in a denial of service.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default:

  • On workstations and servers: Administrators.
  • On domain controllers: Administrators, Server Operators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Shut down the system
  • User rights assignment
  • To assign user rights for your local computer


Generate security audits

Description

This security setting determines which accounts can be used by a process to add entries to the security log. The security log is used to trace unauthorized system access. Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial of service if the Audit: Shut down system immediately if unable to log security audits security policy setting is enabled. For more information about the Audit: Shut down system immediately if unable to log security audits security policy setting, see Audit: Shut down system immediately if unable to log security audits

Default: Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Manage auditing and security log
  • User rights assignment
  • To assign user rights for your local computer


Impersonate a client after authentication

Description

Assigning this privilege to a user allows programs running on behalf of that user to impersonate a client. Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created and then impersonating that client, which can elevate the unauthorized user's permissions to administrative or system levels.

Caution

  • Assigning this user right can be a security risk. Only assign this user right to trusted users.

Default:

  • Administrators
  • Service

Note

  • By default, services that are started by the Service Control Manager have the built-in Service group added to their access tokens. Component Object Model (COM) servers that are started by the COM infrastructure and that are configured to run under a specific account also have the Service group added to their access tokens. As a result, these services get this user right when they are started.

    In addition, a user can also impersonate an access token if any of the following conditions exist.

    • The access token that is being impersonated is for this user.
    • The user, in this logon session, created the access token by logging on to the network with explicit credentials.
    • The requested level is less than Impersonate, such as Anonymous or Identify.

    Because of these factors, users do not usually need this user right.

    For more information, search for "SeImpersonatePrivilege" in the Microsoft Platform SDK.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Increase scheduling priority

Description

This security setting determines which accounts can use a process with Write Property access to another process to increase the execution priority assigned to the other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.

Default: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Load and unload device drivers

Description

This user right determines which users can dynamically load and unload device drivers or other code in to kernel mode. This user right does not apply to Plug and Play device drivers. It is recommended that you do not assign this privilege to other users. Instead, use the StartService() API.

Caution

  • Assigning this user right can be a security risk. Do not assign this user right to any user, group, or process that you do not want to take over the system.

Default: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Lock pages in memory

Description

This security setting determines which accounts can use a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. Exercising this privilege could significantly affect system performance by decreasing the amount of available random access memory (RAM).

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Log on as a batch job

Description

This security setting allows a user to be logged on by means of a batch-queue facility.

For example, when a user submits a job by means of the task scheduler, the task scheduler logs that user on as a batch user rather than as an interactive user.

Note

  • In Windows 2000 Server, Windows 2000 Professional, XOX, and the Windows Server 2003 family, the Task Scheduler automatically grants this right as necessary.

Default: Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Deny logon as a batch job
  • User rights assignment
  • To assign user rights for your local computer


Log on as a service

Description

This security setting determines which service accounts can register a process as a service.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Deny log on as a service
  • User rights assignment
  • To assign user rights for your local computer


Manage auditing and security log

Description

This security setting determines which users can specify object access auditing options for individual resources, such as files, Active Directory objects, and registry keys.

This security setting does not allow a user to enable file and object access auditing in general. For such auditing to be enabled, the Audit object access setting in Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policies must be configured.

You can view audited events in the security log of the Event Viewer. A user with this privilege can also view and clear the security log.

Default: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Modify firmware environment values

Description

This security setting determines who can modify firmware environment values. Firmware environment variables are settings stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor.

  • On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the Last Known Good Configuration setting, which should only be modified by the system.
  • On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user right to run bootcfg.exe and to change the Default Operating System setting on Startup and Recovery in System Properties.
  • On all computers, this user right is required to install or upgrade Windows.

Note

    This security setting does not affect who can modify the system environment variables and user environment variables that are displayed on the Advanced tab of System Properties. For information about how to modify these variables, see To add or change the values of environment variables.

Default: Administrators, Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • Bootcfg
  • To assign user rights for your local computer


Perform volume maintenance tasks

Description

This security setting determines which users and groups can run maintenance tasks on a volume, such as remote defragmentation.

Use caution when assigning this user right. Users with this user right can explore disks and extend files in to memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data.

Default: Administrators

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Profile single process

Description

This security setting determines which users can use performance monitoring tools to monitor the performance of nonsystem processes.

Default: Administrators, Power users, Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Profile system performance
  • User rights assignment
  • To assign user rights for your local computer


Profile system performance

Description

This security setting determines which users can use performance monitoring tools to monitor the performance of system processes.

Default: Administrators, Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Profile single process
  • User rights assignment
  • To assign user rights for your local computer


Remove computer from docking station

Description

This security setting determines whether a user can undock a portable computer from its docking station without logging on.

If this policy is enabled, the user must log on before removing the portable computer from its docking station. If this policy is disabled, the user may remove the portable computer from its docking station without logging on.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Replace a process level token

Description

This security setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. An example of a process that uses this user right is Task Scheduler. For information about Task Scheduler, see Task Scheduler overview.

Default: Network Service, Local System.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Restore files and directories

Description

This security setting determines which users can bypass file, directory, registry, and other persistent objects permissions when restoring backed up files and directories, and determines which users can set any valid security principal as the owner of an object.

Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:

  • Traverse Folder/Execute File
  • Write

Caution

  • Assigning this user right can be a security risk. Since users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, only assign this user right to trusted users.

Default:

  • Workstations and servers: Administrators, Backup Operators.
  • Domain controllers: Administrators, Backup Operators, Server Operators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Back up files and directories
  • User rights assignment
  • To assign user rights for your local computer


Shut down the system

Description

This security setting determines which users who are logged on locally to the computer can shut down the operating system using the Shut Down command. Misuse of this user right can result in a denial of service.

Default:

  • Workstations: Administrators, Backup Operators, Power Users, Users.
  • Servers: Administrators, Backup Operators, Power Users.
  • Domain controllers: Account Operators, Administrators, Backup Operators, Server Operators, Print Operators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Force shutdown from a remote system
  • User rights assignment
  • To assign user rights for your local computer


Synchronize directory service data

Description

This security setting determines which users and groups have the authority to synchronize all directory service data. This is also known as Active Directory synchronization.

Defaults: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Take ownership of files or other objects

Description

This security setting determines which users can take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads.

Caution

  • Assigning this user right can be a security risk. Since owners of objects have full control of them, only assign this user right to trusted users.

Default: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • User rights assignment
  • To assign user rights for your local computer


Security options

This section covers:

  • Accounts: Administrator account status
  • Accounts: Guest account status
  • Accounts: Limit local account use of blank passwords to console logon only
  • Accounts: Rename administrator account
  • Accounts: Rename guest account
  • Audit: Audit the access of global system objects
  • Audit: Audit use of Backup and Restore privilege
  • Audit: Shut down system immediately if unable to log security audits
  • Devices: Allow undock without having to logon
  • Devices: Allowed to format and eject removable media
  • Devices: Prevent users from installing printer drivers
  • Devices: Restrict CD-ROM access to locally logged-on user only
  • Devices: Restrict floppy access to locally logged-on user only
  • Devices: Unassigned driver installation behavior
  • Domain controller: Allow server operators to schedule tasks
  • Domain controller: LDAP server signing requirements
  • Domain controller: Refuse machine account password changes
  • Domain member: Digitally encrypt or sign secure channel data (always)
  • Domain member: Digitally encrypt secure channel data (when possible)
  • Domain member: Digitally sign secure channel data (when possible)
  • Domain member: Maximum machine account password age
  • Domain member: Require strong (Windows 2000 or later) session key
  • Domain member: Disable machine account password changes
  • Interactive logon: Do not display last user name
  • Interactive logon: Do not require CTRL+ALT+DEL
  • Interactive logon: Message text for users attempting to log on
  • Interactive logon: Message title for users attempting to log on
  • Interactive logon: Number of previous logons to cache (in case domain controller is not available)
  • Interactive logon: Prompt user to change password before expiration
  • Interactive logon: Require Domain Controller authentication to unlock
  • Interactive logon: Require smart card
  • Interactive logon: Smart card removal behavior
  • Microsoft network client: Digitally sign communications (always)
  • Microsoft network client: Digitally sign communications (if server agrees)
  • Microsoft network client: Send unencrypted password to connect to third-party SMB servers
  • Microsoft network server: Amount of idle time required before suspending a session
  • Microsoft network server: Digitally sign communications (always)
  • Microsoft network server: Digitally sign communications (if client agrees)
  • Microsoft network server: Disconnect clients when logon time expires
  • Network access: Allow anonymous SID/name translation
  • Network access: Do not allow anonymous enumeration of SAM accounts
  • Network access: Do not allow anonymous enumeration of SAM accounts and shares
  • Network access: Do not allow storage of credentials or .NET Passports for network authentication
  • Network access: Let Everyone permissions apply to anonymous users
  • Network access: Named pipes that can be accessed anonymously
  • Network access: Remotely accessible registry paths
  • Network access: Remotely accessible registry paths and subpaths
  • Network access: Restrict anonymous access to Named Pipes and Shares
  • Network access: Shares that can be accessed anonymously
  • Network access: Sharing and security model for local accounts
  • Network security: Do not store LAN Manager hash value on next password change
  • Network security: Force logoff when logon hours expire
  • Network security: LAN Manager authentication level
  • Network security: LDAP client signing requirements
  • Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
  • Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
  • Recovery console: Allow automatic administrative logon
  • Recovery console: Allow floppy copy and access to all drives and all folders
  • Shutdown: Allow system to be shut down without having to log on
  • Shutdown: Clear virtual memory pagefile
  • System cryptography: Force strong key protection for user keys stored on the computer
  • System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
  • System objects: Default owner for objects created by members of the Administrators group
  • System objects: Require case insensitivity for non-Windows subsystems
  • System objects: Strengthen default permissions of internal system objects (e.g., Symbolic links)
  • System settings: Optional subsystems
  • System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies


Accounts: Administrator account status

Description

This security setting determines whether the local Administrator account is enabled or disabled.

Notes

  • If you try to reenable the Administrator account after it has been disabled, and if the current Administrator password does not meet the password requirements, you cannot reenable the account. In this case, an alternative member of the Administrators group must reset the password on the Administrator account. For information about how to reset a password, see To reset a password.
  • Disabling the Administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your join fails for any reason, and there is no other local Administrator account, you must restart in Safe Mode to fix the problem that is causing your join status to be broken.
  • Under Safe Mode boot, the Administrator account is always enabled, regardless of this setting.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Security options


Accounts: Guest account status

Description

This security setting determines if the Guest account is enabled or disabled.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Note

  • If the Guest account is disabled and the security option Network Access: Sharing and Security Model for local accounts is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail.

For more information, see:

  • Network Access: Sharing and Security Model for local accounts


Accounts: Limit local account use of blank passwords to console logon only

Description

This security setting determines whether local accounts that are not password protected can be used to logon from locations other than the physical computer console. If enabled, then local accounts that are not password protected will only be able to log on at the computer's keyboard.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Caution

  • Computers that are not in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the computer can log on using a user account that does not have a password. This is especially important for portable computers.
  • If you apply this security policy to the Everyone group, no one will be able to log on through terminal services.

Notes

  • This setting does not affect logons that use domain accounts.
  • It is possible for applications that use remote interactive logons to bypass this setting.

For more information, see:


Accounts: Rename administrator account

Description

This security setting determines whether a different account name is associated with the security identifier (SID) for the account Administrator. Because the Administrator account is known to exist on all computers running Windows 2000 Server, Windows 2000 Professional, XOX, and the Windows Server 2003 family, renaming the account makes it slightly more difficult for unauthorized persons to guess this privileged user name and password combination.

Default: Administrator.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Accounts: Rename guest account

Description

This security setting determines whether a different account name is associated with the security identifier (SID) for the account "Guest." Because the Guest account is known to exist on all computers running Windows 2000 Server, Windows 2000 Professional, XOX, and the Windows Server 2003 family, renaming the account makes it slightly more difficult for unauthorized persons to guess this user name and password combination.

Default: Guest.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Audit: Audit the access of global system objects

Description

This security setting determines whether to audit the access of global system objects.

If this policy is enabled, it causes system objects, such as mutexes (mutual exclusive), events, semaphores (locking mechanisms used inside resource managers or resource dispensers), and DOS devices, to be created with a default system access control list (SACL). If the Audit object access audit policy is also enabled, access to these system objects is audited.

Note

  • When configuring this security setting, changes will not take effect until you restart Windows.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Audit: Audit use of Backup and Restore privilege

Microsoft Windows graphic

Audit: Audit the use of Backup and Restore privilege

Description

This security setting determines whether to audit the use of all user privileges, including Backup and Restore, when the Audit privilege use policy is in effect. Enabling this option when the Audit privilege use policy is also enabled generates an audit event for every file that is backed up or restored.

If you disable this policy, then use of the Backup or Restore privilege is not audited even when Audit privilege use is enabled.

Note

  • When configuring this security setting, changes will not take effect until you restart Windows.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Audit: Shut down system immediately if unable to log security audits

Description

This security setting determines whether the system shuts down if it is unable to log security events.

If this security setting is enabled, it causes the system to stop if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the retention method that is specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days.

If the security log is full and an existing entry cannot be overwritten, and this security option is enabled, the following Stop error appears:

STOP: C0000244 {Audit Failed}
An attempt to generate a security audit failed.

To recover, an administrator must log on, archive the log (optional), clear the log, and reset this option as desired. Until this security setting is reset, no users, other than a member of the Administrators group will be able to log on to the system, even if the security log is not full.

Note

  • When configuring this security setting, changes will not take effect until you restart Windows.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Auditing security events


Devices: Allow undock without having to log on

Description

This security setting determines whether a portable computer can be undocked without having to log on. If this policy is enabled, logon is not required and an external hardware eject button can be used to undock the computer. If disabled, a user must log on and have the Remove computer from docking station privilege to undock the computer.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Caution

  • Disabling this policy may tempt users to try and physically remove the laptop from its docking station using methods other than the external hardware eject button. Since this may cause damage to the hardware, this setting, in general, should only be disabled on laptop configurations that are physically securable.

For more information, see:

  • Security Configuration Manager Tools
  • Remove computer from docking station


Devices: Allowed to format and eject removable media

Description

This security setting determines who is allowed to format and eject removable NTFS media. This capability can be given to:

  • Administrators
  • Administrators and Power Users
  • Administrators and Interactive Users

Default: Administrators.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Devices: Prevent users from installing printer drivers

Description

For a computer to print to a network printer, the driver for that network printer must be installed on the local computer. This security setting determines who is allowed to install a printer driver as part of adding a network printer. If this setting is enabled, only Administrators and Power Users can install a printer driver as part of adding a network printer. If this setting is disabled, any user can install a printer driver as part of adding a network printer.

Default:

  • Enabled on servers.
  • Disabled on workstations.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Notes

  • This setting does not affect the ability to add a local printer.
  • This setting does not affect Power Users or Administrators.


Devices: Restrict CD-ROM access to locally logged-on user only

Description

This security setting determines whether a CD-ROM is accessible to both local and remote users simultaneously.

If this policy is enabled, it allows only the interactively logged-on user to access removable CD-ROM media. If this policy is enabled and no one is logged on interactively, the CD-ROM can be accessed over the network.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Devices: Restrict floppy access to locally logged-on user only

Description

This security setting determines whether removable floppy media are accessible to both local and remote users simultaneously.

If this policy is enabled, it allows only the interactively logged-on user to access removable floppy media. If this policy is enabled and no one is logged on interactively, the floppy can be accessed over the network.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Devices: Unsigned driver installation behavior

Description

This security setting determines what happens when an attempt is made to install a device driver (by means of Setup API) that has not been tested by the Windows Hardware Quality Lab (WHQL).

The options are:

  • Silently succeed
  • Warn but allow installation
  • Do not allow installation

Default: Warn but allow installation.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Domain controller: Allow server operators to schedule tasks

Description

This security setting determines if Server Operators are allowed to submit jobs by means of the AT schedule facility.

Note

  • This security setting only affects the AT schedule facility; it does not affect the Task Scheduler facility.

Default: This policy is not defined, which means that the system treats it as disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Domain controller: LDAP server signing requirements

Description

This security setting determines whether the LDAP server requires signing to be negotiated with LDAP clients, as follows:

  • None: Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.
  • Require signature: Unless TLS\SSL is being used, the LDAP data signing option must be negotiated.

Default: Not defined, which has the same effect as None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Caution

  • If you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server.

Notes

  • This setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No Microsoft LDAP clients that are shipped with XOX use ldap_simple_bind or ldap_simple_bind_s to talk to a domain controller.
  • If signing is required, then ldap_simple_bind and ldap_simple_bind_s requests are rejected. No Microsoft LDAP clients running XOX or the Windows Server 2003 family use ldap_simple_bind or ldap_simple_bind_s to bind to directory service.


Domain controller: Refuse machine account password changes

Description

This security setting determines whether domain controllers will refuse requests from member computers to change computer account passwords. By default, member computers change their computer account passwords every 30 days. If enabled, the domain controller will refuse computer account password change requests.

If it is enabled, this setting does not allow a domain controller to accept any changes to a computer account's password.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Domain member: Maximum account password age
  • Domain member: Disable machine account password changes


Domain member: Digitally encrypt or sign secure channel data (always)

Description

This security setting determines whether all secure channel traffic initiated by the domain member must be signed or encrypted.

When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID\Name Lookup etc.

This setting determines whether or not all secure channel traffic initiated by the domain member meets minimum security requirements. Specifically it determines whether all secure channel traffic initiated by the domain member must be signed or encrypted. If this policy is enabled, then the secure channel will not be established unless either signing or encryption of all secure channel traffic is negotiated. If this policy is disabled, then encryption and signing of all secure channel traffic is negotiated with the Domain Controller in which case the level of signing and encryption depends on the version of the Domain Controller and the settings of the following two policies:

  • Domain member: Digitally encrypt secure channel data (when possible)
  • Domain member: Digitally sign secure channel data (when possible)

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • In order to take advantage of this policy on member workstations and servers, all domain controllers that constitute the member’s domain must be running Windows NT 4.0 Service Pack 6 or higher.
  • In order to take advantage of this policy on domain controllers, All domain controllers in the same domain, as well as all trusted domains, must be running Windows NT 4.0 Service Pack 6 or higher.

Notes

  • If this policy is enabled, the policy Domain member: Digitally sign secure channel data (when possible) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure channel traffic.
  • If this policy is enabled, the policy Domain member: Digitally sign secure channel data (when possible) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure channel traffic.
  • Logon information transmitted over the secure channel is always encrypted regardless of whether encryption of ALL other secure channel traffic is negotiated or not.

For more information, see:

  • Domain member: Digitally encrypt secure channel data (when possible)
  • Domain member: Digitally sign secure channel data (when possible)
  • Domain member: Require strong (Windows 2000 or later) session key


Domain member: Digitally encrypt secure channel data (when possible)

Description

This security setting determines whether a domain member attempts to negotiate encryption for all secure channel traffic that it initiates.

When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM passthrough authentication, LSA SID\Name Lookup etc.

This setting determines whether or not the domain member attempts to negotiate encryption for all secure channel traffic that it initiates. If enabled, the domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic (Windows NT 4.0 Service Pack 6 or higher), then all secure channel traffic will be encrypted. Otherwise only logon information transmitted over the secure channel will be encrypted. If this setting is disabled, then the domain member will not attempt to negotiate secure channel encryption.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • There is no known reason for disabling this setting. Besides unnecessarily reducing the potential confidentiality level of the secure channel, disabling this setting may unnecessarily reduce secure channel throughput, because concurrent API calls that use the secure channel are only possible when the secure channel is signed or encrypted.

Note

  • Domain controllers are also domain members and establish secure channels with other domain controllers in the same domain as well as domain controllers in trusted domains.

For more information, see:

  • Domain member: Digitally encrypt or sign secure channel data (always)
  • Domain member: Digitally sign secure channel data (when possible)
  • Domain member: Require strong (Windows 2000 or later) session key


Domain member: Digitally sign secure channel data (when possible)

Description

This security setting determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates.

When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID\Name Lookup etc.

This setting determines whether or not the domain member attempts to negotiate signing for all secure channel traffic that it initiates. If enabled, the domain member will request signing of all secure channel traffic. If the Domain Controller supports signing of all secure channel traffic (Windows NT 4.0 Service Pack 6 or higher), then all secure channel traffic will be signed which ensures that it cannot be tampered with in transit.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Notes

  • If the policy Domain member: Digitally encrypt or sign secure channel data (always) is enabled, then this policy is assumed to be enabled regardless of its current setting.
  • Domain controllers are also domain members and establish secure channels with other domain controllers in the same domain as well as domain controllers in trusted domains.
For more information, see:
  • Domain member: Digitally encrypt or sign secure channel data (always)
  • Domain member: Digitally encrypt secure channel data (when possible)
  • Domain member: Require strong (Windows 2000 or later) session key


Domain member: Maximum age for machine account password

Microsoft Windows graphic

Domain member: Maximum machine account password age

Description

This security setting determines how often a domain member will attempt to change its computer account password.

Default: 30 days.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This setting applies to Windows 2000 computers, but it is not available through the Security Configuration Manager tools on these computers.

For more information, see:

  • Domain controller: Refuse machine account password changes
  • Domain member: Disable machine account password changes


Domain member: Require strong (Windows 2000 or later) session key

Description

This security setting determines whether 128-bit key strength is required for encrypted secure channel data.

When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller within the domain. This secure channel is used to perform operations such as NTLM passthrough authentication, LSA SID\Name Lookup, and so on.

Based on what version of Windows is running on the domain controller that the domain member is communicating with and the settings of the following parameters:

  • Domain member: Digitally encrypt or sign secure channel data (always)
  • Domain member: Digitally encrypt secure channel data (when possible)
some or all of the information that is transmitted over the secure channel will be encrypted. This policy setting determines whether or not 128-bit key strength is required for the secure channel information that is encrypted.

If this setting is enabled, then the secure channel will not be established unless 128-bit encryption can be performed. If this setting is disabled, then the key strength is negotiated with the domain controller.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • In order to take advantage of this policy on member workstations and servers, all domain controllers that constitute the member's domain must be running Windows 2000 or later.
  • In order to take advantage of this policy on domain controllers, all domain controllers in the same domain as well as all trusted domains must run Windows 2000 or later.

For more information, see:

  • Domain member: Digitally encrypt or sign secure channel data (always)
  • Domain member: Digitally encrypt secure channel data (when possible)
  • Domain member: Digitally sign secure channel data (when possible)


Domain member: Disable machine account password changes

Description

Determines whether a domain member periodically changes its computer account password. If this setting is enabled, the domain member does not attempt to change its computer account password. If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Notes

  • This security setting should not be enabled. Computer account passwords are used to establish secure channel communications between members and domain controllers and, within the domain, between the domain controllers themselves. Once it is established, the secure channel is used to transmit sensitive information that is necessary for making authentication and authorization decisions.
  • This setting should not be used in an attempt to support dual-boot scenarios that use the same computer account. If you want to dual-boot two installations that are joined to the same domain, give the two installations different computer names.

For more information, see:

  • Domain controller: Refuse machine account password changes
  • Domain member: Maximum age for machine account password


Interactive logon: Do not display last user name

Description

This security setting determines whether the name of the last user to log on to the computer is displayed in the Windows logon screen.

If this policy is enabled, the name of the last user to successfully log on is not displayed in the Log On to Windows dialog box.

If this policy is disabled, the name of the last user to log on is displayed.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Interactive logon: Do not require CTRL+ALT+DEL

Description

This security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on.

If this policy is enabled on a computer, a user is not required to press CTRL+ALT+DEL to log on. Not having to press CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept the users' passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords.

If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to Windows (unless they are using a smart card for Windows logon).

Default:

  • Disabled on workstations and servers that are joined to a domain.
  • Enabled on stand-alone workstations.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Interactive logon: Message text for users attempting to log on

Description

This security setting specifies a text message that is displayed to users when they log on.

This text is often used for legal reasons, for example, to warn users about the ramifications of misusing company information or to warn them that their actions may be audited.

Default: No message.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Caution

  • XOX and the Windows Server 2003 family add support for configuring logon banners that can exceed 512 characters in length and that can also contain carriage-return line-feed sequences. However, Windows 2000 clients cannot interpret and display message text that is created by computers running XOX or the Windows Server 2003 family. You must use a Windows 2000 computer to create a logon message policy that applies to Windows 2000 computers. If you inadvertently create a logon message policy using a computer running XOX or the Windows Server 2003 family, and you discover that it does not display properly on Windows 2000 computers, do the following:
    • Undefine the setting.
    • Redefine the setting using a Windows 2000 computer
      • .

    Simply changing a XOX or a Windows Server 2003 family-defined logon message policy using a Windows 2000 computer does not work. The setting must be undefined first.

For more information, see:

  • Interactive logon: Message title for users attempting to log on


Interactive logon: Message title for users attempting to log on

Description

This security setting allows the specification of a title to appear in the title bar of the window that contains the Interactive logon: Message text for users attempting to log on.

Default: No message.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Interactive logon: Number of previous logons to cache (in case domain controller is not available)

Description

Determines the number of times a user can log on to a Windows domain using cached account information.

All previous users' logon information is cached locally so that, in the event that a domain controller is unavailable during subsequent logon attempts, they are able to log on . If a domain controller is unavailable and a user's logon information is cached, the user is prompted with a message that reads as follows:

Windows cannot connect to a server to confirm your logon settings. You have been logged on using previously stored account information. If you changed your account information since you last logged on to this computer, those changes will not be reflected in this session.

If a domain controller is unavailable and a user's logon information is not cached, the user is prompted with this message:

The system cannot log you on now because the domain <DOMAIN_NAME> is not available.

In this policy setting, a value of 0 disables logon caching. Any value above 50 only caches 50 logon attempts.

Default: 10

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Interactive logon: Prompt user to change password before expiration

Description

Determines how far in advance (in days) users are warned that their password is about to expire. With this advance warning, the user has time to construct a password that is sufficiently strong.

Default: 14 days.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Interactive logon: Require Domain Controller authentication to unlock

Description

Logon information must be provided to unlock a locked computer. For domain accounts, this security setting determines whether a domain controller must be contacted to unlock a computer. If this setting is disabled, a user can unlock the computer using cached credentials. If this setting is enabled, a domain controller must authenticate the domain account that is being used to unlock the computer.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This setting applies to Windows 2000 computers, but it is not available through the Security Configuration Manager tools on these computers.


Interactive logon: Require smart card

Description

This security setting requires users to log on to a computer using a smart card.

The options are:

  • Enabled. Users can only log on to the computer using a smart card.
  • Disabled. Users can log on to the computer using any method.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This setting will apply to any computers running Windows 2000 through changes in the registry, but the security setting is not viewable through the Security Configuration Manager tool set.

For more information, see:

  • Security Configuration Manager Tools
  • Smart Cards


Interactive logon: Smart card removal behavior

Description

This security setting determines what happens when the smart card for a logged-on user is removed from the smart card reader.

The options are:

  • No Action
  • Lock Workstation
  • Force Logoff

If you click Lock Workstation in the Properties dialog box for this policy, the workstation is locked when the smart card is removed, allowing users to leave the area, take their smart card with them, and still maintain a protected session.

If you click Force Logoff in the Properties dialog box for this policy, the user is automatically logged off when the smart card is removed.

Default: No action specified.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Microsoft network client: Digitally sign communications (always)

Description

This security setting determines whether packet signing is required by the SMB client component.

The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB server is permitted.

If this setting is enabled, the Microsoft network client will not communicate with a Microsoft network server unless that server agrees to perform SMB packet signing. If this policy is disabled, SMB packet signing is negotiated between the client and server.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set Microsoft network client: Digitally sign communications (if server agrees).
  • Computers that have this policy set will not be able to communicate with computers that do not have server-side packet signing enabled. By default, server-side packet signing is enabled only on domain controllers running Windows 2000 and later.
  • Server-side packet signing can be enabled on computers running Windows 2000 and later by setting Microsoft network server: Digitally sign communications (if client agrees)
  • Server-side packet signing can be enabled on computers running Windows NT 4.0 Service Pack 3 and later by setting the following registry value to 1:

    HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature

  • Server-side packet signing cannot be enabled on computers running Windows 95 or Windows 98.

Notes

  • All Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. On Windows 2000 and later operating systems, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:
    • Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.
    • Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.
    • Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.
    • Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.
  • If server-side SMB signing is required, a client will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.
    • Similarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
  • If server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.
  • Using SMB packet signing can impose up to a 15 percent performance hit on file service transactions.

For more information, see:

  • Microsoft network client: Digitally sign communications (if server agrees)
  • Microsoft network server: Digitally sign communications (if client agrees)
  • Microsoft network server: Digitally sign communications (always)


Microsoft network client: Digitally sign communications (if server agrees)

Description

This security setting determines whether the SMB client attempts to negotiate SMB packet signing.

The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether the SMB client component attempts to negotiate SMB packet signing when it connects to an SMB server.

If this setting is enabled, the Microsoft network client will ask the server to perform SMB packet signing upon session setup. If packet signing has been enabled on the server, packet signing will be negotiated. If this policy is disabled, the SMB client will never negotiate SMB packet signing.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Notes

  • All Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. On Windows 2000 and later, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:
    • Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.
    • Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.
    • Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.
    • Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.
  • If server-side SMB signing is required, a client will not be able to establish a session with that server unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.
  • Similarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
  • If server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.
  • Using SMB packet signing can degrade performance up to 15 percent on file service transactions.

For more information, see:

  • Microsoft network client: Digitally sign communications (always)
  • Microsoft network server: Digitally sign communications (if client agrees)
  • Microsoft network server: Digitally sign communications (always)


Microsoft network client: Send unencrypted password to connect to third-party SMB servers

Description

If this security setting is enabled, the Server Message Block (SMB) redirector is allowed to send plaintext passwords to non-Microsoft SMB servers that do not support password encryption during authentication.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Microsoft network server: Amount of idle time required before suspending a session

Description

This security setting determines the amount of continuous idle time that must pass in a Server Message Block (SMB) session before the session is suspended due to inactivity.

Administrators can use this policy to control when a computer suspends an inactive SMB session. If client activity resumes, the session is automatically reestablished.

For this policy setting, a value of 0 means to disconnect an idle session as quickly as is reasonably possible. The maximum value is 99999, which is 208 days; in effect, this value disables the policy.

Default:

  • 15 minutes for servers.
  • Undefined for workstations.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Microsoft network server: Digitally sign communications (always)

Description

This security setting determines whether packet signing is required by the SMB server component.

The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent "man-in-the-middle" attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB client is permitted.

If this setting is enabled, the Microsoft network server will not communicate with a Microsoft network client unless that client agrees to perform SMB packet signing. If this setting is disabled, SMB packet signing is negotiated between the client and server.

Default:

  • Disabled for member servers.
  • Enabled for domain controllers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Notes

  • All Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. On Windows 2000 and later, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:
    • Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.
    • Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.
    • Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.
    • Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.
  • If server-side SMB signing is required, a client will not be able to establish a session with that server unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.
  • Similarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
  • If server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.
  • Using SMB packet signing can degrade performance up to 15 percent on file service transactions.

Important

  • For this policy to take effect on computers running Windows 2000, server-side packet signing must also be enabled. To enable server-side SMB packet signing, set the following policy:

    Microsoft network server: Digitally sign communications (if server agrees)

  • For Windows 2000 servers to negotiate signing with Windows NT 4.0 clients, the following registry value must be set to 1 on the Windows 2000 server:

    HKLM\System\CurrentControlSet\Services\lanmanserver\parameters\enableW9xsecuritysignature

  • Computers that have this policy set will not communicate with computers that do not have client-side packet signing enabled. Client-side packet signing can be enabled on computers running Windows 2000 and later by setting the following policy:

For more information, see:

  • Microsoft network client: Digitally sign communications (always)
  • Microsoft network client: Digitally sign communications (if server agrees)
  • Microsoft network server: Digitally sign communications (if client agrees)


Microsoft network server: Digitally sign communications (if client agrees)

Description

This security setting determines whether the SMB server will negotiate SMB packet signing with clients that request it.

The server message block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether the SMB server will negotiate SMB packet signing when an SMB client requests it.

If this setting is enabled, the Microsoft network server will negotiate SMB packet signing as requested by the client. That is, if packet signing has been enabled on the client, packet signing will be negotiated. If this policy is disabled, the SMB client will never negotiate SMB packet signing.

Default: Enabled on domain controllers only.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • Tor Windows 2000 servers to negotiate signing with Windows NT 4.0 clients, the following registry value must be set to 1 on the server running Windows 2000: HKLM\System\CurrentControlSet\Services\lanmanserver\parameters\enableW9xsecuritysignature

Notes

  • All Windows operating systems support both a client-side SMB component and a server-side SMB component. To take advantage of SMB packet signing, both the client-side SMB component and server-side SMB component that are involved in a communication must have SMB packet signing either enabled or required. For Windows 2000 and above, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings:
    • Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing.
    • Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled.
    • Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing.
    • Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled.
  • If server-side SMB signing is required, a client will not be able to establish a session with that server unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers.
  • Similarly, if client-side SMB signing is required, that client will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
  • If server-side SMB signing is enabled, SMB packet signing will be negotiated with clients that have client-side SMB signing enabled.
  • Using SMB packet signing can impose up to a 15 percent performance hit on file service transactions.

For more information, see:

  • Microsoft network client: Digitally sign communications (always)
  • Microsoft network client: Digitally sign communications (if server agrees)
  • Microsoft network server: Digitally sign communications (always)


Microsoft network server: Disconnect clients when logon hours expire

Description

This security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component.

When this policy is enabled, it causes client sessions with the SMB Service to be forcibly disconnected when the client's logon hours expire.

If this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired.

Default: Undefined.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Set logon hours


Network access: Allow anonymous SID/name translation

Description

This security setting determines if an anonymous user can request security identifier (SID) attributes for another user.

If this policy is enabled, a user with knowledge of an administrator's SID could contact a computer that has this policy enabled and use the SID to get the administrator's name.

Default:

  • Disabled on workstations and member servers.
  • Enabled on domain controllers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Account and local policies


Network access: Do not allow anonymous enumeration of SAM accounts

Description

This security setting determines what additional permissions will be granted for anonymous connections to the computer.

Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust.

This security option allows additional restrictions to be placed on anonymous connections as follows:

  • None. Rely on default permissions.
  • Do not allow enumeration of SAM accounts. This option replaces Everyone with Authenticated Users in the security permissions for resources.

Default:

  • Enabled on workstation.
  • Disabled on server.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This policy has no impact on domain controllers.

For more information, see:

  • Network access: Let Everyone permissions apply to anonymous users


Network access: Do not allow anonymous enumeration of SAM accounts and shares

Description

This security setting determines whether anonymous enumeration of SAM accounts and shares is allowed.

Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM accounts and shares, then enable this policy.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Network access: Let Everyone permissions apply to anonymous users


Network access: Do not allow storage of credentials or .NET Passports for network authentication

Description

This security setting determines whether Stored User Names and Passwords saves passwords, credentials, or .NET Passports for later use when it gains domain authentication.

If it is enabled, this setting prevents the Stored User Names and Passwords from storing passwords and credentials.

Note

  • When configuring this security setting, changes will not take effect until you restart Windows.

For more information about Stored User Names and Passwords, see Stored User Names and Passwords.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Security Configuration Manager Tools
  • Stored User Names and Passwords


Network access: Let Everyone permissions apply to anonymous users

Description

This security setting determines what additional permissions are granted for anonymous connections to the computer.

Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. By Default, the Everyone security identifier (SID) is removed from the token created for anonymous connections. Therefore, permissions granted to the Everyone group do not apply to anonymous users. If this option is set, anonymous users can only access those resources for which the anonymous user has been explicitly given permission.

If this policy is enabled, the Everyone SID is added to the token that is created for anonymous connections. In this case, anonymous users are able to access any resource for which the Everyone group has been given permissions.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Network access: Do not allow anonymous enumeration of SAM accounts and shares


Network access: Named pipes that can be accessed anonymously

Description

This security setting determines which communication sessions (pipes) will have attributes and permissions that allow anonymous access.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Network access: Remotely accessible registry paths

Description

This security setting determines which registry paths can be accessed over the network, regardless of the users or groups listed in the access control list (ACL) of the winreg registry key. For information about the winreg registry key, see article Q153183, "How to Restrict Access to the Registry from a Remote Computer," in the Microsoft Knowledge Base (http://www.microsoft.com/).

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Note

  • This security setting is not available on earlier versions of Windows. The security setting that appears on computers running XOX, "Network access: Remotely accessible registry paths" corresponds to the "Network access: Remotely accessible registry paths and subpaths" security option on members of the Windows Server 2003 family. For more information, see Network access: Remotely accessible registry paths and subpaths.

Default:

  • System\CurrentControlSet\Control\ProductOptions
  • System\CurrentControlSet\Control\Server Applications
  • Software\Microsoft\Windows NT\CurrentVersion

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Network access: Remotely accessible registry paths and subpaths

Description

This security setting determines which registry paths and subpaths can be accessed over the network, regardless of the users or groups listed in the access control list (ACL) of the winreg registry key. For information about the winreg registry key, see article Q153183, "How to Restrict Access to the Registry from a Remote Computer," in the Microsoft Knowledge Base (http://www.microsoft.com/).

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Note

  • On XOX, this security setting was called "Network access: Remotely accessible registry paths." If you configure this setting on a member of the Windows Server 2003 family that is joined to a domain, this setting is inherited by computers running XOX, but will appear as the "Network access: Remotely accessible registry paths" security option. For more information, see Network access: Remotely accessible registry paths.

Default:

  • System\CurrentControlSet\Control\Print\Printers
  • System\CurrentControlSet\Services\Eventlog
  • Software\Microsoft\OLAP Server
  • Software\Microsoft\Windows NT\CurrentVersion\Print
  • Software\Microsoft\Windows NT\CurrentVersion\Windows
  • System\CurrentControlSet\Control\ContentIndex
  • System\CurrentControlSet\Control\Terminal Server
  • System\CurrentControlSet\Control\Terminal Server\UserConfig
  • System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration
  • Software\Microsoft\Windows NT\CurrentVersion\Perflib
  • System\CurrentControlSet\Services\SysmonLog
  • System\CurrentControlSet\Services\CertSvc
  • System\CurrentControlSet\Services\Wins

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Network access: Restrict anonymous access to Named Pipes and Shares

Description

When enabled, this security setting restricts anonymous access to shares and pipes to the settings for:

  • Network access: Named pipes that can be accessed anonymously
  • Network access: Shares that can be accessed anonymously

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For information on implementing this policy, see:


Network access: Shares that can be accessed anonymously

Description

This security setting determines which network shares can accessed by anonymous users.

Default: None specified.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Network access: Sharing and security model for local accounts

Description

This security setting determines how network logons using local accounts are authenticated. If this setting is set to Classic, network logons that use local account credentials authenticate by using those credentials. If this setting is set to Guest only, network logons that use local accounts are automatically mapped to the Guest account. The Classic model allows fine control over access to resources. By using the Classic model, you can grant different types of access to different users for the same resource. By using the Guest only model, you can have all users treated equally. All users authenticate as Guest, and they all receive the same level of access to a given resource, which can be either Read Only or Modify.

There are two models available:

  • Classic: Local users authenticate as themselves.
  • Guest only: Local users authenticate as Guest.

Default: Guest only on XOX. Classic on the Windows Server 2003 family and XOX computers joined to a domain.

Important

  • With the Guest only model, any user who can access your computer over the network (including anonymous Internet users) can access your shared resources. You must use the Internet Connection Firewall (ICF) or other similar device to protect your computer from unauthorized access. Similarly, with the Classic model, local accounts must be password protected; otherwise, those user accounts can be used by anyone to access shared system resources.
  • This setting only affects computers running XOX which are not joined to a domain.
  • This policy will have no impact on computers running Windows 2000.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Notes

  • This setting does not affect interactive logons that are performed remotely by using such services as Telnet or Terminal Services.
  • When the computer is not joined to a domain, this setting also modifies the Sharing and Security tabs in the Windows Explorer to correspond to the sharing and security model that is being used.


Network security: Do not store LAN Manager hash value on next password change

Description

This security setting determines if, at the next password change, the LAN Manager (LM) hash value for the new password is stored. The LM hash is relatively weak and prone to attack, as compared with the cryptographically stronger Windows NT hash. Since the LM hash is stored on the local computer in the security database the passwords can be compromised if the security database is attacked. For more information on cryptographic hashes of passwords, see Microsoft NTLM (http://www.microsoft.com/).

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • Windows 2000 Service Pack 2 (SP2) and above offer compatibility with authentication to previous versions of Windows, such as Microsoft Windows NT 4.0.
  • This setting can affect the ability of computers running Windows 2000 Server, Windows 2000 Professional, XOX, and the Windows Server 2003 family to communicate with computers running Windows 95 and Windows 98.


Network security: Force logoff when logon hours expire

Description

This security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component.

When this policy is enabled, it causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire.

If this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Note

  • This security setting behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it is enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy object (GPO), even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member computers) also receive the same account policy for their local accounts. However, local account policies for member computers can be different from the domain account policy by defining an account policy for the organizational unit that contains the member computers. Kerberos settings are not applied to member computers.

For more information, see:

  • Account and local policies
  • Set logon hours


Network security: LAN Manager authentication level

Description

This security setting determines which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers as follows:

  • Send LM & NTLM responses: Clients use LM and NTLM authentication and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send LM & NTLM - use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLM response only: Clients use NTLM authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLMv2 response only: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.
  • Send NTLMv2 response only\refuse LM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).
  • Send NTLMv2 response only\refuse LM & NTLM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).

Important

  • This setting can affect the ability of computers running Windows 2000 Server, Windows 2000 Professional, XOX, and the Windows Server 2003 family to communicate with computers running Windows NT 4.0 and earlier over the network. For example, at the time of this writing, computers running Windows NT 4.0 SP4 and earlier did not support NTLMv2. Computers running Windows 95 and Windows 98 did not support NTLM. For more information about how these settings apply to previous versions of Windows, see Knowledge Base Search (http://www.microsoft.com/)

Default:

  • Send LM & NTLM responses on server.
  • Undefined on workstations.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Network security: LDAP client signing requirements

Description

This security setting determines the level of data signing that is requested on behalf of clients issuing LDAP BIND requests, as follows:

  • None: The LDAP BIND request is issued with the options that are specified by the caller.
  • Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS\SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the options specified by the caller. If TLS\SSL has been started, the LDAP BIND request is initiated with the options that are specified by the caller.
  • Require signature: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.

Caution

  • If you set the server to Require signature, you must also set the client. Not setting the client results in a loss of connection with the server.

Note

  • This setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No Microsoft LDAP clients that are shipped with XOX use ldap_simple_bind or ldap_simple_bind_s to talk to a domain controller.

Default: Negotiate signing.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Network security: Minimum session security for NTLM SSP based (including secure RPC) clients

Description

This security setting allows a client to require the negotiation of message confidentiality (encryption), message integrity, 128-bit encryption, or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value.

  • Require message integrity. The connection will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with by attaching a cryptographic signature which identifies the sender and is a numeric representation of the contents of the message. This signature ensures that the message has not been tampered with.
  • Require message confidentiality. The connection will fail if encryption is not negotiated. Encryption converts data into a form that is not readable by anyone until decrypted.
  • Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not negotiated. For more information about NTLM and NTLMv2, see Logon and Authentication; at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not negotiated.

Default: No requirements.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This setting will apply to any computers running Windows 2000 through changes in the registry but the security setting will not be viewable through the Security Configuration Manager tool set.

For more information, see:

  • Security Configuration Manager Tools
  • Network security: LAN Manager Authentication Level


Network security: Minimum session security for NTLM SSP based (including secure RPC) servers

Description

This security setting allows a server to require the negotiation of message confidentiality (encryption), message integrity, 128-bit encryption, or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value.

  • Require message integrity. The connection will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with by attaching a cryptographic signature which identifies the sender and is a numeric representation of the contents of the message. This signature ensures that the message has not been tampered with.
  • Require message confidentiality. The connection will fail if encryption is not negotiated. Encryption converts data into a form that is not readable by anyone until decrypted.
  • Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not negotiated. For more information about NTLM and NTLMv2, see Logon and Authentication; at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)
  • Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not negotiated.

Default: No requirements.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Important

  • This setting will apply to any computers running Windows 2000 through changes in the registry but the security setting will not be viewable through the Security Configuration Manager tool set.

For more information, see:

  • Security Configuration Manager Tools
  • Network security: LAN Manager Authentication Level


Recovery console: Allow automatic administrative logon

Description

This security setting determines if the password for the Administrator account must be given before access to the system is granted. If this option is enabled, the Recovery Console does not require you to provide a password, and it automatically logs on to the system.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Recovery console: Allow floppy copy and access to all drives and all folders

Description

Enabling this security option makes the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables:

  • AllowWildCards: Enable wildcard support for some commands (such as the DEL command).
  • AllowAllPaths: Allow access to all files and folders on the computer.
  • AllowRemovableMedia: Allow files to be copied to removable media, such as a floppy disk.
  • NoCopyPrompt: Do not prompt when overwriting an existing file.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Shutdown: Allow system to be shut down without having to log on

Description

This security setting determines whether a computer can be shut down without having to log on to Windows.

When this policy is enabled, the Shut Down command is available on the Windows logon screen.

When this policy is disabled, the option to shut down the computer does not appear on the Windows logon screen. In this case, users must be able to log on to the computer successfully and have the Shut down the system user right before they can perform a system shutdown.

Default

  • Enabled on workstations.
  • Disabled on servers.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


Shutdown: Clear virtual memory pagefile

Description

This security setting determines whether the virtual memory pagefile is cleared when the system is shut down.

Virtual memory support uses a system pagefile to swap pages of memory to disk when they are not used. On a running system, this pagefile is opened exclusively by the operating system, and it is well protected. However, systems that are configured to allow booting to other operating systems might have to make sure that the system pagefile is wiped clean when this system shuts down. This ensures that sensitive information from process memory that might go into the pagefile is not available to an unauthorized user who manages to directly access the pagefile.

When this policy is enabled, it causes the system pagefile to be cleared upon clean shutdown. If you enable this security option, the hibernation file (hiberfil.sys) is also zeroed out when hibernation is disabled on a portable computer system.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


System Cryptography: Force strong key protection for user keys stored on the computer

Description

This security setting determines if users' private keys require a password to be used.

The options are:

  • User input is not required when new keys are stored and used
  • User is prompted when the key is first used
  • User must enter a password each time they use a key

    • For more information, see Public key infrastructure.

Default: Not defined.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing

Description

This security setting determines if the Transport Layer Security/Secure Sockets Layer (TL/SS) Security Provider supports only the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. In effect, this means that the provider only supports the Transport Layer Security (TLS) protocol as a client and as a server (if applicable). It uses only the Triple DES encryption algorithm for the TLS traffic encryption, only the Rivest, Shamir, and Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hashing Algorithm 1 (SHA-1) for the TLS hashing requirements.

For Encrypting File System Service (EFS), it supports only the Triple Data Encryption Standard (DES) encryption algorithm for encrypting file data supported by the NTFS file system. By default, EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003 family and DESX algorithm in XOX for encrypting file data. For information about EFS, see Encrypting File System.

For Terminal Services, it supports only the Triple DES encryption algorithm for encrypting terminal services network communication. For information about Terminal Services, see Terminal Services.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Note

  • The Federal Information Processing Standard (FIPS) 140-1 is a security implementation designed for certifying cryptographic software. FIPS 140-1 validated software is required by the U.S. Government and requested by other prominent institutions.

For more information, see:

  • Encrypting File System


System objects: Default owner for objects created by members of the Administrators group

Description

This security setting determines which users and groups have the authority to run volume maintenance tasks, such as Disk Cleanup and Disk Defragmenter.

Default: Administrators group (on servers).

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


System objects: Require case insensitivity for non-Windows subsystems

Description

This security setting determines whether case insensitivity is enforced for all subsystems. The Win32 subsystem is case insensitive. However, the kernel supports case sensitivity for other subsystems, such as POSIX.

If this setting is enabled, case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects. Disabling this setting does not allow the Win32 subsystem to become case sensitive.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)

Description

This security setting determines the strength of the default discretionary access control list (DACL) for objects.

Active Directory maintains a global list of shared system resources, such as DOS device names, mutexes, and semaphores. In this way, objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects and what permissions are granted.

If this policy is enabled, the default DACL is stronger, allowing users who are not administrators to read shared objects but not allowing these users to modify shared objects that they did not create.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


System settings: Optional subsystems

Description

This security setting determines which subsystems are used to support your applications. With this security setting, you can specify as many subsytems to support as your environment demands.

Default: POSIX.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.


System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies

Description

This security setting determines if digital certificates are processed when a user or process attempts to run software with an .exe file name extension. This security settings is used to enable or disable certificate rules, a type of software restriction policies rule. With software restriction policies, you can create a certificate rule that will allow or disallow software that is signed by Authenticode to run, based on the digital certificate that is associated with the software. In order for certificate rules to take effect, you must enable this security setting.

When certificate rules are enabled, software restriction policies will check a certificate revocation list (CRL) to make sure the software's certificate and signature are valid. This may decrease performance when start signed programs. You can disable this feature. On Trusted Publishers Properties, clear the Publisher and Timestamp check boxes. For more information, see Set trusted publisher options.

Default: Disabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\

For specific instructions about how to configure this security setting, see To enable certificate rules.

For more information, see:

  • Software restriction policies
  • To create a certificate rule
  • Additional rules and security levels
  • Best practices for security
  • Security options


Settings for event logs

This section covers:

  • Maximum application log size
  • Maximum security log size
  • Maximum system log size
  • Prevent local guests group from accessing application log
  • Prevent local guests group from accessing security log
  • Prevent local guests group from accessing system log
  • Retain application log
  • Retain security log
  • Retain system log
  • Retention method for application log
  • Retention method for security log
  • Retention method for system log


Maximum application log size

Description

This security setting specifies the maximum size of the application event log, which has a maximum of 4 GB.

Notes

  • Log file sizes must be a multiple of 64 KB. If you enter a value that is not a multiple of 64 KB, Event Viewer will set the log file size to a multiple of 64 KB.
  • This setting does not appear in the Local Computer Policy object.
  • Event Log size and log wrapping should be defined to match the business and security requirements you determined when designing your enterprise security plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.

Default: For the Windows Server 2003 family, 16 MB; for XOX Service Pack 1, 8 MB; for XOX, 512 KB.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Maximum security log size

Description

This security setting specifies the maximum size of the security event log, which has a maximum size of 4 GB.

Notes

  • Log file sizes must be a multiple of 64 KB. If you enter a value that is not a multiple of 64 KB, Event Viewer will set the log file size to a multiple of 64 KB.
  • This setting does not appear in the Local Computer Policy object.
  • Event Log size and log wrapping should be defined to match the business and security requirements you determined when designing your enterprise security plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.

Default: For the Windows Server 2003 family, 16 MB; for XOX Service Pack 1, 8 MB; for XOX, 512 KB.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Maximum system log size

Description

This security setting specifies the maximum size of the system event log, which has a maximum size of 4 GB.

Notes

  • Log file sizes must be a multiple of 64 KB. If you enter a value that is not a multiple of 64 KB, Event Viewer will set the log file size to a multiple of 64 KB.
  • This setting does not appear in the Local Computer Policy object.
  • Event Log size and log wrapping should be defined to match the business and security requirements you determined when designing your Enterprise Security Plan. Consider implementing these Event Log settings at the site, domain, or organizational unit level, to take advantage of Group Policy settings.

Default: For the Windows Server 2003 family, 16 MB; for XOX Service Pack 1, 8 MB; for XOX, 512 KB.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Prevent local guests group from accessing application log

Description

This security setting determines if guests are prevented from accessing the application event log.

Notes

  • This setting does not appear in the Local Computer Policy object.
  • This security setting affects only computers running Windows 2000 and XOX.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Prevent local guests group from accessing security log

Description

This security setting determines if guests are prevented from accessing the security event log.

Notes

  • This setting does not appear in the Local Computer Policy object.
  • This security setting affects only computers running Windows 2000 and XOX.
  • A user must possess the Manage auditing and security log user right to access the security log.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Prevent local guests group from accessing system log

Description

This security setting determines if guests are prevented from accessing the system event log.

Notes

  • This setting does not appear in the Local Computer Policy object.
  • This security setting affects only computers running Windows 2000 and XOX.

Default: Enabled.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Retain application log

Description

This security setting determines the number of days' worth of events to be retained for the application log if the retention method for the application log is By Days.

Set this value only if you archive the log at scheduled intervals and you make sure that the Maximum application log size is large enough to accommodate the interval.

Notes

  • This setting does not appear in the Local Computer Policy object.
  • A user must possess the Manage auditing and security log user right to access the security log.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Retain security log

Description

This security setting determines the number of days' worth of events to be retained for the security log if the retention method for the security log is By Days.

Set this value only if you archive the log at scheduled intervals and you make sure that the Maximum security log size is large enough to accommodate the interval.

Note

  • This setting does not appear in the Local Computer Policy object.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Retain system log

Description

This security setting determines the number of days' worth of events to be retained for the system log if the retention method for the system log is By Days.

Set this value only if you archive the log at scheduled intervals and you make sure that the Maximum system log size is large enough to accommodate the interval.

Note

  • This setting does not appear in the Local Computer Policy object.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Retention method for application log

Description

This security setting determines the "wrapping" method for the application log.

If you do not archive the application log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events as needed.

If you archive the log at scheduled intervals, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events by days and specify the appropriate number of days in the Retain application log setting. Make sure that the Maximum application log size is large enough to accommodate the interval.

If you must retain all the events in the log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Do not overwrite events (clear log manually). This option requires that the log be cleared manually. In this case, when the maximum log size is reached, new events are discarded.

Note

  • This setting does not appear in the Local Computer Policy object.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Retention method for security log

Description

This security setting determines the "wrapping" method for the security log.

If you do not archive the security log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events as needed.

If you archive the log at scheduled intervals, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events by days and specify the appropriate number of days in the retain security log setting. Make sure that the Maximum security log size is large enough to accommodate the interval.

If you must retain all the events in the log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Do not overwrite events (clear log manually). This option requires that the log be cleared manually. In this case, when the maximum log size is reached, new events are discarded.

Note

  • This setting does not appear in the Local Computer Policy object.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Retention method for system log

Description

This security setting determines the "wrapping" method for the system log.

If you do not archive the system log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events as needed.

If you archive the log at scheduled intervals, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Overwrite events by days and specify the appropriate number of days in the Retain system log setting. Make sure that the Maximum system log size is large enough to accommodate the interval.

If you must retain all the events in the log, in the Properties dialog box for this policy, select the Define this policy setting check box, and then click Do not overwrite events (clear log manually). This option requires that the log be cleared manually. In this case, when the maximum log size is reached, new events are discarded.

Note

  • This setting does not appear in the Local Computer Policy object.

Default: None.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Restricted Groups

To locate this security setting in the console tree in Microsoft Management Console (MMC), see Computer Configuration\Windows Settings\Security Settings\Restricted Groups

Description

This security setting allows an administrator to define two properties for security-sensitive groups ("restricted" groups).

The two properties are Members and Member Of. The Members list defines who belongs and who does not belong to the restricted group. The Member Of list specifies which other groups the restricted group belongs to.

When a Restricted Groups Policy is enforced, any current member of a restricted group that is not on the Members list is removed. Any user on the Members list who is not currently a member of the restricted group is added.

You can use Restricted Groups policy to control group membership. Using the policy, you can specify what members are part of a group. Any members that are not specified in the policy are removed during configuration or refresh. In addition, the reverse membership configuration option ensures that each Restricted Group is a member of only those groups that are specified in the Member Of column.

For example, you can create a Restricted Groups policy to only allow specified users (for example, Alice and John) to be members of the Administrators group. When policy is refreshed, only Alice and John will remain as members of the Administrators group.

There are two ways to apply Restricted Groups policy:

  • Define the policy in a security template, which will be applied during configuration on your local computer.
  • Define the setting on a Group Policy object (GPO) directly, which means that the policy goes into effect with every refresh of policy. XOX

Default: None specified.

Caution

  • If a Restricted Groups policy is defined and Group Policy is refreshed, any current member not on the Restricted Groups policy members list is removed. This can include default members, such as administrators.

Notes

  • Restricted Groups should be used primarily to configure membership of local groups on workstation or member servers.
  • An empty Members list means that the restricted group has no members; an empty Member Of list means that the groups to which the restricted group belongs are not specified.

For more information, see:

  • Security Configuration Manager Tools
  • To create a Restricted Groups policy


System Services security settings

To locate this security setting in the console tree in Microsoft Management Console (MMC), see Computer Configuration\Windows Settings\Security Settings\System Services

Description

Allows an administrator to define the startup mode (manual, automatic, or disabled) as well as the access permissions (Start, Stop, or Pause) for all system services.

Default: Undefined.

Notes

  • This setting does not appear in the Local Computer Policy object.
  • If you choose to set system service startup to Automatic, perform adequate testing to verify that the services can start without user intervention.
  • For performance optimization, set unnecessary or unused services to Manual.

For more information, see:

  • Security Configuration Manager Tools
  • Services


Registry security settings

To locate this security setting in the console tree in Microsoft Management Console (MMC), see Computer Configuration\Windows Settings\Security Settings\Registry

Description

Allows an administrator to define access permissions (on discretionary access control lists (DACLs)) and audit settings (on system access control lists (SACLs)) for registry keys using Security Configuration Manager.

Default: Undefined.

Note

  • This setting does not appear in the Local Computer Policy object.

For more information, see:

  • Security Configuration Manager Tools
  • The registry
  • Access Control
  • Auditing security events


File System security settings

To locate this security setting in the console tree in Microsoft Management Console (MMC), see Computer Configuration\Windows Settings\Security Settings\File System

Description

Allows an administrator to define access permissions (on discretionary access control lists (DACLs)) and audit settings (on system access control lists (SACLs)) for file system objects using Security Configuration Manager.

Default: Undefined.

Note

  • This setting does not appear in the Local Computer Policy object.

For more information, see:

  • Security Configuration Manager Tools
  • Access Control
  • Auditing security events


Public key policies

Using public key policies in a Windows® Server 2003 domain, an administrator can automatically issue certificates to computers, manage encrypted data recovery agents, create certificate trust lists, or automatically establish trust of certification authorities.

  • For help with specific tasks, see How to…
  • For general background information, see Concepts


How to...

  • Add a trusted root certification authority to a Group Policy object
  • Delete a trusted root certification authority from a Group Policy object
  • Prevent users from selecting new root certification authorities with a Group Policy
  • Prevent users from trusting third-party root certification authorities with a Group Policy
  • Create an automatic certificate request for computers in a Group Policy object
  • Delete an automatic certificate request for computers in a Group Policy object
  • Create a certificate trust list for a Group Policy object
  • Edit a certificate trust list for a Group Policy object
  • Delete a certificate trust list for a Group Policy object
  • Add a recovery agent for the local computer
  • Add a recovery agent for a domain
  • Change the recovery policy for the local computer
  • Change the recovery policy for a domain
  • Not require a recovery agent for a domain
  • Disable Encrypting File System


Add a trusted root certification authority to a Group Policy object

Microsoft Windows graphic

To add a trusted root certification authority to a Group Policy object

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, click Trusted Root Certification Authorities.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Trusted Root Certification Authorities
  3. On the Action menu, point to All Tasks, and then click Import.

    This starts the Certificate Import Wizard, which guides you through the process of importing a root certificate and installing it as a trusted root certification authority (CA) for this GPO.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.
  • You can import a trusted root certificate from a PKCS #12 file (.pfx, .p12), a PKCS #7 file (.spc, .p7b), a certificate file (.cer, .crt), or a Microsoft serialized certificate store file (.sst).

Related Topics


Delete a trusted root certification authority from a Group Policy object

Microsoft Windows graphic

To delete a trusted root certification authority from a Group Policy object

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, click Trusted Root Certification Authorities.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Trusted Root Certification Authorities
  3. In the details pane, click the root certificate that you want to delete.
  4. On the Action menu, click Delete.
  5. If you are sure that you want to delete this certificate, click Yes.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.

Related Topics


Prevent users from selecting new root certification authorities with a Group Policy

Microsoft Windows graphic

To prevent users from selecting new root certification authorities with a Group Policy

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, right-click Trusted Root Certification Authorities, and then click Properties.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Trusted Root Certification Authorities
  3. Clear the Allow users to select new root certification authorities (CAs) to trust check box.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.

Related Topics


Prevent users from trusting third-party root certification authorities with a Group Policy

Microsoft Windows graphic

To prevent users from trusting third-party root certification authorities with a Group Policy

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, right-click Trusted Root Certification Authorities, and click Properties.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Trusted Root Certification Authorities
  3. In Client computers can trust the following certificate stores, click Enterprise Root Certification Authorities.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.

Related Topics


Create an automatic certificate request for computers in a Group Policy object

Microsoft Windows graphic

To create an automatic certificate request for computers in a Group Policy object

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, click Automatic Certificate Request Settings.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Automatic Certificate Request Settings
  3. On the Action menu, point to New, and then click Automatic Certificate Request.

    This starts the Automatic Certificate Request Setup Wizard. Follow the steps in the wizard to create an automatic certificate request for computers that have this GPO applied to them.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.
  • To use the Automatic Certificate Request Setup Wizard, you must know the certificate template that you want to use. A certificate based on the selected template will be requested automatically at the first occurrence of any of the following: a user logs on, Group Policy is refreshed, or a computer joins the domain and is subject to a Group Policy setting.
  • The Automatic Certificate Request Setup Wizard asks which certification authority (CA) it should query when the wizard runs on Windows 2000. The wizard will not prompt you when it runs on XOX or the Windows Server 2003 family.
  • There can only be one certificate request for each certificate type per GPO.

Related Topics


Delete an automatic certificate request for computers in a Group Policy object

Microsoft Windows graphic

To delete an automatic certificate request for computers in a Group Policy object

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, click Automatic Certificate Request Settings.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Automatic Certificate Request Settings
  3. In the details pane, click the automatic certificate request that you want to delete.
  4. On the Action menu, click Delete.
  5. If you are sure that you want to delete this automatic certificate request, click Yes.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.

Related Topics


Create a certificate trust list for a Group Policy object

Microsoft Windows graphic

To create a certificate trust list for a Group Policy object

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, click Enterprise Trust.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Enterprise Trust
  3. On the Action menu, point to New, and then click Certificate Trust List.

    This starts the Certificate Trust List Wizard. Follow the steps in the wizard to create a certificate trust list (CTL) for the GPO.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.

  • To use the Certificate Trust List Wizard, you need the following information:

    • The certificate purposes for this CTL. For more information about CTL purposes, see Using enterprise trust policy.
    • The certificates that you want to add to the CTL. You can add certificates from the certificate store on the local computer or from a file. Acceptable file formats from which you can import a certificate are an X.509 v3 certificate file (.cer, .crt), a PKCS #7 file (.spc, .p7b), or a Microsoft serialized certificate store (.sst).
    • A certificate that has the Trust List Signing purpose and its associated private key in your personal certificate store. For general instructions on how to request a certificate, see To request a certificate.
    • As an option, you can enter a time stamp service URL to time-stamp the CTL.

Related Topics


Edit a certificate trust list for a Group Policy object

Microsoft Windows graphic

To edit a certificate trust list for a Group Policy object

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, click Enterprise Trust.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Enterprise Trust
  3. In the details pane, click the certificate trust list (CTL) that you want to edit.
  4. On the Action menu, point to All Tasks, and then click Edit.

    This starts the Certificate Trust List Wizard. Follow the steps in the wizard to edit the CTL for the GPO.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.

  • To use the Certificate Trust List Wizard, you need the following information:

    • The certificate purposes for this CTL. For more information about CTL purposes, see Using enterprise trust policy.
    • The certificates that you want to add to the CTL. You can add certificates from the certificate store on the local computer or from a file. Acceptable file formats from which you can import a certificate are an X.509 v3 certificate file (.cer, .crt), a PKCS #7 file (.spc, .p7b) or a Microsoft serialized certificate store (.sst).
    • A certificate that has the Trust List Signing purpose and its associated private key in your personal certificate store. For general instructions on how to request a certificate, see Request a certificate.
    • As an option, you can enter a time stamp service URL to time-stamp the CTL.

Related Topics


Delete a certificate trust list for a Group Policy object

Microsoft Windows graphic

To delete a certificate trust list for a Group Policy object

  1. Open the Group Policy object (GPO) that you want to edit.
  2. In the console tree, click Enterprise Trust.

    Where?

    • Policy Object Name
    • Computer Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
    • Enterprise Trust
  3. In the details pane, right-click the certificate trust list (CTL) that you want to delete.
  4. On the Action menu, click Delete.
  5. Click Yes if you are sure that you want to delete this CTL.

Notes

  • XOX
  • To open a GPO, see Group Policy.
  • This procedure does not apply to Local Policy objects.

Related Topics


Concepts

This section covers:

  • Public key policies overview
  • Understanding public key policies
  • Using public key policies


Public key policies overview

You can use the public key policy settings in Group Policy to:

  • Have computers automatically submit a certificate request to an enterprise certification authority and install the issued certificate. This is useful for ensuring that computers have the certificates that they need to perform public key cryptographic operations in your organization, for example, for Internet Protocol security (IPSec) or for client authentication. For more information about certificate autoenrollment for computers, see Automatic certificate request settings.

  • Create and distribute a certificate trust list (CTL). A certificate trust list is a signed list of root certification authority certificates that an administrator considers reputable for designated purposes such as client authentication or secure e-mail. For example, if you want to trust a certification authority's certificates for IPSec, but not for client authentication, you can implement that trust relationship with a certificate trust list. For more information about certificate trust lists, see Enterprise trust policy.

  • Establish common trusted root certification authorities. You can use this policy setting to make computers and users subject to common root certification authorities (in addition to the ones that they already trust individually). It is not necessary to use this policy setting for certification authorities in a domain, because they are already trusted by all users and computers in the domain. This policy is primarily for establishing trust in a root certification authority that is not a part of your organization. For more information about root certification authorities, see Policies to establish trust of root certification authorities.

  • Add encrypted data recovery agents, and change the encrypted data recovery policy settings. For more information about this policy setting, see Recovering data. For a general overview of Encrypting File System (EFS), see Encrypting File System overview.
It is not necessary for you to use these public key policy settings in Group Policy to deploy a public key infrastructure in your organization. However, these settings give you additional flexibility and control when you establish trust in certification authorities, issue certificates to computers, and deploy EFS across a domain.


Understanding public key policies

You can create public key policies for distribution to computers or users within a site, domain, or organizational unit. To do this, use Group Policy, with the Security Settings extension enabled. This section covers:

  • Automatic certificate request settings
  • Policies to establish trust of root certification authorities
  • Enterprise trust policy
  • Recovering data


Automatic certificate request settings

Certificate enrollment is the process of requesting, receiving, and installing a certificate. By using automatic certificate settings in public key policies, you can have computers that are associated with a Group Policy object (GPO) automatically enroll for certificates. This can save you the step of explicitly enrolling for computer-related certificates for each computer.

After you establish an automatic certificate request, the actual certificate requests occur the next time the computers associated with the GPO log on to the network.

For more information, see Automatic certificate request policy and Public key policies overview.


Policies to establish trust of root certification authorities

When a client presents a certificate to a host, the host has to trust the certificate of the root certification authority (CA) in the certification path to accept the certificate as a valid credential. You might want to establish trust automatically in specific root CAs for groups of users or computers.

You can use the public key policy in Group Policy to establish common trusted root CAs for the users and computers associated with a Group Policy object (GPO). When you apply the GPO to a site, domain, or organizational unit, the corresponding computers inherit the policy. These computers then trust the root CAs whose certificates you imported into the trusted root certification authority policy.

You have the option of designating trusted CAs by using either the trusted root certification authority policy or the enterprise trust policy. Use the following guidelines in determining which policy to use:

  • If your organization has its own Windows 2000 root CAs and uses Active Directory, you do not need to use the Group Policy mechanism to distribute the root certificates.
  • If your organization has its own root CAs that are installed on servers not running Windows 2000, use the trusted root certification authority policy to distribute your organization's root certificates. For more information, see Trusted root certification authority policy.
  • If your organization does not have its own CAs, use the enterprise trust policy to create certificate trust lists (CTLs) to establish your organization's trust of external root CAs. For more information, see Enterprise trust policy.

For more information, see Public key policies overview.


Enterprise trust policy

A certificate trust list (CTL) enables you to control trust of the purpose and of the validity period of certificates issued by external certification authorities (CAs).

Typically, a certification authority can issue certificates for a wide variety of purposes, such as secure e-mail or client authentication. But there might be situations in which you want to limit the trust of certificates issued by a particular certification authority, especially if the CA is outside your organization. In these situations, creating a CTL and using it through Group Policy can be useful.

Suppose, for example, a certification authority named "My CA" is capable of issuing certificates for server authentication, client authentication, code signing, and secure e-mail. However, you only want to trust certificates issued by My CA for the purpose of client authentication. You can create a CTL and limit the purpose for which you trust certificates issued by My CA so that they are only valid for client authentication. Any certificates issued for another purpose by My CA are not accepted for use by any computer or user in the scope of the Group Policy object (GPO) to which the CTL is applied.

There can be multiple CTLs in an organization. Because the uses and trusts of certificates for particular domains or organizational units might be different, you can create separate CTLs to reflect these uses and assign particular CTLs to particular GPOs.

Through the use of Group Policy in your organization, you have the option of designating trust in CAs by using either the trusted root certification authority policy or the enterprise trust policy (CTLs). Use the following guidelines in determining which policy to use:

  • If your organization has its own root CAs and uses Active Directory, you do not need to use the Group Policy mechanism to distribute those root certificates.
  • If your organization has its own root CAs that are not installed on servers, you should use the trusted root certification authority policy to distribute your organization's root certificates. For more information, see Trusted root certification authority policy.
  • If your organization does not have its own CAs, use the enterprise trust policy to create CTLs to establish your organization's trust of external root CAs. For more information, see Using enterprise trust policy.

For more information, see Public key policies overview.


Using public key policies

This section covers:

  • Automatic certificate request policy
  • Trusted root certification authority policy
  • Using enterprise trust policy
  • Encrypted data recovery agents policy


Automatic certificate request policy

To create an automatic certificate request, you need the following information:

  • The certificate type that you want computers that are associated with the Group Policy object (GPO) to automatically enroll for. Computers can automatically request only certificate types that have a purpose associated with computers, not with users. Examples of computer-related certificates include:
    • Computer certificates
    • Internet Protocol security (IPSec) certificates
    • Web Server certificates
  • The certification authority (CA) that can issue the certificate.

    You can select from a predefined list of CAs. The CA that you select must be capable of issuing a certificate of the type and purpose that you have specified.

For more information, see Automatic certificate request settings, Create an automatic certificate request for computers in a Group Policy object, and Delete an automatic certificate request for computers in a Group Policy object.


Trusted root certification authority policy

To establish a trusted root certification authority using Group Policy, the Group Policy object (GPO) that you create must have access to the root certificate. This requires that you import a copy of the root certification authority certificate.

You can do this by using the procedure in To add a trusted root certification authority to a Group Policy object.

For a root certification authority certificate to be imported, the root certificate must be in a PKCS #12 file, in a PKCS #7 file, or in binary-encoded X.509 v3 certificate files. For more information about these file formats, see Importing and exporting certificates.

For more information on trusted root certification authority policies, see Policies to establish trust of root certification authorities and Delete a trusted root certification authority from a Group Policy object.


Using enterprise trust policy

You can assign a certificate trust list (CTL) to a Group Policy object (GPO) either by creating a new CTL or by importing an existing one. If you are creating a new CTL, you must sign the CTL with a certificate issued for this purpose by a certification authority (CA).

Creating a CTL also requires:

  • The root certificates that you want to include in the CTL.
  • The purposes for which you want to trust the root certificates in the CTL.

For more information, see Enterprise trust policy, Create a certificate trust list for a Group Policy object, Edit a certificate trust list for a Group Policy object, and Delete a certificate trust list for a Group Policy object.


Encrypted data recovery agents policy

You can manage encrypted data recovery policy for computers in a domain by using the following procedures:

  • To add a recovery agent for a domain
  • To create a recovery policy for a domain

You can manage encrypted data recovery policy for a local computer by using the following procedures:

  • To add a recovery agent for the local computer
  • To change the recovery policy for the local computer

For more information, see Encrypting File System overview and Recovering data.


Remove computer from docking station

Description

This security setting determines which users can remove a portable computer from its docking station.

Default: On servers and workstations, Administrators, Power Users, and Users have the right to remove a portable computer from its docking station on computers that contain "clean installations" of Windows 2000 Server, Windows 2000 Professional, XOX, or the Windows Server 2003 family, that is, installations that have not been upgraded from a previous version of Windows.

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

Note

  • On computers that have been upgraded from Windows NT to Windows 2000 Server, Windows 2000 Professional, XOX, or the Windows Server 2003 family, this right to remove the portable computer from its docking station must be explicitly granted to the appropriate group or user.


Shut down the computer when the security audit log is full

Description

Determine if the system will be automatically shut down if the security audit file has reached maximum size.

Notes

  • It is suggested that Audit: Shut down system immediately if unable to log security audits is used, instead of this policy setting.
  • This setting does not appear in the Local Computer Policy object.

Default: None

Configuring this security setting

You can configure this security setting by opening the appropriate policy and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Event Log\

For specific instructions about how to configure security policy settings, see To edit a security setting on a Group Policy object.

For more information, see:

  • Event Viewer


Event log

This security area defines attributes that are related to the application, security, and system logs: maximum log size, access rights for each log, and retention settings and methods. The application log records events generated by programs; the security log records security events, including logon attempts, object access, and changes to security, depending on what is audited; and the system log records operating system events. For more information, see Event Viewer.

This section covers:

  • Settings for Event Logs