Group Policy Settings - Local Policies - Security Options

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.

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

Default: Disabled.

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.

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.

Warning:

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.

This security setting determines whether a different account name is associated with the security identifier (SID) for the account Administrator. Renaming the well-known Administrator account makes it slightly more difficult for unauthorized persons to guess this privileged user name and password combination.

Default: Administrator.
Accounts: Rename guest account

This security setting determines whether a different account name is associated with the security identifier (SID) for the account "Guest." Renaming the well-known Guest account makes it slightly more difficult for unauthorized persons to guess this user name and password combination.

Default: Guest.

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.

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.

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.

Default: Disabled.

Windows Vista and later versions of Windows allow audit policy to be managed in a more precise way using audit policy subcategories. Setting audit policy at the category level will override the new subcategory audit policy feature. To allow audit policy to be managed using subcategories without requiring a change to Group Policy, there is a new registry value in Windows Vista and later versions, SCENoApplyLegacyAuditPolicy, which prevents the application of category-level audit policy from Group Policy and from the Local Security Policy administrative tool.

If the category level audit policy set here is not consistent with the events that are currently being generated, the cause might be that this registry key is set.

Default: Disabled

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.

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.

Default: Disabled.

This policy setting determines which users or groups can access DCOM application remotely or locally. This setting is used to control the attack surface of the computer for DCOM applications.

You can use this policy setting to specify access permissions to all the computers to particular users for DCOM applications in the enterprise. When you specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. If the security descriptor is left blank, the policy setting is defined in the template, but it is not enforced. Users and groups can be given explicit Allow or Deny privileges on both local access and remote access.

The registry settings that are created as a result of enabling the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting take precedence over (have higher priority) the previous registry settings in this area. Remote Procedure Call Services (RpcSs) checks the new registry keys in the Policies section for the computer restrictions, and these registry entries take precedence over the existing registry keys under OLE. This means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, computer access permissions for users are not changed. Use care in configuring their list of users and groups.

The possible values for this policy setting are:

ò Blank. This represents the local security policy way of deleting the policy enforcement key. This value deletes the policy and then sets it as Not defined state. The Blank value is set by using the ACL editor and emptying the list, and then pressing OK.

ò SDDL. This is the Security Descriptor Definition Language representation of the groups and privileges you specify when you enable this policy.

ò Not Defined. This is the default value.

Note
If the administrator is denied permission to access DCOM applications due to the changes made to DCOM in Windows, the administrator can use the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting to manage DCOM access to the computer. The administrator can specify which users and groups can access the DCOM application on the computer both locally and remotely by using this setting. This will restore control of the DCOM application to the administrator and users. To do this, open the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax setting, and click Edit Security. Specify the groups you want to include and the computer access permissions for those groups. This defines the setting and sets the appropriate SDDL value.

This policy setting determines which users or groups can launch or activate DCOM applications remotely or locally. This setting is used to control the attack surface of the computer for DCOM applications.

You can use this setting to grant access to all the computers to users of DCOM applications. When you define this setting, and specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. If the security descriptor is left blank, the policy setting is defined in the template, but it is not enforced. Users and groups can be given explicit Allow or Deny privileges on local launch, remote launch, local activation, and remote activation.

The registry settings that are created as a result of this policy take precedence over the previous registry settings in this area. Remote Procedure Call Services (RpcSs) checks the new registry keys in the Policies section for the computer restrictions; these entries take precedence over the existing registry keys under OLE.

The possible values for this Group Policy setting are:

ò Blank. This represents the local security policy way of deleting the policy enforcement key. This value deletes the policy and then sets it to Not defined state. The Blank value is set by using the ACL editor and emptying the list, and then pressing OK.

ò SDDL. This is the Security Descriptor Definition Language representation of the groups and privileges you specify when you enable this policy.

ò Not Defined. This is the default value.

Note
If the administrator is denied access to activate and launch DCOM applications due to the changes made to DCOM in this version of Windows, this policy setting can be used for controlling the DCOM activation and launch to the computer. The administrator can specify which users and groups can launch and activate DCOM applications on the computer both locally and remotely by using the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting. This restores control of the DCOM application to the administrator and specified users. To do this, open the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax setting, and click Edit Security. Specify the groups you want to include and the computer launch permissions for those groups. This defines the setting and sets the appropriate SDDL value.

This security setting determines the behavior of Admin Approval mode for the Built-in Administrator account.

The options are:

ò Enabled: The Built-in Administrator will logon in Admin Approval Mode. By default any operation that requires elevation of privilege will prompt the Consent Admin to choose either Permit or Deny.

ò Disabled: The Built-in Administrator will logon in XP compatible mode and run all applications by default with full administrative privilege.

Default: Disabled

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.

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.

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

Administrators
Administrators and Interactive Users

Default: This policy is not defined and only Administrators have this ability.

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 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 on servers: Enabled.
Default on workstations: Disabled

Notes

This setting does not affect the ability to add a local printer.
This setting does not affect Administrators.

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: This policy is not defined and CD-ROM access is not restricted to the locally logged-on user.

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: This policy is not defined and floppy disk drive access is not restricted to the locally logged-on user.

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.

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.

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: This policy is not defined, which has the same effect as None.

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 through SSL. No Microsoft LDAP clients that are shipped with Windows XP Professional use LDAP simple bind or LDAP simple bind through SSL to talk to a domain controller.
If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected. No Microsoft LDAP clients running Windows XP Professional or the Windows Server 2003 family use LDAP simple bind or LDAP simple bind through SSL to bind to directory service.

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: This policy is not defined, which means that the system treats it as Disabled.

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.

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.

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

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.

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, then all secure channel traffic will be signed which ensures that it cannot be tampered with in transit.

Default: Enabled.

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.

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.

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.

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

Default: 30 days.

Important

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

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.

Depending on what version of Windows is running on the domain controller that the domain member is communicating with and the settings of the 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.

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.

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.

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 on domain-computers: Disabled.
Default on stand-alone computers: Enabled.

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.

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.

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

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.

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.

Important

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

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.

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.

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
ò Disconnect if a remote Terminal Services session

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.

If you click Disconnect if a remote Terminal Services session, removal of the smart card disconnects the session without logging the user off. This allows the user to insert the smart card and resume the session later, or at another smart card reader-equipped terminal, without having to log on again.

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

On Windows Vista and above: In order for this setting to work, the Smart Card Removal Policy service must be started.

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.

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.

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.

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.

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.

Sending unencrypted passwords is a security risk.

Default: Disabled.

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:This policy is not defined, which means that the system treats it as 15 minutes for servers and undefined for workstations.

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.

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:

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.

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.

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 on Windows Vista: Enabled.
Default on Windows XP: Disabled

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 on workstations and member servers: Disabled.
Default on domain controllers: Enabled.

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:

Enabled: Do not allow enumeration of SAM accounts. This option replaces Everyone with Authenticated Users in the security permissions for resources.
Disabled: No additional restrictions. Rely on default permissions.

Default on workstations: Enabled.
Default on server:Disabled.

Important

This policy has no impact on domain controllers.

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.

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.

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.

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

Default: None.

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.

Default:

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

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 Windows XP, "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

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.

Default:

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

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 Windows XP, "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

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.

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

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 Windows XP, 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 Windows XP, but will appear as the "Network access: Remotely accessible registry paths" security option. For more information, see Network access: Remotely accessible registry paths and subpaths.

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.

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

Default: None specified.

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. 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.
If this setting is set to Guest only, network logons that use local accounts are automatically mapped to the Guest account. By using the Guest 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.

Default on domain omputers: Classic.
Default on stand-alone computers: Guest only

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 Windows Firewall 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.

Note:

This setting does not affect interactive logons that are performed remotely by using such services as Telnet or Terminal Services
This policy will have no impact on computers running Windows 2000.
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.

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.

Default on Windows Vista: Enabled
Default on Windows XP: Disabled.

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, Windows XP, and the Windows Server 2003 family to communicate with computers running Windows 95 and Windows 98.

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.

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.

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, Windows XP Professional, 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.

Default:

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

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 Windows XP Professional use ldap_simple_bind or ldap_simple_bind_s to talk to a domain controller.

Default: Negotiate signing.

This security setting allows a client to require the negotiation of 128-bit encryption and/or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The options are:

Require NTLMv2 session security: The connection will fail if NTLMv2 protocol is not negotiated.
Require 128-bit encryption: The connection will fail if strong encryption (128-bit) is not negotiated.

Default: No requirements.

This security setting allows a server to require the negotiation of 128-bit encryption and/or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The options are:

Require NTLMv2 session security: The connection will fail if message integrity is not negotiated.
Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not negotiated.

Default: No requirements.

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: This policy is not defined and automatic administrative logon is not allowed.

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: This policy is not defined and the recover console SET command is not available.

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 on workstations: Enabled.
Default on servers: Disabled.

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.

This security setting determines if the Transport Layer Security/Secure Sockets Layer (TL/SS) Security Provider supports only the Transport Layer Security (TLS) protocol as a client and as a server (if applicable). If this setting is enabled, 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 Windows XP 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.

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.

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: This policy is not defined.

Default: Administrators group (on servers).

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.

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.

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.

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.

This security setting determines the behavior of Admin Approval mode for the Built-in Administrator account.

The options are:

ò Enabled: The Built-in Administrator will logon in Admin Approval Mode. By default any operation that requires elevation of privilege will prompt the Consent Admin to choose either Permit or Deny.

ò Disabled: The Built-in Administrator will logon in XP compatible mode and run all applications by default with full administrative privilege.

Default: Disabled

This security setting determines the behavior of the elevation prompt for administrators

The options are:

ò Prompt for consent: An operation that requires elevation of privilege will prompt the Consent Admin to select either Permit or Deny. If the Consent Admin selects Permit the operation will continue with their highest available privilege. This option allows users to enter their name and password to perform a privileged task.

ò Prompt for credentials: An operation that requires elevation of privilege will prompt the Consent Admin to enter their user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.

ò Elevate without prompting: This option allows the Consent Admin to perform an operation that requires elevation without consent or credentials. Note: this scenario should only be used in the most constrained environments.

Default: Prompt for consent

The options are:

ò Prompt for credentials: An operation that requires elevation of privilege will prompt the user to enter an administrative user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.

ò Automatically deny elevation requests: This option results in an access denied error message being returned to the standard user when they try to perform an operation that requires elevation of privilege. Most enterprises running desktops as standard user will configure this policy to reduce help desk calls.

Default: Prompt for credentials (home) / Automatically deny elevation requests (enterprise)

This security setting determines the behavior of application installation detection for the entire system.

The options are:

ò Enabled: Application installation packages that require an elevation of privilege to install will be heuristically detected and trigger the configured elevation prompt UX.

ò Disabled: Enterprises running standard users desktops that leverage delegated installation technologies like Group Policy Software Install (GPSI) or SMS will disable this feature. In this case, installer detection is unnecessary and thus not required.

Default: Enabled (home) / Disabled (enterprise)

This security setting will enforce PKI signature checks on any interactive application that requests elevation of privilege. Enterprise administrators can control the admin application allowed list thru the population of certificates in the local computers Trusted Publisher Store.

The options are:

ò Enabled: Enforces the PKI certificate chain validation of a given executable before it is permitted to run.

ò Disabled: Does not enforce PKI certificate chain validation before a given executable is permitted to run.

Default: Disabled

This security setting will enforce the requirement that applications that request execution with a UIAccess integrity level (via a marking of UIAccess=true in their application manifest), must reside in a secure location on the file system. Secure locations are limited to the following directories:

- à\Program Files\, including subdirectories
- à\Windows\system32\
- à\Program Files (x86)\, including subdirectories for 64 bit versions of Windows

Note: Windows enforces a PKI signature check on any interactive application that requests execution with UIAccess integrity level regardless of the state of this security setting.

The options are:

ò Enabled: An application will only launch with UIAccess integrity if it resides in a secure location in the file system.

ò Disabled: An application will launch with UIAccess integrity even if it does not reside in a secure location in the file system.

Default: Enabled

This security setting determines the behavior of all UAC policies for the entire system.

The options are:

ò Enabled: Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this setting requires a system reboot.

ò Disabled: Admin Approval Mode user type and all related UAC policies will be disabled. Note: the Security Center will notify that the overall security of the operating system has been reduced.

Default: Enabled

This security setting determines whether the elevation request will prompt on the interactive users desktop or the Secure Desktop.

The options are:

ò Enabled: All elevation requests by default will go to the secure desktop

ò Disabled: All elevation requests will go to the interactive users desktop

Default: Enabled

This security setting enables the redirection of legacy application write failures to defined locations in both the registry and file system. This feature mitigates those applications that historically ran as administrator and wrote runtime application data back to either %ProgramFiles%, %Windir%; %Windir%\system32 or HKLM\Software\....

Virtualization facilitates the running of pre-Vista (legacy) applications that historically failed to run as Standard User. An administrator running only Windows Vista compliant applications may choose to disable this feature as it is unnecessary.

The options are:

ò Enabled: Facilitates the runtime redirection of application write failures to defined user locations for both the file system and registry.

ò Disabled: Applications that write data to protected locations will simply fail as they did in previous versions of Windows.

Default : Enabled

This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts being used by a standard user.

If you enable this setting, UIA programs including Windows Remote Assistance can automatically disable the secure desktop for elevation prompts. Unless you have also disabled elevation prompts, the prompts will appear on the interactive user's desktop instead of the secure desktop.

If you disable or do not configure this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the "User Account Control: Switch to the secure desktop when prompting for elevation" setting.

UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but allowing elevation requests to appear on the regular interactive desktop instead of the secure desktop increases your security risk.

Since UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. In order to be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths:
..\Program Files\ (and subfolders)
..\Program Files (x86)\ (and subfolders, in 64-bit versions of Windows only)
..\Windows\System32\

The requirement to be in a protected path can be disabled by the "User Account Control: Only elevate UIAccess applications that are installed in secure locations" setting.

While this setting applies to any UIA program, it will be used primarily in certain Windows Remote Assistance scenarios. The Windows Remote Assistance program in Windows Vista is a UIA program.

If a user requests remote assistance from an administrator and the remote assistance session is established, any elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, ,the user may select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. However, selecting this check box itself requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation.

If you enable this setting, ("User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop”), , requests for elevation are automatically sent to the interactive desktop (not the secure desktop) and also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator is able to provide the appropriate credentials for elevation.

This setting does not change the behavior of the UAC elevation prompt for administrators.

If you plan to enable this setting, you should also review the effect of the "User Account Control: Behavior of the elevation prompt for standard users" setting. If it is configured as "Automatically deny elevation requests" elevation requests will not be presented to the user.