Threats and Countermeasures Guide: Security Options
Applies To: Windows 7
Security Options
The Security Options section of Group Policy configures computer security settings for digital data signatures, Administrator and Guest account names, access to floppy disk and CD/DVD drives, driver installation behavior, and logon prompts.
Security Options settings
You can configure the Security Options policy settings in the following location within the Group Policy Object Editor or the Group Policy Management Console:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
The Security Options item of Group Policy contains the following policies:
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 the use of Backup and Restore privilege
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
Audit: Shut down system immediately if unable to log security audits
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL)
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL)
Devices: Allow undock without having to log on
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
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 (multiple related settings)
Domain member: Disable machine account password changes
Domain member: Maximum machine account password age
Domain member: Require strong (Windows 2000 or later) session key
Interactive logon: Display user information when the session is locked
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 and 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 workstation
Interactive logon: Require smart card
Interactive logon: Smart card removal behavior
Microsoft network client and server: Digitally sign communications (four related settings)
Microsoft network client: Send unencrypted password to third-party SMB servers
Microsoft network server: Amount of idle time required before suspending session
Microsoft network server: Disconnect clients when logon hours expire
Microsoft network server: Server SPN target name validation level
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 passwords or credentials 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 sub-paths
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: Allow Local System to use computer identity for NTLM
Network security: Allow Local System NULL session fallback
Network Security: Allow PKU2U authentication requests to this computer to use online identities
Network security: Configure encryption types allowed for Kerberos
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
Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
Network security: Restrict NTLM: Add server exceptions in this domain
Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
Network Security: Restrict NTLM: Audit NTLM authentication in this domain
Network Security: Restrict NTLM: Incoming NTLM traffic
Network Security: Restrict NTLM: NTLM authentication in this domain
Network Security: Restrict NTLM: Outgoing NTLM traffic to remote 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
User Account Control: Admin Approval Mode for the Built-in Administrator account
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
User Account Control: Behavior of the elevation prompt for standard users
User Account Control: Detect application installations and prompt for elevation
User Account Control: Only elevate executables that are signed and validated
User Account Control: Only elevate UIAccess applications that are installed in secure locations
User Account Control: Run all administrators in Admin Approval Mode
User Account Control: Switch to the secure desktop when prompting for elevation
User Account Control: Virtualize file and registry write failures to per-user locations
Accounts: Administrator account status
This policy setting enables or disables the Administrator account for normal operational conditions. If you start a computer in Safe Mode, the Administrator account is always enabled, regardless of how you configure this policy setting.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
The built-in Administrator account cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute force attacks that attempt to guess passwords. This account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute force attack by using the SID to log on. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum.
Countermeasure
Disable the Accounts: Administrator account status policy setting so that the built-in Administrator account cannot be used in a normal system startup.
If it is very difficult to maintain a regular schedule for periodic password changes for local accounts, you can disable the built-in Administrator account instead of relying on regular password changes to protect it from attack.
Potential impact
Maintenance issues can arise under certain circumstances if you disable the Administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there is no other local Administrator account, you must restart in Safe Mode to fix the problem that caused the secure channel to fail.
If the current Administrator password does not meet the password requirements, you cannot enable the Administrator account after it is disabled. If this situation occurs, another member of the Administrators group must set the password on the Administrator account with the Local Users and Groups tool.
Accounts: Guest account status
This policy setting enables or disables the Guest account.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
The default Guest account allows unauthenticated network users to log on as Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group are accessible over the network, which could lead to the exposure or corruption of data.
Countermeasure
Disable the Accounts: Guest account status policy setting so that the built-in Guest account cannot be used.
Potential impact
All network users must be authenticated before they can access shared resources. If you disable the Guest account and the Network Access: Sharing and Security Model option is set to Guest Only, network logons fail, such as those performed by the Microsoft Network Server (SMB Service). This policy setting should have little impact on most organizations because Disabled is the default setting.
Accounts: Limit local account use of blank passwords to console logon only
This policy setting enables or disables remote interactive logons by network services such as Terminal Services or Remote Desktop Services, Telnet, and File Transfer Protocol (FTP) for local accounts that have blank passwords. If you enable this policy setting, a local account must have a non-blank password to perform an interactive or network logon from a remote client.
Possible values:
Enabled
Disabled
Not Defined
Warning
This policy setting does not affect interactive logons that are performed physically at the console or logons that use domain accounts. It is possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting.
Vulnerability
Blank passwords are a serious threat to computer security, and they should be forbidden through both organizational policy and suitable technical measures. In fact, the default settings for Active Directory® domains require complex passwords of at least seven characters. However, if users with the ability to create new accounts bypass your domain-based password policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts could then use it to log on.
Countermeasure
Enable the Accounts: Limit local account use of blank passwords to console logon only policy setting.
Potential impact
None. This is the default configuration.
Accounts: Rename administrator account
This policy setting determines whether a different account name is associated with the SID for the Administrator account.
Possible values:
User-defined text
Not Defined
Vulnerability
If you rename the Administrator account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination. The user who installs the operating system specifies an account that is the first member of the Administrator group and has full rights to configure the computer. The account may not have the name Administrator, so this countermeasure is applied by default on new Windows® 7 installations. If a computer is upgraded from a previous version of Windows to Windows 7, the account with the name Administrator is retained with all the rights and privileges that were defined for the account in the previous installation.
The built-in Administrator account cannot be locked; regardless of how many times an attacker might use an incorrect password. This capability makes the Administrator account a popular target for brute force attacks that attempt to guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute force attack by using the SID to log on.
Countermeasure
Specify a new name in the Accounts: Rename administrator account policy setting to rename the Administrator account.
Potential impact
You must provide users who are authorized to use this account with the new account name. (The guidance for this policy setting assumes that the Administrator account was not disabled.)
Accounts: Rename guest account
This policy setting determines that the account name is associated with the SID for the Guest account.
Possible values:
User-defined text
Not Defined
Vulnerability
Because the Guest account name is well known, it provides a vector for a malicious user to access network resources and attempt to elevate privileges or install software that could be used for a later attack on your system.
Countermeasure
Specify a new name in the Accounts: Rename guest account policy setting to rename the Guest account. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination.
Potential impact
There should be little impact because the Guest account is disabled by default.
Audit: Audit the access of global system objects
If you enable this policy setting, a default system access control list (SACL) is applied when the computer creates system objects such as mutexes, events, semaphores, and MS-DOS® devices. If you also enable the Audit object access audit setting, access to these system objects is audited.
Global system objects, also known as "base system objects" or "base named objects," are temporary kernel objects that have had names assigned to them by the application or system component that created them. These objects are most commonly used to synchronize multiple applications or multiple parts of a complex application. Because they have names, these objects are global in scope, and therefore, they are visible to all processes on the computer. These objects all have a security descriptor, but typically they have a NULL SACL. If you enable this policy setting at startup, the kernel assigns a SACL to these objects when they are created.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
A globally visible named object, if incorrectly secured, could be acted upon by malicious software by using the name of the object. For instance, if a synchronization object such as a mutex had a poorly chosen discretionary access control list (DACL), malicious software could access that mutex by name and cause the program that created it to malfunction. However, the risk of such an occurrence is very low.
Countermeasure
Enable the Audit: Audit the access of global system objects policy setting.
Potential impact
If you enable the Audit: Audit the access of global system objects policy setting, a large number of security events could be generated, especially on busy domain controllers and application servers. Such an occurrence could cause servers to respond slowly and force the Security log to record numerous events of little significance. This policy setting can only be enabled or disabled, and there is no way to choose which events are recorded. Even organizations that have the resources to analyze events that are generated by this policy setting are not likely to have the source code or a description of what each named object is used for. Therefore, it is unlikely that most organizations would benefit by enabling this policy setting.
Audit: Audit the use of Backup and Restore privilege
This policy setting enables or disables auditing of the use of all user privileges, including Backup and Restore, when the Audit privilege use policy setting is in effect. If you enable both policy settings, an audit event is generated for every file that is backed up or restored.
If you enable this policy setting in conjunction with the Audit privilege use policy setting, any exercise of user rights is recorded in the Security log. If you disable this policy setting, actions by users who have Backup or Restore privileges are not audited, even if Audit privilege use is enabled.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
When the Backup and Restore function is used, it creates a copy of the file system that is identical to the target of the backup. Making regular Backup and Restore volumes is an important part of your incident response plan. However, a malicious user could use a legitimate backup copy to gain access to information or to impersonate a legitimate network resource to compromise your enterprise.
Countermeasure
Enable the Audit: Audit the use of Backup and Restore privilege policy setting. Alternatively, implement automatic log backup by configuring the AutoBackupLogFiles registry key. If you enable this option when the Audit privilege use policy setting is also enabled, an audit event is generated for every file that is backed up or restored. This information could help you to identify an account that was used to accidentally or maliciously restore data in an unauthorized manner.
For more information about configuring this key, see article 100879 in the Microsoft Knowledge Base.
Potential impact
If you enable this policy setting, a large number of security events could be generated, which could cause servers to respond slowly and force the Security event log to record numerous events of little significance. If you increase the Security log size to reduce the chances of a system shutdown, an excessively large log file may affect system performance.
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
In Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2, audit policies can be managed in a more precise way by using the audit policy subcategories. Setting audit policies at the category level overrides the subcategory audit policy feature. The registry value SCENoApplyLegacyAuditPolicy, allows audit policies to be managed by using subcategories without requiring a change to Group Policy settings. This registry value can be set to prevent the application of category-level audit policies from Group Policy and from the Local Security Policy administrative tool.
There are 40 auditing subcategories that provide more precise details about activities on a computer. The following table lists these subcategories.
| Category–Subcategory | Description | Default Setting |
|---|---|---|
System–Security System Extension |
Reports the loading of extension code such as authentication packages by the security subsystem. |
No Auditing |
System–System Integrity |
Reports on violations of integrity of the security subsystem. |
Success and Failure |
System–IPsec Driver |
Reports on the activities of the Internet Protocol security (IPsec) driver. |
No Auditing |
System–Other System Events |
Reports on other system events. |
Success and Failure |
System–Security State Change |
Reports changes in security state of the system, such as when the security subsystem starts and stops. |
Success |
Logon/Logoff–Logon |
Reports when a user attempts to log on to the system. |
Success |
Logon/Logoff–Logoff |
Reports when a user logs off from the system. |
Success |
Logon/Logoff–Account Lockout |
Reserved for future use. |
No Auditing |
Logon/Logoff–IPsec Main Mode |
Reports the results of Internet Key Exchange (IKE) protocol and Authenticated Internet Protocol (AuthIP) during Main Mode negotiations. |
No Auditing |
Logon/Logoff–IPsec Quick Mode |
Reports the results of IKE protocol and AuthIP during Quick Mode negotiations. |
No Auditing |
Logon/Logoff–IPsec Extended Mode |
Reports the results of AuthIP during Extended Mode negotiations. |
No Auditing |
Logon/Logoff–Special Logon |
Reports when a special logon is used. A special logon is a logon that has administrator-equivalent privileges and can be used to elevate a process to a higher level. |
Success |
Logon/Logoff–Network Policy Server |
Reports events that are generated by RADIUS and Network Access Protection (NAP) user access requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and Unlock. Auditing this setting results in a medium or high volume of records on servers running Network Policy Server. |
No Auditing |
Logon/Logoff–Other Logon/Logoff Events |
Reports other logon/logoff-related events, such as disconnecting and reconnecting to Remote Desktop Services or Terminal Services sessions, using RunAs to run processes under a different account, and locking and unlocking a workstation. |
No Auditing |
Object Access–File System |
Reports when file system objects are accessed. Only file system objects with SACLs cause audit records to be generated, and only when they are accessed in a manner that matches their SACL. |
No Auditing |
Object Access–Registry |
Reports when registry objects are accessed. Only registry objects with SACLs cause audit records to be generated, and only when they are accessed in a manner that matches their SACL. |
No Auditing |
Object Access–Kernel Object |
Reports when kernel objects such as processes and mutexes are accessed. Only kernel objects with SACLs cause audit records to be generated, and only when they are accessed in a manner that matches their SACL. Typically kernel objects are only given SACLs if the AuditBaseObjects or AuditBaseDirectories auditing options are enabled. |
No Auditing |
Object Access–SAM |
Reports when SAM objects are accessed. |
No Auditing |
Object Access–Certification Services |
Reports when Certification Services operations are performed. |
No Auditing |
Object Access–Application Generated |
Reports when applications attempt to generate audit events by using the Windows auditing application programming interfaces (APIs). |
No Auditing |
Object Access–Handle Manipulation |
Reports when a handle to an object is opened or closed. Only objects with SACLs cause these events to be generated and only if the attempted handle operation matches the SACL. Handle Manipulation events are only generated for object types where the corresponding Object Access subcategory is enabled; for example, File System or Registry. |
No Auditing |
Object Access–File Share |
Reports when a file share is accessed. |
No Auditing |
Object Access–Filtering Platform Packet Drop |
Reports when packets are dropped by the Windows Filtering Platform (WFP). These are high-volume events, so log file size should be monitored closely when auditing these events. |
No Auditing |
Object Access–Filtering Platform Connection |
Reports when connections are allowed or blocked by WFP. These are high-volume events, so log file size should be monitored closely when auditing these events. |
No Auditing |
Object Access–Other Object Access Events |
Reports other object access-related events such as Task Scheduler jobs and COM+ objects. |
No Auditing |
Detailed Tracking–Process Termination |
Reports when a process terminates. |
No Auditing |
Detailed Tracking– DPAPI Activity |
Reports encrypted or decrypted calls into the data protections application programming interface (DPAPI). DPAPI protects secret information such as stored password and key information. |
No Auditing |
Detailed Tracking–RPC Events |
Reports remote procedure call (RPC) connection events. |
No Auditing |
Detailed Tracking–Process Creation |
Reports the creation of a process and the name of the program or user that created it. |
No Auditing |
Policy Change–Audit Policy Change |
Reports changes in the audit policy including SACL changes. |
Success |
Policy Change–Authentication Policy Change |
Reports changes in the authentication policy. |
Success |
Policy Change–Authorization Policy Change |
Reports changes in the authorization policy including permissions (DACL) changes. |
No Auditing |
Policy Change–MPSSVC Rule-Level Policy Change |
Reports changes in policy rules that are used by the Microsoft Protection Service (MPSSVC.exe). This service is used by Windows Firewall. |
No Auditing |
Policy Change–Filtering Platform Policy Change |
Reports the addition and removal of objects from WFP, including startup filters. These are high-volume events, so log file size should be monitored closely when auditing these events. |
No Auditing |
Policy Change–Other Policy Change Events |
Reports other types of security policy changes, such as configuration of the Trusted Platform Module (TPM) or cryptographic providers. |
No Auditing |
Account Management–User Account Management |
Reports each event of user account management, such as when a user account is created, changed, deleted, renamed, disabled, or enabled, or when a password is set or changed. |
Success |
User Account Management–Computer Account Management |
Reports each event of computer account management, such as when a computer account is created, changed, deleted, renamed, disabled, or enabled. |
No Auditing |
User Account Management–Security Group Management |
Reports each event of security group management, such as when a security group is created, changed, or deleted, or when a member is added to or removed from a security group. |
Success |
User Account Management–Distribution Group Management |
Reports each event of distribution group management, such as when a distribution group is created, changed, or deleted, or when a member is added to or removed from a distribution group. |
No Auditing |
User Account Management–Application Group Management |
Reports each event of application group management on a computer, such as when an application group is created, changed, or deleted, or when a member is added to or removed from an application group. |
No Auditing |
User Account Management–Other Account Management Events |
Reports other account management events. |
No Auditing |
DS Access–Directory Service Changes |
Reports changes to objects in Active Directory Domain Services (AD DS). Directory Service Changes auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed. Only objects with SACLs cause an audit to be generated, and only when they are accessed in a manner that matches their SACL. Some objects and properties do not cause an audit to be generated due to settings to the object class in the schema. |
No Auditing |
DS Access–Directory Service Replication |
Reports when replication between two domain controllers begins and ends. |
No Auditing |
DS Access–Detailed Directory Service Replication |
Reports details about the information that is replicating between domain controllers. These are high-volume events, so log file size should be monitored closely when auditing these events. |
No Auditing |
DS Access–Directory Service Access |
Reports when an AD DS object is accessed. Only objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches their SACL. |
No Auditing |
Account Logon–Kerberos Ticket Events |
Reports the results of validation tests on Kerberos protocol tickets that are submitted for a user account logon request. |
No Auditing |
Account Logon–Other Account Logon Events |
Reports the events that occur in response to credentials that are submitted for a user account logon request. These events do not relate to credential validation or Kerberos protocol tickets, because those events have separate subcategories that can be audited). |
No Auditing |
Account Logon–Credential Validation |
Reports the results of validation tests on credentials that are submitted for a user account logon request. |
No Auditing |
Privilege Use–Sensitive Privilege Use |
Reports when a user account or service uses a sensitive privilege. A sensitive privilege includes the following user rights:
Auditing this subcategory creates a high volume of events, so log file size should be monitored closely when auditing these events. |
No Auditing |
Privilege Use–Non Sensitive Privilege Use |
Reports when a user account or service uses a nonsensitive privilege. The following list identifies the user rights that are considered nonsensitive privileges:
Auditing this subcategory creates a high volume of events, so log file size should be monitored closely when auditing these events. |
No Auditing |
Privilege Use–Other Privilege Use |
This category is reserved for future use. No events are currently mapped to this subcategory. |
No Auditing |
Vulnerability
Prior to the introduction of auditing subcategories in Windows Vista, it was difficult to track events at a per-system or per-user level. The larger event categories created too many events, and the key information that needed to be audited was difficult to find.
Countermeasure
Enable audit policy subcategories as needed to track specific events.
Potential impacts
The individual audit policy subcategories are now exposed in the Group Policy tools interface. Administrators can deploy a custom audit policy that applies detailed security auditing settings. If you attempt to modify an auditing setting by using Group Policy after you enable this setting, the Group Policy auditing setting is ignored in favor of the custom policy setting. To modify auditing settings by using Group Policy, you must first disable the SCENoApplyLegacyAuditPolicy key.
Important
Be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable Success or Failure auditing for all of the Privilege Use subcategories, the high volume of audit events that are generated can make it difficult to find other types of entries in the Security log. Such a configuration could also have a significant impact on system performance.
Audit: Shut down system immediately if unable to log security audits
This policy setting enables or disables shutting down the computer if it is unable to log security events. The Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certifications require that the computer prevent the occurrence of auditable events if the audit system is unable to log them. The way that Windows meets this requirement is to halt the computer and display a Stop error if the audit system fails. If you enable this policy setting, the computer stops if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the Security log is full, and its specified retention method is Do Not Overwrite Events or Overwrite Events by Days.
When this policy setting is enabled, the following Stop error displays if the security log is full and an existing entry cannot be overwritten:
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 disable this option to allow the computer to be restarted. At that point, it may be necessary to manually clear the Security log before you can configure this policy setting toEnabled.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
If the computer is unable to record events to the Security log, critical evidence or important troubleshooting information may not be available for review after a security incident. Also, an attacker could potentially generate a large volume of Security log events to purposely force a computer shutdown.
Countermeasure
Enable the Audit: Shut down system immediately if unable to log security audits policy setting to ensure that security auditing information is captured for review.
Potential impact
If you enable this policy setting, the administrative burden can be significant, especially if you also configure the Retention method for the Security log to Do not overwrite events (clear log manually). This configuration causes a repudiation threat (for example, a backup operator could deny that they backed up or restored data) to become a denial-of-service (DoS) vulnerability because a server could be forced to shut down if it is overwhelmed with logon events and other security events that are written to the Security log. Also, because the shutdown is abrupt, it is possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system maintains its integrity when this type of computer shutdown occurs, there is no guarantee that every data file for every application will still be in a usable form when the computer restarts.
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL)
This policy setting allows administrators to define additional computer-wide access controls that govern access to all Distributed Component Object Model (DCOM)–based applications on a computer. These controls restrict call, activation, or launch requests on the computer. A simple way to think about these access controls is that an additional access check call is performed against a computer-wide access control list (ACL) on each call, activation, or launch of any COM server on the computer. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM server on the computer. This policy setting controls access permissions to cover call rights.
These computer-wide ACLs provide a way to override weak security settings that are specified by a specific application through the CoInitializeSecurity function or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific server.
These ACLs also provide a centralized location for an administrator to set a general authorization policy that applies to all COM servers on the computer.
This policy setting allows you to specify an ACL in two ways. You can type the security descriptor in SDDL, or you can choose users and groups and grant or deny them Local Access and Remote Access permissions. We recommend that you use the built-in user interface to specify the ACL content that you want to apply with this setting.
The default ACL settings vary, depending on the version of the Windows operating system you are running.
Vulnerability
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that often allow unauthenticated access to the process. In earlier versions of Windows, administrators could not override these settings to force stronger security without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls.
Also, COM infrastructure includes the Remote Procedure Call System Service (RPCSS), a system service that runs during and after computer startup. This service manages activation of COM objects and the running object table, and it provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM servers allow unauthenticated remote access, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users who use remote, unauthenticated computers.
Countermeasure
To protect individual COM-based applications or services, set the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) policy setting to an appropriate computer-wide ACL.
Potential impact
Windows operating systems implement default COM ACLs when they are installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM server and you override the default security settings, confirm that the application-specific call permissions that ACL assigns correct permissions to appropriate users. If the permissions are incorrect, you must change your application-specific permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail.
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL)
This policy setting is similar to the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) policy setting in that it allows administrators to define additional computer-wide access controls that govern access to all DCOM–based applications on a computer. However, the ACLs that are specified in this policy setting control local and remote COM launch requests (not access requests) on the computer. A simple way to think about this access control is that an additional access check call is performed against a computer-wide ACL on each launch of any COM server on the computer. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to launch any COM server on the computer. The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) policy setting differs in that it provides a minimum access check that is applied to attempts to access an already launched COM server.
These computer-wide ACLs provide a way to override weak security settings that are specified by a specific application through CoInitializeSecurity or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific COM server. These ACLs provide a centralized location for an administrator to set a general authorization policy that applies to all COM servers on the computer.
The DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL) policy setting allows you to specify an ACL in two ways. You can type the security descriptor in SDDL, or you can choose users and groups and grant or deny them Local Access and Remote Access permissions. We recommend that you use the built-in user interface to specify the ACL content that you want to apply with this policy setting.
The default ACL settings vary, depending on the version of the Windows operating system you are running.
Vulnerability
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that often allow unauthenticated access to the process. In earlier versions of Windows, administrators could not override these settings to force stronger security without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls.
COM infrastructure includes the RPCSS, a system service that runs during computer startup and always runs after that. This service manages activation of COM objects and the running object table, and it provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM servers allow unauthenticated remote component activation, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users by using remote, unauthenticated computers.
Countermeasure
To protect individual COM-based applications or services, set this policy setting to an appropriate computer-wide ACL.
Potential impact
Windows operating systems implement default COM ACLs when they are installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM server and you override the default security settings, confirm that the application-specific launch permissions ACL assigns activation permission to appropriate users. If it does not, you must change your application-specific launch permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail.
Devices: Allow undock without having to log on
This policy setting enables or disables the ability of a user to remove a portable computer from a docking station without logging on. If you enable this policy setting, users can press a docked portable computer's physical eject button to safely undock the computer. If you disable this policy setting, the user must log on to receive permission to undock the computer. Only users who have the Remove Computer from Docking Station privilege can obtain this permission.
Note
Disabling this policy setting only reduces theft risk for portable computers that cannot be mechanically undocked. Computers that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
If this policy setting is enabled, anyone with physical access to portable computers in docking stations could remove them and possibly tamper with them.
Countermeasure
Disable the Devices: Allow undock without having to log on policy setting.
Potential impact
Users who have docked their computers must log on to the local console before they can undock their computers. For computers that do not have docking stations, this policy setting has no impact.
Devices: Allowed to format and eject removable media
This policy setting determines who is allowed to format and eject removable media.
Possible values:
Administrators
Administrators and Power Users
Administrators and Interactive Users
Not Defined
Vulnerability
Users could move data on removable disks to a different computer where they have administrative privileges. The user could then take ownership of any file, grant themselves full control, and view or modify any file. The fact that most removable storage devices eject media when a mechanical button is pressed diminishes the advantage of this policy setting.
Countermeasure
Configure the Devices: Allowed to format and eject removable media policy setting to Administrators.
Potential impact
Only administrators can format and eject removable media. If users are in the habit of using removable media for file transfers and storage, they must be informed of the change in policy.
Devices: Prevent users from installing printer drivers
This policy setting determines who is allowed to install a printer driver when adding a network printer. For a computer to print to a network printer, that network printer driver must be installed on the local computer. If you enable this policy setting, only members of the Administrators, Power Users, or Server Operators groups are allowed to install a printer driver when they add a network printer. If you disable this policy setting, all users can install printer drivers when they add a network printer. This policy setting prevents typical users from downloading and installing untrusted printer drivers.
Note
This policy setting has no impact if an administrator has configured a trusted path to download drivers. If you use trusted paths, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver is not installed and the network printer is not added.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
It may be appropriate in some organizations to allow users to install printer drivers on their own workstations. However, you should allow only administrators, not users, to do so on servers because printer driver installation on a server may unintentionally cause the computer to become less stable. A malicious user could install inappropriate printer drivers in a deliberate attempt to damage the computer, or a user might accidentally install malicious software that masquerades as a printer driver.
Countermeasure
Enable the Devices: Prevent users from installing printer drivers policy setting.
Potential impact
Only members of the Administrators, Power Users, or Server Operators groups can install printers on the servers. If this policy setting is enabled but the driver for a network printer already exists on the local computer, users can still add the network printer.
Devices: Restrict CD-ROM access to locally logged-on user only
This policy setting determines whether a CD is accessible to local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable CDs. If this policy setting is enabled and no one is logged on interactively, the CD can be accessed over the network.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
A remote user could potentially access a mounted CD that contains sensitive information. This risk is small because CD drives are not automatically made available as shared drives; administrators must deliberately choose to share the drive. However, administrators can deny network users the ability to view data or run applications from removable media on the server.
Countermeasure
Enable the Devices: Restrict CD-ROM drive access to locally logged-on user only policy setting.
Potential impact
Users who connect to the server over the network cannot use any CD drives that are installed on the server when someone is logged on to the local console of the server. System tools that require access to the CD drive will fail. For example, the Volume Shadow Copy service attempts to access all CD and floppy disk drives that are present on the computer when it initializes, and if the service cannot access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail. This policy setting would not be suitable for a computer that serves as a CD media player for network users.
Devices: Restrict floppy access to locally logged-on user only
This policy setting determines whether removable floppy disks are accessible to local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable floppy disks. If this policy setting is enabled and no one is logged on interactively, a floppy disk can be accessed over the network.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
A remote user could potentially access a mounted floppy disk that contains sensitive information. This risk is small because floppy disk drives are not automatically shared; administrators must deliberately choose to share the drive. However, administrators can deny network users the ability to view data or run applications from removable media on the server.
Countermeasure
Enable the Devices: Restrict floppy access to locally logged-on user only policy setting.
Potential impact
Users who connect to the server over the network cannot use any floppy disk drives that are installed on the server when someone is logged on to the local console of the server. System tools that require access to floppy disk drives fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy disk drives that are present on the computer when it initializes, and if the service cannot access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail.
Domain controller: Allow server operators to schedule tasks
This policy setting determines whether server operators are allowed to submit jobs by means of the AT command. If you enable this policy setting, jobs that are created by server operators by means of the AT command run in the context of the account that runs the Task Scheduler service. By default, that is the Local System account. If you enable this policy setting, server operators could perform tasks that the Local System account can do, but that they typically cannot do, such as add their account to the local Administrators group.
Note
This security option setting affects only the AT schedule tool. It does not affect the Task Scheduler tool.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Tasks that run under the context of the Local System account can affect resources that are at a higher privilege level than the user account that scheduled the task.
Countermeasure
Disable the Domain controller: Allow server operators to schedule tasks policy setting.
Potential impact
The impact should be small for most organizations. Users (including those in the Server Operators group) can still create jobs by means of the Task Scheduler snap-in. However, those jobs run in the context of the account with which the user authenticates when setting up the job.
Domain controller: LDAP server signing requirements
This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
Possible values:
None
Require signature
Not Defined
Vulnerability
Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client, modifies them, and then forwards them to the client. Where LDAP servers are concerned, an attacker could cause a client to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement strong physical security measures to protect the network infrastructure. You could also implement Internet Protocol security (IPsec) authentication header mode (AH tunnel mode), which performs mutual authentication and packet integrity for IP traffic to make all types of man-in-the-middle attacks extremely difficult.
Countermeasure
Configure the Domain controller: LDAP server signing requirements policy setting to Require signature.
Potential impact
Clients that do not support LDAP signing cannot run LDAP queries against the domain controllers.
Domain controller: Refuse machine account password changes
This policy setting enables or disables a domain controller from accepting password change requests for computer accounts.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
If you enable this policy setting on all domain controllers in a domain, domain members cannot change their computer account passwords, and those passwords are more susceptible to attack.
Countermeasure
Disable the Domain controller: Refuse machine account password changes policy setting.
Potential impact
None. This is the default configuration.
Domain member: Digitally encrypt or sign secure channel data (multiple related settings)
The following policy settings determine whether a secure channel can be established with a domain controller that cannot sign or encrypt secure channel traffic:
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)
If you enable the Domain member: Digitally encrypt or sign secure channel data (always) policy setting, a secure channel cannot be established with any domain controller that cannot sign or encrypt all secure channel data.
To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, computers that are running the Windows operating system create a communication channel through NetLogon called "secure channels." These channels authenticate computer accounts, and they also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called "pass-through authentication," and it allows a computer that has joined a domain to have access to the user account database in its domain and in any trusted domains.
Note
To enable the Domain member: Digitally encrypt or sign secure channel data (always) policy setting on a member workstation or server, all domain controllers in the domain that the member belongs to must sign or encrypt all secure channel data. This requirement means that all such domain controllers cannot run an operating system earlier than Microsoft Windows NT® 4.0 with Service Pack 6a (SP6a).
If you enable the Domain member: Digitally encrypt or sign secure channel data (always) policy setting, the Domain member: Digitally sign secure channel data (when possible) policy setting is automatically enabled.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
When a computer joins a domain, a computer account is created. After it joins the domain, the computer uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated and sensitive information such as passwords are encrypted, but the channel is not integrity-checked, and not all information is encrypted. If a computer is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
Countermeasure
Select one of the following settings as appropriate for your environment to configure the computers in your domain to encrypt or sign secure channel data:
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)
Potential impact
Using digital encryption and signing the secure channel is a good idea where they are supported. The secure channel protects domain credentials as they are sent to the domain controller. However, operating systems earlier than Windows NT 4.0 with SP6a do not support digital encryption and signing the secure channel. Microsoft Windows® 98 Second Edition client computers do not support it unless they have the Active Directory Client Extension installed. Therefore, you cannot enable the Domain member: Digitally encrypt or sign secure channel data (always) policy setting on domain controllers that support Windows 98 client computers as members of the domain. Potential impacts can include the following:
The ability to create or delete trust relationships is disabled with clients running versions of Windows earlier than Windows NT 4.0 with SP6a.
Logons are disabled from client computers running versions of Windows earlier than Windows NT 4.0 with SP6a.
The ability to authenticate other domains' users is disabled from a domain controller running a version of Windows earlier than Windows NT 4.0 with SP6a in a trusted domain.
You can enable this policy setting after you eliminate all client computers running Windows 98 or Windows 95 from the domain and upgrade all Windows NT 4.0 servers and domain controllers from trusted/trusting domains to Windows NT 4.0 with SP6a. You can enable the policy settings, Domain member: Digitally encrypt secure channel data (when possible) and Domain member: Digitally encrypt sign channel data (when possible), on all computers in the domain that support the above settings and client computers running versions of Windows earlier than Windows NT 4.0 with SP6a. Applications that run on these versions of Windows are not affected.
Domain member: Disable machine account password changes
This policy setting enables or disables blocking the periodic changing of computer account passwords. If you enable this policy setting, the domain member cannot change its computer account password. If you disable this policy setting, the domain member is allowed to change its computer account password as specified by the Domain Member: Maximum age for computer account password policy setting, which is every 30 days by default.
Warning
Do not enable the Domain member: Disable machine account password changes policy setting. Computer account passwords are used to establish secure channel communications between members and domain controllers, and within the domain, they establish a secure channel between the domain controllers. After such communications are established, the secure channel transmits sensitive information that is needed to make authentication and authorization decisions.
Do not use the Domain member: Disable machine account password changes policy setting in an attempt to support dual-boot scenarios that use the same computer account. If you want to support such a scenario for two installations that are joined to the same domain, use different computer names for the two installations.
This policy setting was added to Windows to make it easier for organizations that store prebuilt computers that are put into production months later. It eliminates the need for those computers to rejoin the domain. This policy setting is also sometimes used with imaged computers or those with hardware- or software-level change prevention. Correct imaging procedures make the use of this policy unnecessary for imaged computers.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
The default requirement for domain accounts is to change the password every 30 days. If you disable this policy setting, computers retain the same passwords as their computer accounts. Computers that cannot automatically change their account password are at risk from an attacker who could determine the password for the computer's domain account.
Countermeasure
Verify that the Domain member: Disable machine account password changes policy setting is configured to Disabled.
Potential impact
None. This is the default configuration.
Domain member: Maximum machine account password age
This policy setting determines the maximum allowable age for a computer account password.
Possible values:
User-defined number of days between 0 and 999
Not Defined
Vulnerability
In Active Directory domains, each computer and every user has an account and password. By default, the domain members automatically change their domain password every 30 days. If you increase this interval significantly, or set it to 0 so that the computers no longer change their passwords, an attacker has more time to undertake a brute force attack to guess the password of one or more computer accounts.
Countermeasure
Configure the Domain member: Maximum machine account password age policy setting to 30 days.
Potential impact
None. This is the default configuration.
Domain member: Require strong (Windows 2000 or later) session key
This policy setting determines whether a secure channel can be established with a domain controller that cannot encrypt secure channel traffic with a strong, 128-bit session key. If you enable this policy setting, you can establish a secure channel only with a domain controller that can encrypt secure channel data with a strong key. If you disable this policy setting, 64-bit session keys are allowed.
Note
To enable this policy setting on a member workstation or server, all domain controllers in the domain to which the member belongs must be able to encrypt secure channel data with a strong, 128-bit key.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from attacks that attempt to hijack network sessions and eavesdrop. (Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the sender, or it can be redirected.)
Countermeasure
Enable the Domain member: Require strong (Windows 2000 or later) session key policy setting.
If you enable this policy setting, all outgoing secure channel traffic requires a strong encryption key. If you disable this policy setting, the key strength is negotiated. You should enable this policy setting only if the domain controllers in all trusted domains support strong keys. By default, this policy setting is disabled.
Potential impact
Computers that have this policy setting enabled cannot join Windows NT 4.0 domains, and trusts between Active Directory domains and Windows NT domains may not work properly. Computers that do not support this policy setting cannot join domains in which the domain controllers have this policy setting enabled.
Interactive logon: Display user information when the session is locked
When a Windows session is locked (which means the user at the computer pressed CTRL+ALT+DEL and the secure desktop is now displayed), user information is displayed. By default, this information is in the form of <user name> is logged on. The user display name is the user's Full name as set on the Properties page for that user. These settings do not apply to the display of the logon tiles, which are displayed on the desktop after using the Switch User feature. The information that is displayed can be changed to meet your security requirements by using the following possible values.
Possible values:
User display name, domain and user names
User display name only
Do not display user information
Not Defined
Vulnerability
When a computer displays the secure desktop in an unsecured area, certain user information can be readily available to anyone looking at the monitor, either physically or through a remote connection. The displayed user information could include the domain user account name or the full name of the user who locked the session or who had logged on last.
Countermeasure
Enabling this policy setting allows the operating system to hide certain user information from being displayed on the secure desktop (after the computer has been started or when the session has been locked by using CTRL+ALT+DEL). However, user information is displayed if the Switch User feature is used so that the logon tiles are displayed for each logged on user.
You might consider enabling the Interactive logon: Do not display last user name policy setting, which will prevent Windows from displaying the logon name and logon tile of the last user to log on.
Potential impact
If you do not enable this policy setting, the effect will be the same as enabling the policy setting and selecting the User display name, domain and user names option.
If the policy setting is enabled and set to Do not display user information, the user name of the user who is currently logged on is not displayed on the secure desktop when the computer is locked. However, if the Interactive logon: Do not display last user name policy setting is not enabled, the user name of the last user who logged on is still displayed. Depending on how the logon tiles are configured, they could provide visual clues as to who is logged on. In addition, if the Interactive logon: Do not display last user name policy setting is not enabled, then the Switch user feature will show user information.
Interactive logon: Do not display last user name
This policy setting determines whether the account name of the last user to log on to the client computers in your organization will be displayed in each computer's respective Windows logon screen. Enable this policy setting to prevent intruders from collecting account names visually from the screens of desktop or portable computers in your organization.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
An attacker with access to the console (for example, someone with physical access or someone who can connect to the server through Remote Desktop Services or Terminal Services) could view the name of the last user who logged on to the server. The attacker could then try to guess the password, use a dictionary, or use a brute force attack to try to log on.
Countermeasure
Enable the Interactive logon: Do not display last user name policy setting.
Potential impact
Users must always type their user names when they log on to the servers.
Interactive logon: Do not require CTRL+ALT+DEL
The CTRL+ALT+DEL key combination establishes a trusted path to the operating system for users to type their user name and password. When this policy setting is enabled, users are not required to use this key combination to log on to the network. However, this configuration poses a security risk because it provides an opportunity for users to log on with weaker logon credentials. When this policy is disabled, users must press CTRL+ALT+DEL before they log on to Windows, or they must use a smart card, a tamper-proof device that stores security information, to log on.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
This policy setting makes it easier for users with certain types of physical impairments to log on to computers that run the Windows operating system. However, if users are not required to press CTRL+ALT+DEL, they are susceptible to attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is required before logon, user passwords are communicated by means of a trusted path.
If this policy setting is enabled, an attacker could install a Trojan horse program that looks like the standard Windows logon dialog box and capture the user's password. The attacker would then be able to log on to the compromised account with whatever level of privilege that user has.
Countermeasure
Disable the Interactive logon: Do not require CTRL+ALT+DEL policy setting.
Potential impact
Unless they use a smart card to log on, users must simultaneously press CTRL+ALT+DEL before the logon dialog box is displayed.
Interactive logon: Message text for users attempting to log on and Message title for users attempting to log on
There are two separate policy settings that relate to logon displays:
Interactive logon: Message text for users attempting to log on
Interactive logon: Message title for users attempting to log on
The first policy setting specifies a text message that displays to users when they log on, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.
Possible values:
User-defined text
Not Defined
Vulnerability
Users often do not understand the importance of security practices. However, the display of a warning message before logon may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help to reinforce corporate policy by notifying employees of the appropriate policy during the logon process.
Countermeasure
Configure the Interactive logon: Message text for users attempting to log on and Interactive logon: Message title for users attempting to log on policy settings to an appropriate value for your organization.
Note
Any warning message that displays should be approved by your organization's legal and human resources representatives.
Potential impact
Users see a message in a dialog box before they can log on to the server console.
Note
Client computers running Windows 2000 cannot interpret and display messages that exceed 512 characters in length and contain carriage-return, line-feed sequences. You must use a computer that is running Windows 2000 to create a logon message policy that applies to other computers running Windows 2000. If you create a logon message policy on a computer that is running Windows 2000, and you discover that it does not display properly on other computers running Windows 2000, you must first change the policy setting to Not Defined, and then reconfigure the setting by using a computer running Windows 2000. If you do not do this, the changes do not take effect properly.
Interactive logon: Number of previous logons to cache (in case domain controller is not available)
This policy setting determines the number of individual users who can log on to a Windows domain by using cached account information. Logon information for domain accounts can be cached locally so that if a domain controller cannot be contacted on subsequent logons, a user can still log on. This policy setting determines the number of individual users whose logon information is cached locally.
If a domain controller is unavailable and a user's logon information is cached, the user is prompted with the following message:
A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on may not be available.
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.
Possible values:
User-defined number between 0 and 50
Not Defined
Vulnerability
The number that is assigned to this policy setting indicates the number of users whose logon information is cached locally by the servers. If the number is set to 10, the server caches logon information for 10 users. When an eleventh user logs on to the computer, the server overwrites the oldest cached logon session.
Users who access the server console have their logon credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords.
To mitigate this type of attack, Windows encrypts the information and obscures its physical location.
Countermeasure
Configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) policy setting to 0, which disables the local caching of logon information. Additional countermeasures include enforcement of strong password policies and physically secure locations for the computers.
Potential impact
Users cannot log on to any computers if there is no domain controller available to authenticate them. Organizations can configure this value to 2 for end-user computers, especially for mobile users. A configuration value of 2 means that the user's logon information is still in the cache, even if a member of the IT department has recently logged on to the computer to perform system maintenance. This method allows users to log on to their computers when they are not connected to the organization's network.
Interactive logon: Prompt user to change password before expiration
This policy setting determines how many days in advance that users are warned their password is about to expire. With this advanced warning, the user has time to construct a sufficiently strong password.
Possible values:
User-defined number of days between 1 and 999
Not Defined
Vulnerability
If user passwords are configured to expire periodically in your organization, users need to be warned when this is about to happen, or they may be locked out of the computer inadvertently when their passwords expire. This condition could lead to confusion for users who access the network locally, or it could make it impossible for users to access your organization's network through dial-up or virtual private network (VPN) connections.
Countermeasure
Configure the Interactive logon: Prompt user to change password before expiration policy setting to 14 days.
Potential impact
Users see a dialog-box prompt to change their password each time that they log on to the domain when their password is configured to expire in 14 or fewer days.
Interactive logon: Require Domain Controller authentication to unlock workstation
This policy setting enables or disables the requirement for a domain account to contact a domain controller to unlock a computer. Logon information is required to unlock a locked computer. If you enable this setting, a domain controller must authenticate the domain account that is being used to unlock the computer. If you disable this setting, logon-information confirmation with a domain controller is not required for a user to unlock the computer. However, if you configured the Interactive logon: Number of previous logons to cache (in case domain controller is not available) policy setting to a value that is greater than zero, the user's cached credentials are used to unlock the computer.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
By default, the computer caches (in memory) the credentials of any users who are authenticated locally. The computer uses these cached credentials to authenticate anyone who attempts to unlock the console. When cached credentials are used, any changes that have recently been made to the account—such as user rights assignments, account lockout, or the account being disabled—are not considered or applied after the account is authenticated. User privileges are not updated, and (more important) disabled accounts are still able to unlock the console of the computer.
Countermeasure
Configure the Interactive logon: Require Domain Controller authentication to unlock workstation policy setting to Enabled and configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) policy setting to 0.
Potential impact
When the console on a computer is locked by a user or automatically by a screen-saver timeout, the console can be unlocked only if the user can authenticate to the domain controller. If no domain controller is available, users cannot unlock their workstations. If you configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) policy setting to 0, users whose domain controllers are unavailable (such as mobile or remote users) cannot log on.
Interactive logon: Require smart card
This policy setting enables or disables the requirement for users to log on to a computer with a smart card. The use of smart cards instead of passwords for authentication dramatically increases security because current technology makes it extremely difficult for an attacker to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user must possess the smart card and know its PIN. Attackers who capture the authentication traffic between the user's computer and the domain controller find it extremely difficult to decrypt the traffic, and if they do, the next time that the user logs on to the network a new session key is generated to encrypt traffic between the user and the domain controller.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
It can be difficult to make users choose strong passwords, and even strong passwords are vulnerable to brute force attacks if an attacker has sufficient time and computing resources.
Countermeasure
For users with access to computers that contain sensitive data, issue smart cards and configure the Interactive logon: Require smart card policy setting to Enabled.
Potential impact
All users of a computer with this policy setting enabled must use smart cards to log on to the local computer, which means that the organization must have a reliable public key infrastructure (PKI) in addition to smart cards and smart card readers for these users. These requirements are significant challenges because expertise and resources are required to plan for and deploy these technologies. For more information about deploying smart cards, see Windows Vista Smart Card Infrastructure.
Interactive logon: Smart card removal behavior
This policy setting determines what happens when the smart card for a logged-on user is removed from the smart card reader.
Possible values:
No Action
Lock Workstation
Force Logoff
Disconnect if a remote Terminal Services session
Not Defined
By default, this policy setting is Not Defined, which is equivalent to the No Action setting.
Note
The Smart Card Removal Policy service must be started for this policy setting to work.
Vulnerability
Users sometimes forget to lock their workstations when they are away from them, allowing the possibility for malicious users to access their computers. If smart cards are used for authentication, the computer should automatically lock itself when the card is removed to ensure that only the user with the smart card is accessing resources by using those credentials.
Countermeasure
Configure the Interactive logon: Smart card removal behavior policy setting to Lock Workstation.
If you select Lock Workstation for this policy setting, the workstation locks when the smart card is removed. Users can leave the area, take their smart card with them, and still maintain a protected session. This behavior is similar to the setting that requires users to log on when resuming work on the computer after the screen saver has started.
If you select Force Logoff for this policy setting, the user is automatically logged off when the smart card is removed. This policy setting is useful when a computer is deployed as a public access point, such as a kiosk or other type of shared computer.
Potential impact
If you select Force Logoff, users must reinsert their smart cards and reenter their PINs when they return to their workstations.
Microsoft network client and server: Digitally sign communications (four related settings)
There are four separate policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications:
Microsoft Network Client: Digitally Sign Communications (Always)
Microsoft Network Server: Digitally Sign Communications (Always)
Microsoft Network Client: Digitally Sign Communications (If Server Agrees)
Microsoft Network Server: Digitally Sign Communications (If Client Agrees)
Implementation of digital signatures in high-security networks helps prevent the impersonation of clients and servers, known as "session hijacking."
Possible values for each of these policy settings are:
Enabled
Disabled
Not Defined
Vulnerability
Session hijacking uses tools that allow attackers who have access to the same network as the client computer or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client after legitimate authentication and gain unauthorized access to data.
SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate both users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
Countermeasure
Configure the policy settings as follows:
Disable Microsoft Network Client: Digitally Sign Communications (Always).
Disable Microsoft Network Server: Digitally Sign Communications (Always).
Enable Microsoft Network Client: Digitally Sign Communications (If Server Agrees).
Enable Microsoft Network Server: Digitally Sign Communications (If Client Agrees).
In highly secure environments, we recommend that you configure all of these policy settings to Enabled. However, that configuration may cause slower performance on client computers and prevent communications with earlier SMB applications and operating systems.
Note
An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
Potential impact
The Windows implementation of the SMB file and print-sharing protocol support mutual authentication, which prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by both the client computer and the server.
Implementing SMB signing may negatively affect performance because each packet must be signed and verified. If these policy settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
Microsoft network client: Send unencrypted password to third-party SMB servers
This policy setting enables or disables sending plaintext passwords by the SMB redirector to non-Microsoft SMB servers that do not support password encryption during authentication.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
If you enable this policy setting, the server can transmit plaintext passwords across the network to other computers that offer SMB services. These other computers might not use any of the SMB security mechanisms.
Countermeasure
Disable the Microsoft network client: Send unencrypted password to connect to third-party SMB servers policy setting.
Potential impact
Some very old applications and operating systems such as MS-DOS, Windows for Workgroups 3.11, and Microsoft Windows 95 may not be able to communicate with the servers in your organization by means of the SMB protocol.
Microsoft network server: Amount of idle time required before suspending session
This policy setting determines the amount of continuous idle time that must pass in an SMB session before the session is suspended because of inactivity. Administrators can use this policy setting to control when a computer suspends an inactive SMB session. The session automatically reestablishes when activity in client computer resumes. A value of 0 disconnects an idle session as quickly as possible. The maximum value is 99999, which is 208 days which in effect disables the policy setting.
Possible values:
User-defined period of time in minutes
Not Defined
By default, this policy is not defined, which means that the system allows 15 minutes of idle time for servers and an undefined time for workstations.
Vulnerability
Each SMB session consumes server resources, and numerous null sessions slow the server or possibly cause it to fail. An attacker could repeatedly establish SMB sessions until the server's SMB services become slow or unresponsive.
Countermeasure
The default behavior on a server mitigates this threat by design.
Potential impact
There is little impact because SMB sessions are reestablished automatically if the client resumes activity.
Microsoft network server: Disconnect clients when logon hours expire
This policy setting enables or disables the forced disconnection of users who are connected to the local computer outside their user account's valid logon hours. It affects the SMB component. If you enable this policy setting, client sessions with the SMB service are forcibly disconnected when the client's logon hours expire. If you disable this policy setting, established client sessions are maintained after the client's logon hours expire. If you enable this policy setting, you should also enable Network security: Force logoff when logon hours expire.
Possible values:
Enabled
Disabled
Not Defined
By default, this policy setting is enabled.
Vulnerability
If your organization configures logon hours for users, it makes sense to enable this policy setting. Otherwise, users who should not have access to network resources outside of their logon hours may actually continue to use those resources with sessions that were established during allowed hours.
Countermeasure
Enable the Microsoft network server: Disconnect clients when logon hours expire policy setting.
Potential impact
If logon hours are not used in your organization, this policy setting has no impact. If logon hours are used, existing user sessions are forcibly terminated when their logon hours expire.
Microsoft network server: Server SPN target name validation level
This policy setting controls the level of validation that a computer with shared folders or printers (the server) performs on the service principal name (SPN) that is provided by the client computer when it establishes a session by using the Server Message Block (SMB) protocol.
Possible values:
Off
Accept if provided by client
Required from client
By default, this policy setting is not defined.
Vulnerability
This policy setting controls the level of validation that a computer with shared folders or printers (the server) performs on the SPN that is provided by the client computer when it establishes a session by using the SMB protocol. The level of validation can help prevent a class of attacks against SMB servers (referred to as SMB relay attacks). This policy setting will affect SMB1 and SMB2.
Countermeasure
If you set Accept if provided by client, the SMB server will accept and validate the SPN that is provided by the SMB client and allow a session to be established if it matches the SMB server's list of SPNs. If the SPN does not match, the session request for that SMB client computer will be denied.
If you set Required from client, the SMB client computer must send an SPN name in session setup, and the SPN name that is provided must match the SMB server that is being requested to establish a connection. If no SPN is provided by the client computer, or the SPN that is provided does not match, the session is denied.
Potential impact
All Windows operating systems support a client SMB component and a server SMB component. This policy setting affects the server SMB behavior, and its implementation should be carefully evaluated and tested to prevent disruptions to file and print serving capabilities.
Because the SMB protocol is widely deployed, setting the options to Accept if provided by client or Required from client will prevent some clients from successfully authenticating to some servers in your environment.
Network access: Allow anonymous SID/Name translation
This policy setting enables or disables the ability of an anonymous user to request SID attributes for another user.
Possible values:
Enabled
Disabled
Not Defined
By default, this policy setting is enabled on domain controllers, and it is disabled on workstations and member servers.
Vulnerability
If this policy setting is enabled, a user with local access could use the well-known Administrator's SID to learn the real name of the built-in Administrator account, even if it has been renamed. That person could then use the account name to initiate a password-guessing attack.
Countermeasure
Disable the Network access: Allow anonymous SID/Name translation policy setting.
Potential impact
Disabled is the default configuration for this policy setting on member computers; therefore, it has no impact on them. The default configuration for domain controllers is Enabled. If you disable this policy setting on domain controllers, computers running versions of Windows earlier than Windows Server 2003 may not communicate with domains that have computers running Windows Server 2003. For example, the following computers may not work:
Remote Access Service servers running Windows NT 4.0
Servers that host Microsoft SQL Server® and run on computers that are running Windows NT 3.x or Windows NT 4.0
Servers that host Remote Access Service or Microsoft SQL Server and run on computers that are running Windows 2000 and are located in Windows NT domains
Network access: Do not allow anonymous enumeration of SAM accounts
This policy setting determines which additional permissions are granted for anonymous connections to the computer. The Windows operating system allows anonymous users to perform certain activities, such as querying the Security Accounts Manager (SAM) database store of user accounts and security descriptors for users on the local computer, and then enumerating the results. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. However, even if this policy setting is enabled, anonymous users still have access to any resources that have permissions that explicitly include the special built-in group ANONYMOUS LOGON.
In Windows 2000, a similar policy setting called Additional Restrictions for Anonymous Connections managed a registry value called RestrictAnonymous, which was located in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA registry key. In Windows Server 2003, the policy settings Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares replaced the Windows 2000 policy setting. They manage the registry values RestrictAnonymousSAM and RestrictAnonymous, respectively, which are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa registry key.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
An unauthorized user could anonymously list account names and use the information to perform social engineering attacks or attempt to guess passwords. Social engineering attackers try to deceive users in some way to obtain passwords or some form of security information.
Countermeasure
Enable the Network access: Do not allow anonymous enumeration of SAM accounts policy setting.
Potential impact
It is impossible to establish trust with domains that are running Windows NT 4.0. Also, client computers that run earlier versions of the Windows operating system such as Windows NT 3.51 and Windows 95 experience problems when they try to use resources on the server.
Network access: Do not allow anonymous enumeration of SAM accounts and shares
This policy setting determines whether anonymous enumeration of Security Accounts Manager (SAM) accounts and shared folders is allowed. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. You can enable this policy setting if you do not want to allow anonymous enumeration of SAM accounts and shared folders. However, even if it is enabled, anonymous users still have access to any resources that have permissions that explicitly include the special built-in group ANONYMOUS LOGON.
In Windows 2000, a similar policy setting called Additional Restrictions for Anonymous Connections managed a registry value called RestrictAnonymous, which was located in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA registry key. In Windows Server 2003, the policy settings Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares replaced the Windows 2000 policy setting. They manage the registry values RestrictAnonymousSAM and RestrictAnonymous, respectively, which are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa registry key.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords or perform social-engineering attacks.
Countermeasure
Enable the Network access: Do not allow anonymous enumeration of SAM accounts and shares policy setting.
Potential impact
It is impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers. The users must be authenticated before they can view the lists of shared folders and printers.
Network access: Do not allow storage of passwords or credentials for network authentication
This policy setting determines whether the Stored User Names and Passwords feature can save passwords or credentials for later use when it gains domain authentication. If you enable this policy setting, the Stored User Names and Passwords feature in Windows does not store passwords and credentials.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Passwords that are cached can be accessed by users when they are logged on to their computer. Although this information may sound obvious, a problem can arise if the user unknowingly runs malicious software that reads the passwords and forwards them to an unauthorized user.
Note
The chances of success for this exploit and others that involve malicious software are reduced significantly for organizations that effectively implement and manage an enterprise antivirus solution combined with sensible software restriction policies. For more information about software restriction policies, see the section Software Restriction Policies.
Countermeasure
Enable the Network access: Do not allow storage of passwords or credentials for network authentication policy setting.
Potential impact
Users are forced to type passwords whenever they log on to network resources that are not accessible to their domain account. This policy setting should have no impact on users who access network resources that are configured to allow access with their Active Directory–based domain account.
Network access: Let Everyone permissions apply to anonymous users
This policy setting determines what additional permissions are granted for anonymous connections to the computer. If you enable this policy setting, anonymous users can enumerate the names of domain accounts and shared folders and perform certain other activities. This capability 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 token that is created for anonymous connections does not include the Everyone SID. Therefore, permissions that are assigned to the Everyone group do not apply to anonymous users. If you enable this policy setting, the Everyone SID is added to the token that is created for anonymous connections, and anonymous users can access any resource for which the Everyone group has been assigned permissions.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
An unauthorized user could anonymously list account names and shared resources, and then use the information to attempt to guess passwords, perform social engineering attacks, or launch DoS attacks.
Countermeasure
Disable the Network access: Let Everyone permissions apply to anonymous users policy setting.
Potential impact
None. This is the default configuration.
Network access: Named Pipes that can be accessed anonymously
This policy setting determines which communication sessions, or pipes, have attributes and permissions that allow anonymous access.
Possible values:
User-defined list of shared folders
Not Defined
For this policy setting to take effect, you must also enable the Network access: Restrict anonymous access to named pipes and shares policy setting.
Vulnerability
You can restrict access over named pipes such as COMNAP and LOCATOR to help prevent unauthorized access to the network. The following list describes available named pipes and their purpose. These named pipes were granted anonymous access in earlier versions of Windows and some legacy applications may still use them.
| Named pipe | Purpose |
|---|---|
COMNAP |
SNABase named pipe (Systems Network Architecture (SNA) is a collection of network protocols that were originally developed for IBM mainframe computers.) |
COMNODE |
SNA Server named pipe |
SQL\QUERY |
Default named pipe for SQL Server |
SPOOLSS |
Named pipe for the Print Spooler service |
EPMAPPER |
End Point Mapper named pipe. |
LOCATOR |
Remote Procedure Call Locator service named pipe |
TrlWks |
Distributed Link Tracking Client named pipe |
TrkSvr |
Distributed Link Tracking Server named pipe |
Countermeasure
Configure the Network access: Named Pipes that can be accessed anonymously policy setting to a null value (enable the policy setting but do not specify named pipes in the text box).
Potential impact
This configuration disables null-session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes no longer function. This may break trust between domains in a mixed-mode environment.
Network access: Remotely accessible registry paths
This policy setting determines which registry paths are accessible when an application or process references the WinReg key to determine access permissions.
Possible values:
User-defined list of paths
Not Defined
Vulnerability
An attacker could use information in the registry to facilitate unauthorized activities. To reduce the risk of such an attack, suitable ACLs are assigned throughout the registry to help protect it from access by unauthorized users.
Countermeasure
Configure the Network access: Remotely accessible registry paths policy setting to a null value (enable the policy setting but do not enter any paths in the text box).
Potential impact
Remote management tools require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail.
Note
If you want to allow remote access, you must also enable the Remote Registry service.
Network access: Remotely accessible registry paths and sub-paths
This policy setting determines which registry paths and subpaths are accessible when an application or process references the WinReg key to determine access permissions.
Possible values:
User-defined list of paths
Not Defined
Vulnerability
The registry contains sensitive computer configuration information that could be used by an attacker to facilitate unauthorized activities. The fact that the default ACLs that are assigned throughout the registry are fairly restrictive and help protect the registry from access by unauthorized users reduces the risk of such an attack.
Countermeasure
Configure the Network access: Remotely accessible registry paths and sub-paths policy setting to a null value (enable the policy setting but do not enter any paths in the text box).
Potential impact
Remote management tools require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail.
Note
If you want to allow remote access, you must also enable the Remote Registry service.
Network access: Restrict anonymous access to Named Pipes and Shares
This policy setting enables or disables the restriction of anonymous access to only those shared folders and pipes that are named in the Network access: Named pipes that can be accessed anonymously and Network access: Shares that can be accessed anonymously policy settings. This policy setting controls null session access to shared folders on your computers by adding RestrictNullSessAccess with the value 1 in the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters. This registry value toggles null session shared folders on or off to control whether the Server service restricts unauthenticated clients' access to named resources.
Possible values:
Enabled
Disabled
Not Defined
This policy setting is enabled by default.
Vulnerability
Null sessions are a weakness that can be exploited through shared folders (including the default shared folders) on computers in your environment.
Countermeasure
Enable the Network access: Restrict anonymous access to Named Pipes and Shares policy setting.
Potential impact
You can enable this policy setting to restrict null-session access for unauthenticated users to all server pipes and shared folders except those that are listed in the NullSessionPipes and NullSessionShares entries.
If you choose to enable this policy setting and are supporting Windows NT 4.0 domains, determine whether any of the named pipes in the following list are required to maintain trust relationships between the domains, and then add the pipe to the Network access: Named pipes that can be accessed anonymously:
COMNAP–SNA session access
COMNODE–SNA session access
SQL\QUERY–SQL instance access
SPOOLSS–Spooler service
LLSRPC–License Logging service
Netlogon–Net Logon service
Lsarpc–LSA access
Samr–Remote access to SAM objects
browser–Computer Browser service
In operating systems earlier than Windows Server 2003 with Service Pack 1 (SP1), these named pipes were allowed anonymous access by default. In later operating systems, these pipes must be explicitly added if needed.
Network access: Shares that can be accessed anonymously
This policy setting determines which shared folders can be accessed by anonymous users.
Possible values:
User-defined list of shared folders
Not Defined
Vulnerability
Any shared folders that are listed can be accessed by any network user, which could lead to the exposure or corruption of sensitive data.
Countermeasure
Configure the Network access: Shares that can be accessed anonymously policy setting to a null value.
Potential impact
There should be little impact because this is the default configuration. Only authenticated users have access to shared resources on the server.
Network access: Sharing and security model for local accounts
This policy setting determines how network logons that use local accounts are authenticated. If you configure this policy setting to Classic, network logons that use local account credentials authenticate with those credentials. If you configure this policy setting to Guest only, network logons that use local accounts are automatically mapped to the Guest account. The Classic model provides precise control over access to resources and enables you to grant different types of access to different users for the same resource. Conversely, the Guest only model treats all users equally as the Guest user account, and they all receive the same level of access to a given resource, which can be either Read Only or Modify.
The default configuration for a stand-alone computer is Guest only. The default configuration for domain members is Classic.
Note
This policy setting does not affect network logons that use domain accounts. Nor does this policy setting affect interactive logons that are performed remotely through services such as Telnet, Terminal Services or Remote Desktop Services. This setting also has no effect on computers running Windows 2000.
When the computer is not joined to a domain, this policy setting also tailors the Sharing and Security tabs in Windows Explorer to correspond to the sharing and security model that is being used.
Possible values:
Classic: Local users authenticate as themselves
Guest only: Local users authenticate as Guest
Not Defined
Vulnerability
With the Guest only model, any user who can authenticate to your computer over the network does so with guest privileges, which probably means that they do not have Write access to shared resources on that computer. Although this restriction does increase security, it makes it more difficult for authorized users to access shared resources on those computers because ACLs on those resources must include access control entries (ACEs) for the Guest account. With the Classic model, local accounts should be password protected. Otherwise, if Guest access is enabled, anyone can use those user accounts to access shared system resources.
Countermeasure
For network servers, configure the Network access: Sharing and security model for local accounts policy setting to Classic – local users authenticate as themselves. On end-user computers, configure this policy setting to Guest only – local users authenticate as guest.
Potential impact
None. This is the default configuration.
Network security: Allow Local System to use computer identity for NTLM
This policy setting allows Local System services that use SPNEGO (Negotiate) to use the computer identity when reverting to NTLM authentication.
If you enable this policy setting, services running as Local System that use Negotiate will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.
If you do not configure this policy setting, services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. This was the behavior in previous versions of Windows.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
When connecting to computers running versions of Windows earlier than Windows Vista or Windows Server 2008, services running as Local System and using SPNEGO (Negotiate) that revert to NTLM use the computer identity. In Windows Server 2008 R2 or Windows 7, if you are connecting to a computer running Windows Server 2008 or Windows Vista, then a system service uses either the computer identity or a NULL session. When connecting with a NULL session, a system-generated session key is created, which provides no protection but allows applications to sign and encrypt data without errors. When connecting with the computer identity, signing and encryption are supported to provide data protection.
Countermeasure
You can configure the Network security: Allow Local System to use computer identity for NTLM security policy setting to allow Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.
Potential impact
If you do not configure this policy setting, services running as Local System that use the default credentials and a NULL session revert to NTLM authentication for Windows operating systems earlier than Windows Vista or Windows Server 2008. This might cause some authentication requests between Windows operating systems to fail and display an error.
Network security: Allow Local System NULL session fallback
This policy setting controls what values are used when a service connects to different versions of Windows operating systems from computers running Windows Server 2008 R2 and Windows 7.
If Network security: Allow Local System to use computer identity for NTLM is set to disabled, then services running as Local System will fall back to using NULL session authentication when transmitting data to servers running versions of Windows earlier than Windows Vista or Windows Server 2008. NULL session does not establish a unique session key for each authentication and thus cannot provide integrity or confidentiality protection. This setting determines whether services that request the use of these faculties are allowed to perform signature or encryption functions with well-known key for application compatibility.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
If this setting is enabled, then a system-generated session key is created when connecting with a NULL session, which provides no protection but allows applications to sign and encrypt data without errors. Data intended to be protected may be exposed.
Countermeasure
You can configure the computer to use the machine identity for Local System with the policy Network security: Allow Local System to use computer identity for NTLM. If that is not possible, then this policy can be used to prevent data from being exposed in transit that was protected with a well-known key.
Potential impact
If you enable this policy, services that use NULL session with Local System could fail to authenticate because they will be prohibited from using signing and encryption.
This policy applies to Windows Server 2008 and Windows Vista (SP1 and later). When your environment no longer requires support for NT 4, this policy should be disabled. By default it is disabled on Windows 7 and Windows Server 2008 R2.
Network Security: Allow PKU2U authentication requests to this computer to use online identities
This policy setting determines whether the PKU2U authentication protocol requests will be allowed between computers running Windows 7.
If you enable this policy setting, this will allow authentication to successfully complete between the two (or more) computers that have established a peer relationship through the use on online IDs. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer computers. When validated on the peer computer, the certificate within the metadata is sent to the logon peer for validation, and it associates the user's certificate to a security token and the logon process completes.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Enabling this policy setting allows a user account on one computer to be associated with an online identity, such as Windows Live ID, so that the account can log on to a peer computer (if the peer computer is likewise configured) without the use of a Windows logon account (domain or local). Although this can be beneficial for workgroups or home groups, using this feature in a domain might circumvent your established security policies.
Countermeasure
Set this policy to Disabled or do not configure this security policy for all domain-joined computers.
Potential impact
If you disable or do not enable this policy setting, the PKU2U protocol will not be used to authenticate between peer computers, which forces users to follow domain-defined access control policies. If you enable this policy setting, you will allow your users to use PKU2U to authenticate by using local certificates between computers that are not part of a domain. This allows users to share resources between computers.
Network security: Configure encryption types allowed for Kerberos
This policy setting determines which set of encryption types will be allowed for processing Kerberos authentication requests.
Possible values:
DES_CBC_CRC
DES_CBC_MD5
RC4_HMAC_MD5
AES128_HMAC_SHA1
AES256_HMAC_SHA1
Future encryption types
The following table describes these values.
| Value | Description |
|---|---|
DES_CBC_CRC |
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Windows 7 and Windows Server 2008 R2 systems do not support DES by default. |
DES_CBC_MD5 |
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. Windows 7 and Windows Server 2008 R2 systems do not support DES by default. |
RC4_HMAC_MD5 |
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. |
AES128_HMAC_SHA1 |
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. |
AES256_HMAC_SHA1 |
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. |
Future encryption types |
As of the release of Windows Server 2008 R2 and Windows 7, this is reserved by Microsoft for additional encryption types that might be implemented. |
Vulnerability
Windows Server 2008 R2 and Windows 7 do not support the DES cryptographic suites by default because stronger cryptographic suites are available. However, to enable Kerberos protocol interoperability with non-Windows versions of Kerberos, these suites can be enabled. Doing so might open attack vectors on computers running Windows Server 2008 R2 and Windows 7.
Countermeasure
Do not configure this policy setting. This will force computers running Windows Server 2008 R2 and Windows 7 to use the AES or RC4 cryptographic suites. You can also disable DES for your computers running Windows Vista and Windows Server 2008.
Potential impact
If you do not select any of the encryption types, computers running Windows Server 2008 R2 and Windows 7 might have Kerberos protocol authentication failures when connecting with computers running non-Windows versions of Kerberos.
If you do select any encryption type, you will lower the effectiveness of encryption for Kerberos authentication.
Contemporary non-Windows implementations of Kerberos support RC4 and AES 128-bit and AES 256-bit encryption. Most implementations, including MIT Kerberos and Windows Kerberos, are deprecating DES encryption.
Network security: Do not store LAN Manager hash value on next password change
This policy setting determines whether LAN Manager is prevented from storing hash values for the new password the next time the password is changed. Hash values are representation of the password after the encryption algorithm is applied that corresponds to the format specified by the algorithm. To decrypt the hash value, the encryption algorithm must be determined and then reversed. The LAN Manager hash is relatively weak and prone to attack compared to the cryptographically stronger NTLM hash.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
The SAM file can be targeted by attackers who seek access to user name and password hashes. Such attacks use special tools to discover passwords, which can then be used to impersonate users and gain access to resources on your network. These types of attacks are not prevented by enabling this policy setting because LAN Manager hashes are much weaker than NTLM hashes, but it is much more difficult for these attacks to succeed.
Countermeasure
Enable the Network security: Do not store LAN Manager hash value on next password change policy setting. Require that all users set new passwords the next time they log on to the domain so that LAN Manager hashes are removed.
Potential impact
Earlier operating systems such as Windows 95, Windows 98, and Windows Millennium Edition, in addition to some non-Microsoft applications, cannot connect to the system.
Network security: Force logoff when logon hours expire
This policy setting enables or disables the forced disconnection of users who are connected to the local computer outside their user account's valid logon hours. It affects the SMB component. If you enable this policy setting, client sessions with the SMB server are disconnected when the client's logon hours expire. If you disable this policy setting, established client sessions are maintained after the client's logon hours expire.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
If you disable this policy setting, users can remain connected to the computer outside of their allotted logon hours.
Countermeasure
Enable the Network security: Force logoff when logon hours expire policy setting. This policy setting does not apply to administrator accounts.
Potential impact
When a user's logon time expires, SMB sessions terminate. The user cannot log on to the computer until the next scheduled access time commences.
Network security: LAN Manager authentication level
This policy setting determines which challenge/response authentication protocol is used for network logons. LAN Manager allows users to link personal computers together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory uses LAN Manager (LM), NTLM, or NTLM version 2 (NTLMv2).
LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and it is the protocol that is used to authenticate all Windows client computers when they perform the following operations:
Join a domain
Authenticate between Active Directory forests
Authenticate to domains based on earlier versions of Windows
Authenticate to computers that do not run the Windows 2000, Windows Server 2003, Windows Vista, or Windows XP operating systems
Authenticate to computers that are not in the domain
Possible values:
Send LM & NTLM responses
Send LM & NTLM - use NTLMv2 session security if negotiated
Send NTLM responses only
Send NTLMv2 responses only
Send NTLMv2 responses only. Refuse LM
Send NTLMv2 responses only. Refuse LM & NTLM
Not Defined
The Network security: LAN Manager authentication level policy setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that client computers use, the session security level that the computers negotiate, and the authentication level that servers accept. The following table identifies the policy settings, describes the setting, and identifies the security level that is used in the corresponding registry setting if you choose to use the registry to control this setting instead of the policy setting.
| Setting | Description | Registry security level |
|---|---|---|
Send LM & NTLM responses |
Client computers use LM and NTLM authentication, and they never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
0 |
Send LM & NTLM – use NTLMv2 session security if negotiated |
Client computers use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
1 |
Send NTLM response only |
Client computers use NTLM authentication only, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
2 |
Send NTLMv2 response only |
Client computers use NTLMv2 authentication only, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
3 |
Send NTLMv2 response only. Refuse LM |
Client computers use NTLMv2 authentication only, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM authentication, and they will accept only NTLM and NTLMv2 authentication. |
4 |
Send NTLMv2 response only. Refuse LM & NTLM |
Client computers use NTLMv2 authentication only, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM and NTLM authentication, and they will accept only NTLMv2 authentication. |
5 |
Vulnerability
Beginning with Windows Vista, this policy setting is undefined. Beginning with Windows Server 2008, this policy setting is configured to Send NTLMv2 responses only. In Windows 2000, Windows Server 2003, and Windows XP, client computers are configured by default to send LM and NTLM authentication responses (client computers running Windows 95 and Windows 98 send only LM).
The default setting on servers allows all client computers to authenticate with servers and use their resources. However, this means that LM responses—the weakest form of authentication response—are sent over the network, and it is potentially possible for attackers to intercept that traffic to reproduce the user's password more easily.
The Windows 95, Windows 98, and Windows NT operating systems cannot use the Kerberos version 5 protocol for authentication. For this reason, in a Windows Server 2003 domain, these computers authenticate by default with the LM and NTLM protocols for network authentication.
You can enforce a more secure authentication protocol for Windows 95, Windows 98, and Windows NT by using NTLMv2. For the logon process, NTLMv2 uses a secure channel to protect the authentication process. Even if you use NTLMv2 for client computers and servers running these earlier versions of Windows, client computers and servers that are members of the domain use the Kerberos authentication protocol to authenticate with Windows Server 2003 domain controllers.
Countermeasure
Configure the Network security: LAN Manager Authentication Level policy setting to Send NTLMv2 responses only. We and a number of independent organizations strongly recommend this level of authentication when all client computers support NTLMv2.
For more information about how to enable NTLMv2 on earlier versions of Windows, see article 239869 in the Microsoft Knowledge Base. Windows NT 4.0 requires Service Pack 4 (SP4) to support NTLMv2, and the Windows 95 and Windows 98 operating systems need the directory service client installed to support NTLMv2.
Potential impact
Clients that do not support NTLMv2 authentication cannot authenticate in the domain and access domain resources by using LM and NTLM.
Network security: LDAP client signing requirements
This policy setting determines the level of data signing that is requested on behalf of clients that issue LDAP BIND requests. These different levels of data signing are described in the following list:
None. The LDAP BIND request is issued with the caller-specified options.
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 caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.
Require signing. This level 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 returned a message that the LDAP BIND command request failed.
Note
This policy setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. Microsoft LDAP clients do not use ldap_simple_bind or ldap_simple_bind_s to communicate with a domain controller.
Possible values:
None
Negotiate signing
Require signature
Not Defined
Vulnerability
Unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures the packets between the client and server, modifies them, and then forwards them to the server. For an LDAP server, this susceptibility means that an attacker could cause a server to make decisions that are based on false or altered data from the LDAP queries. To lower this risk in your network, you can implement strong physical security measures to protect the network infrastructure. Also, you can make all types of man-in-the-middle attacks extremely difficult if you require digital signatures on all network packets by means of IPsec authentication headers.
Countermeasure
Configure the Network security: LDAP server signing requirements policy setting to Require signature.
Potential impact
If you configure the server to require LDAP signatures, you must also configure the client computer. If you do not configure the client computer, it cannot communicate with the server, which could cause many features to fail, including user authentication, Group Policy, and logon scripts.
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
This policy setting allows a client computer to require the negotiation of 128-bit encryption, or NTLMv2 session security. These values are dependent on the Network security: LAN Manager Authentication Level policy setting value.
Possible values:
Require 128-bit encryption
Require NTLMv2 session security
Not Defined
Vulnerability
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker who has gained access to the network can create man-in-the-middle attacks.
Countermeasure
Enable all options that are available for the Network security: Minimum session security for NTLM SSP based (including secure RPC) clients policy setting.
Potential impact
If this policy setting is configured, client computers that are enforcing these settings cannot communicate with older servers that do not support these settings.
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
This policy 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.
Possible values:
Require message integrity
Require message confidentiality
Require NTLMv2 session security
Require 128-bit encryption
Not Defined
Vulnerability
Network traffic that uses the NTLM Security Support Provider (NTLM SSP) could be exposed such that an attacker who has gained access to the network can create man-in-the-middle attacks.
Countermeasure
Enable all four options that are available for the Network security: Minimum session security for NTLM SSP based (including secure RPC) servers policy setting.
Potential impact
If this policy setting is configured, older client computers that do not support these security settings cannot communicate with this computer.
Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication
This policy setting allows you to create an exception list of remote servers to which client computers are allowed to use NTLM authentication if any of the deny options are set in the Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers policy setting.
When you can enter a list of remote servers to which client computers are allowed to use NTLM authentication, the policy is defined and enabled.
Possible values:
User-defined list of remote servers
Not Defined
Vulnerability
When it has been determined that the NTLM authentication protocol should not be used from a client to any remote servers because you are required to use a more secure protocol, such as Kerberos protocol, there might be some applications on the client computer that still use NTLM. If so, and you set Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers to any of the Deny options, those applications will fail because the outbound NTLM authentication traffic from the client computer will be blocked.
If you define an exception list of servers to which client computers are allowed to use NTLM authentication, then NTLM authentication traffic will continue to flow between the servers and those applications on the client computers. The servers then are vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM.
Countermeasure
When you use Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers in audit-only mode, you can determine by reviewing which applications on the client computers are making NTLM authentication requests to the remote servers in your environment. When assessed, you will have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements. If not, then the application has to be upgraded to use something other than NTLM authentication.
Potential impact
Defining a list of servers for this policy setting will enable NTLM authentication traffic from the application on the client computer that uses those servers, and this might result in a security vulnerability.
If this list is not defined and Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers is enabled, then applications on client computers that use NTLM will fail to authenticate to those servers that they have used in the past.
Network security: Restrict NTLM: Add server exceptions in this domain
This policy setting allows you to create an exception list of servers in this domain to which client computers are allowed to use NTLM pass-through authentication if any of the deny options are set in the Network Security: Restrict NTLM: NTLM authentication in this domain policy setting.
When you enter a list of remote servers to which clients are allowed to use NTLM authentication, the policy is defined and enabled.
Possible values:
User-defined list of servers to which clients are allowed to use NTLM authentication
Not Defined
Vulnerability
When it has been determined that the NTLM authentication protocol should not be used within a domain because you are required to use a more secure protocol, such as Kerberos protocol, there might be some client applications that still use NTLM. If so, and you set Network Security: Restrict NTLM: NTLM authentication in this domain to any of the Deny options, those applications will fail because the outbound NTLM authentication traffic from the client will be blocked.
If you define an exception list of servers in this domain to which client computers are allowed to use NTLM pass-through authentication, then NTLM authentication traffic will continue to flow between the servers and those applications on the client computers. The servers then are vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM.
Countermeasure
When you use Network Security: Restrict NTLM: NTLM authentication in this domain in audit-only mode, you can determine by reviewing which applications on the client computers are making NTLM authentication requests to the pass-through authentication servers. When assessed, you will have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements. If not, then the application has to be upgraded to use something other than NTLM authentication.
Potential impact
Defining a list of servers for this policy setting will enable NTLM authentication traffic between those servers and any application on the client computer that uses those servers and might result in asecurity vulnerability.
If this list is not defined and Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers is enabled, then applications on the client computers that use NTLM will fail to authenticate to those servers that they have used in the past.
Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
This policy setting allows you to audit a member or remote server for NTLM traffic that is coming in from client computer-based services. The policy works in conjunction with the Network Security: Restrict NTLM: Incoming NTLM traffic policy setting that restricts the traffic.
Possible values:
Disable
Enable auditing for domain accounts
Enable auditing for all accounts
Not Defined
Vulnerability
Enabling this policy setting will reveal through logging which servers and client computers within your network or domain handle NTLM traffic. The identity of these computers can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting does not prevent or mitigate any vulnerability because it is for audit purposes only.
Countermeasure
Restrict access to the log files when this policy setting is enabled in your production environment.
Potential impact
If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
Network Security: Restrict NTLM: Audit NTLM authentication in this domain
This policy setting allows you to audit NTLM authentication requests that come from member servers to a domain controller. The policy setting works in conjunction with the Network security: Restrict NTLM: NTLM authentication in this domain policy setting that restricts the traffic.
Possible values:
Disable
Enable for domain accounts to domain servers
Enable for domain accounts
Not Defined
Vulnerability
Enabling this policy setting will reveal through logging which servers and client computers within your network or domain handle NTLM traffic. The identity of these computers can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting does not prevent or mitigate any vulnerability because it is for audit purposes only.
Countermeasure
Restrict access to the log files when this policy setting is enabled in your production environment.
Potential impact
If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
Network Security: Restrict NTLM: Incoming NTLM traffic
This policy setting allows you to deny or allow NTLM traffic on the targeted server that is coming from client computers, other member servers, or a domain controller.
Possible values:
Allow all
Deny all domain accounts
Deny all accounts
Not Defined
Vulnerability
Malicious attacks on NTLM authentication traffic resulting in a compromised server can occur only if the server handles NTLM requests. If those requests are denied, this attack vector is eliminated.
Countermeasure
When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol, such as Kerberos protocol, you can select from several options based on your security goals to restrict NTLM usage.
Potential impact
If you configure this policy setting, numerous NTLM authentication requests could fail within your network, which could degrade productivity. Before implementing this change through this policy setting, set Network security: Restrict NTLM: Audit Incoming NTLM Traffic to the same option so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from the Network security: Restrict NTLM: Add server exceptions in this domain policy setting.
Network Security: Restrict NTLM: NTLM authentication in this domain
This policy setting allows you to deny or allow NTLM authentication within a domain from this domain controller. This policy setting does not affect interactive logon to this domain controller.
Possible values:
Disable
Deny for domain accounts to domain servers
Deny for domain accounts
Deny for domain servers
Deny all
Not Defined
Vulnerability
Malicious attacks on NTLM authentication traffic resulting in a compromised server or domain controller can occur only if the server or domain controller handles NTLM requests. If those requests are denied, this attack vector is eliminated.
Countermeasure
When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol, such as the Kerberos protocol, then you can select from several options based on your security goals to restrict NTLM usage within the domain.
Potential impact
If you configure this policy setting, numerous NTLM authentication requests could fail within the domain, which could decrease productivity. Before implementing this change through this policy setting, set Network security: Restrict NTLM: Audit NTLM authentication in this domain to the same option so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy setting by using Network security: Restrict NTLM: Add server exceptions in this domain.
Audited and blocked events are recorded on this computer in the Operational log located in Applications and Services Log\Microsoft\Windows\NTLM.
Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers
This policy setting allows you to deny or audit outgoing NTLM traffic from a computer running Windows 7 or Windows Server 2008 R2 to any remote server running the Windows operating system.
Possible values:
Allow all
Audit all
Deny all
Not Defined
Vulnerability
Malicious attacks on NTLM authentication traffic resulting in a compromised server or domain controller can occur only if the server or domain controller handles NTLM requests. If those requests are denied, this attack vector is eliminated.
Countermeasure
When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol, such as Kerberos protocol, you can select from several options, based on your security goals, to restrict NTLM usage to servers.
Potential impact
If you configure this policy setting to deny all requests, numerous NTLM authentication requests to remote servers could fail, which could decrease productivity. Before implementing this restriction through this policy setting, select Audit all so that you can review the log for the potential impact, perform an analysis of servers, and create an exception list of servers to exclude from this policy by using Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication.
Audited and blocked events are recorded on this computer in the Operational log located in Applications and Services Log\Microsoft\Windows\NTLM.
Recovery console: Allow automatic administrative logon
This policy setting determines whether the Administrator account password must be provided before access to the computer is granted. If you enable this policy setting, the Administrator account is automatically logged on to the computer at the Recovery Console; no password is required.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
The Recovery Console can be very useful when you must troubleshoot and repair computers that do not start. However, allowing automatic logon to the Recovery Console can make it possible for someone to assume full control of the server.
Countermeasure
Disable the Recovery console: Allow automatic administrative logon policy setting.
Potential impact
Users must enter a user name and password to access the Recovery Console.
Recovery console: Allow floppy copy and access to all drives and all folders
This policy setting enables or disables the Recovery Console SET command, which allows you to set the following Recovery Console environment variables:
AllowWildCards. Enables wildcard support for some commands, such as the DEL command.
AllowAllPaths. Allows access to all files and folders on the computer.
AllowRemovableMedia. Allows files to be copied to removable media, such as a floppy disk.
NoCopyPrompt. Suppresses the prompt that typically displays before an existing file is overwritten.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
An attacker who can cause the system to restart into the Recovery Console could steal sensitive data and leave no audit or access trail.
Countermeasure
Disable the Recovery console: Allow floppy copy and access to drives and folders policy setting.
Potential impact
Users who have started a server through the Recovery Console and logged on with the built-in Administrator account cannot copy files and folders to a floppy disk.
Shutdown: Allow system to be shut down without having to log on
This policy setting determines whether a computer can be shut down without having to log on to Windows. If you enable this policy setting, the Shut down command is available on the Windows logon screen. If you disable this policy setting, the Shut down command is removed from the Windows logon screen. This configuration requires that users are able to log on to the computer successfully and they have the Shut down the system user right before they can perform a computer shutdown.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Users who can access the console locally could shut down the computer.
Attackers who have access to the local console could restart the server, which would cause a temporary DoS condition. Attackers could also shut down the server and leave all of its applications and services unavailable.
Countermeasure
Disable the Shutdown: Allow system to be shut down without having to log on policy setting.
Potential impact
Operators must log on to servers to shut them down or restart them.
Shutdown: Clear virtual memory pagefile
This policy setting determines whether the virtual memory paging file is cleared when the computer is shut down. Virtual memory support uses a system paging file to swap pages of memory to disk when they are not used. On a running computer, this paging file is opened exclusively by the operating system, and it is well protected. However, computers that are configured to allow other operating systems to start should verify that the system paging file is cleared as the computer shuts down. This confirmation ensures that sensitive information from process memory that might be placed in the paging file is not available to an unauthorized user who manages to directly access the paging file after shutdown.
When you enable this policy setting, the system paging file is cleared when the system shuts down normally. Also, this policy setting forces the computer to clear the hibernation file (hiberfil.sys) when hibernation is disabled on a portable computer.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Important information that is kept in real memory may be written periodically to the paging file to help the operating system handle multitasking functions. An attacker who has physical access to a server that has been shut down could view the contents of the paging file. The attacker could move the system volume into a different computer and then analyze the contents of the paging file. Although this process is time consuming, it could expose data that is cached from random access memory (RAM) to the paging file.
Warning
An attacker who has physical access to the computer could bypass this countermeasure by unplugging the computer from its power source.
Countermeasure
Enable the Shutdown: Clear virtual memory pagefile when system shuts down policy setting. This configuration causes the operating system to clear the pagefile when the computer is shut down. The amount of time that is required to complete this process depends on the size of the pagefile. Because the process overwrites the storage area used by the pagefile several times, it could be several minutes before the computer completely shuts down.
Potential impact
It takes longer to shut down and restart the computer, especially on computers with large paging files. For a computer with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy setting could increase the shutdown process by 20 to 30 minutes, or more. For some organizations this downtime violates their internal service level agreements. Therefore, use caution before you implement this countermeasure in your environment.
System cryptography: Force strong key protection for user keys stored on the computer
This policy setting determines whether users can use private keys, such as their Secure/Multipurpose Internet Mail Extensions (S/MIME) key, without a password.
Possible values:
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
Not Defined
Vulnerability
If a user's account is compromised or the user's computer is inadvertently left unsecured, the malicious user can use the keys that are stored for the user to access protected resources.
Countermeasure
Configure the System cryptography: Force strong key protection for user keys stored on the computer policy setting to User must enter a password each time they use a key so that users must provide a password that is distinct from their domain password every time they use a key. This configuration makes it more difficult for an attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines the logon password.
Potential impact
Users must type their password every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to digitally sign their email, they are forced to type the password for that certificate every time they send a signed email message. For some organizations, the overhead that is involved by using this configuration may be too high. At a minimum, this policy setting should be set to User is prompted when the key is first used.
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
This policy setting determines whether the TLS/SSL Security Support Provider supports only the Federal Information Processing Standard (FIPS)-compliant strong cipher suite known as TLS_RSA_WITH_3DES_EDE_CBC_SHA, which means that the provider only supports the TLS protocol as a client and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements.
When this policy setting is enabled, the Encrypting File System (EFS) service supports only the 3DES encryption algorithm for encrypting file data. By default, the implementation of EFS beginning with Windows Server 2003 uses the Advanced Encryption Standard (AES) with a 256-bit key.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
You can enable this policy setting to ensure that the computer uses the most powerful algorithms that are available for digital encryption, hashing, and signing. Use of these algorithms minimizes the risk of compromise of digitally encrypted or signed data by an unauthorized user.
Countermeasure
Enable the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing policy setting.
Potential impact
Client computers that have this policy setting enabled cannot communicate by means of digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms cannot use servers that require the algorithms for network communications. For example, many Apache-based Web servers are not configured to support TLS. If you enable this policy setting, you must also configure your Web browser to use TLS.
This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool uses the RDP to communicate with servers that run Remote Desktop Services or Terminal Services and client computers that are configured for remote control. RDP connections fail if both computers are not configured to use the same encryption algorithms.
System objects: Default owner for objects created by members of the Administrators group
This policy setting determines whether the Administrators group or an object creator is the default owner of any system objects that are created.
Possible values:
Administrators group
Object creator
Not Defined
Vulnerability
If you configure this policy setting to the Administrators group, it is impossible to hold individuals accountable for the creation of new system objects.
Countermeasure
Configure the System objects: Default owner for objects created by members of the Administrators group policy setting to Object creator.
Potential impact
When system objects are created, the ownership reflects which account created the object instead of the more generic Administrators group. A consequence of this policy setting is that objects become orphaned when user accounts are deleted. For example, when a member of the information technology group leaves, any objects that they created anywhere in the domain have no owner.
This situation could become an administrative burden because administrators must manually take ownership of orphaned objects to update their permissions. This potential burden can be minimized if you can ensure that Full Control is always assigned to new objects for a domain group such as Domain Admins.
System objects: Require case insensitivity for non-Windows subsystems
This policy setting enables or disables the enforcement of case insensitivity for all subsystems. The Microsoft Win32® subsystem is case-insensitive. However, the kernel supports case sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). If you enable this policy setting, case insensitivity is enforced for all directory objects, symbolic links, IO, and file objects. If you disable this policy setting, case insensitivity is not enforced, but the Win32 subsystem does not become case sensitive.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Because Windows is case insensitive but the POSIX subsystem supports case sensitivity, failure to enable this policy setting makes it possible for a user of that subsystem to create a file with the same name as another file but with a different mix of uppercase and lowercase letters. Such a situation could potentially confuse users when they try to access such files from normal Win32 tools because only one of the files is available.
Countermeasure
Enable the System objects: Require case insensitivity for non-Windows subsystems policy setting.
Potential impact
All subsystems are forced to observe case insensitivity. This configuration may confuse users who are familiar with any UNIX-based operating systems that are case sensitive.
System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)
This policy setting determines the strength of the default DACL for objects. The Windows operating system maintains a global list of shared computer resources (such as MS-DOS device names, mutexes, and semaphores) so that 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 with what permissions. If you enable this policy setting, the default DACL is strengthened because non-administrator users are allowed to read shared objects but not modify shared objects that they did not create.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
This policy setting is enabled by default to protect against a known vulnerability that can be used with hard links or symbolic links. Hard links are actual directory entries in the file system. With hard links, the same data in a file system can be referred to by different file names. Symbolic links are text files that provide a pointer to the file that is interpreted and followed by the operating system as a path to another file or directory.
Because symbolic links are a separate file, they can exist independently of the target location. If a symbolic link is deleted, its target location remains unaffected. When this policy setting is disabled, it is possible for a malicious user to destroy a data file by creating a link that looks like a temporary file that the system automatically creates, such as a sequentially named log file, but points to the data file that the malicious user wants to eradicate. When the system writes the files with that name, the data is overwritten.
Enabling System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links) prevents an attacker from exploiting programs that create files with predictable names by not allowing them to write to objects that they did not create.
Countermeasure
Enable the System objects: Strengthen default permissions of global system objects (e.g., Symbolic Links) policy setting.
Potential impact
None. This is the default configuration.
System settings: Optional subsystems
This policy setting determines which subsystems support your applications. You can use this security setting to specify as many subsystems as your environment demands.
Possible values:
User-defined list of subsystems
Not Defined
Vulnerability
The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The POSIX subsystem is required if the server supports applications that use that subsystem.
The POSIX subsystem introduces a security risk that relates to processes that can potentially persist across logons. If a user starts a process and then logs out, there is a potential that the next user who logs on to the computer could access the previous user's process. This would allow the second user to take actions on the process by using the privileges of the first user.
Countermeasure
Configure the System settings: Optional subsystems setting to a null value. The default value is POSIX.
Potential impact
Applications that rely on the POSIX subsystem no longer operate. For example, Microsoft Services for Unix (SFU) installs an updated version of the POSIX subsystem that is required, so you must reconfigure this setting in Group Policy for any servers that use SFU.
System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies
This policy setting determines whether digital certificates are processed when software restriction policies are enabled and a user or process attempts to run software with an .exe file name extension. This security setting enables or disables certificate rules (a type of software restriction policies rule). With software restriction policies, you can create a certificate rule that allows or disallows Microsoft Authenticode®-signed software to run, based on the digital certificate that is associated with the software. For certificate rules to work in software restriction policies, you must enable this security setting.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Without the use of software restriction policies, users and computers might be exposed to the running of unauthorized software that could include malicious software such as viruses and Trojan horses.
Countermeasure
Enable the System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies policy setting.
Potential impact
If you enable certificate rules, software restriction policies check a certificate revocation list (CRL) to verify that the software's certificate and signature are valid. This checking process may negatively affect performance when signed programs start. To disable this feature, you can edit the software restriction policies in the appropriate GPO. On the Trusted Publishers Properties dialog box, clear the Publisher and Timestamp check boxes.
User Account Control: Admin Approval Mode for the Built-in Administrator account
This policy setting determines the behavior of Admin Approval mode for the built-in Administrator account.
Possible values:
Enabled
Disabled
When this policy setting is enabled, the built-in Administrator account logs on in Admin Approval Mode. In this mode, the local Administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege.
When this policy setting is disabled, the built-in Administrator account logs on in XP-compatible mode, and it runs all applications by default with full administrative privileges. By default, this policy setting is set to Disabled. However, if a computer is upgraded from a previous version of Windows to Windows 7 and the Administrator account is the only account on the computer, the built-in Administrator account remains enabled, and this policy setting is also enabled.
Vulnerability
One of the risks that User Account Control (UAC) is intended to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. An attack vector for malicious programs is to discover the password of the Administrator account because that user account was created for all installations of the Windows operating system. To address this risk, the built-in Administrator account is disabled in Windows 7. In Windows Server 2008 R2, the Administrator account is enabled, and the password must be changed the first time the administrator logs on. In a default installation of Windows 7, accounts with administrative control over the computer are initially set up in one of two ways:
If the computer is not joined to a domain, the first user account you create has the equivalent permissions as a local administrator.
If the computer is joined to a domain, no local administrator accounts are created. The enterprise or domain administrator must log on to the computer and create a local administrator account if one is warranted.
After Windows 7 is installed, the built-in Administrator account can be enabled, but we strongly recommend that this account remain disabled.
Countermeasure
Enable the User Account Control: Admin Approval Mode for the Built-in Administrator account policy setting if you have the built-in Administrator account enabled.
Potential impact
Users who log on by using the local Administrator account are prompted for consent whenever a program requests an elevation in privilege.
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop
This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts that are being used by a standard user.
Note
This policy setting does not change the behavior of the UAC elevation prompt for administrators.
Possible values:
Enabled
Disabled or Not Configured
When this policy setting is enabled, UIA programs including Windows Remote Assistance can automatically disable the secure desktop for elevation prompts. Unless you have also disabled elevation prompts, the prompts appear on the interactive user's desktop instead of the secure desktop, and they appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator can provide the appropriate credentials for elevation.
If you plan to enable this policy setting, you should also review the effect of the User Account Control: Behavior of the elevation prompt for standard users policy setting. If it is configured as Automatically deny elevation requests, elevation requests are not presented to the user. If you disable this policy 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 policy setting. By default, this policy setting is set to Enabled.
Vulnerability
UIA programs are designed to interact with the Windows operating system and with application programs on behalf of a user. This policy 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 the risk that a malicious program could intercept data that is being transferred between the UI and the application.
Because UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. 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, including subfolders
Program Files (x86), including 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 policy setting. Although this policy setting applies to any UIA program, it is used primarily in certain Windows Remote Assistance scenarios. The Windows Remote Assistance program is a UIA program.
Countermeasure
Disable the User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop policy setting.
Potential impact
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 can 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 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.
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
This policy setting determines the behavior of the elevation prompt for accounts that have administrative credentials.
Possible values:
Elevate without prompting
Prompt for credentials
Prompt for consent
The default value for this policy setting is Prompt for consent.
Vulnerability
One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. This policy setting notifies the administrator of elevated privilege operations and permits the administrator to prevent a malicious program from elevating its privilege when the program attempts to do so.
Countermeasure
Configure the User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode policy setting to Prompt for consent.
Potential impact
This is the default behavior. Administrators should be made aware that they will be prompted for consent.
User Account Control: Behavior of the elevation prompt for standard users
This policy setting determines the behavior of the elevation prompt for standard users.
Possible values:
Automatically deny elevation requests
Prompt for credentials
The default configuration for this policy setting is Prompt for credentials.
Vulnerability
One of the risks that UAC tries to mitigate is that of malicious programs running under elevated credentials without the user or administrator being aware of their activity. This policy setting notifies the user that a program requires the use of elevated privilege operations, and it requires that the user be able to supply administrative credentials for the program to run.
Countermeasure
Configure the User Account Control: Behavior of the elevation prompt for standard users to Automatically deny elevation requests. This policy setting requires the user to log on with an administrative account to run programs that require elevation of privilege. As a security best practice, standard users should not have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, we recommend setting Prompt for credentials so that the users do not choose to always log on with their administrator accounts, and they use the standard user account instead.
Potential impact
Users must provide administrative passwords to run programs with elevated privileges. This could cause an increased load on IT staff while the programs that are affected are identified and standard operating procedures are modified to support least privilege operations.
User Account Control: Detect application installations and prompt for elevation
This policy setting determines the behavior of application installation detection for the entire system. If this policy setting is enabled, application installation packages that require an elevation of privilege to install are detected and the user is prompted for administrative credentials.
Enterprises that are running standard user desktops that capitalize on delegated installation technologies (such as Group Policy Software Install (GPSI) or SMS) can disable this feature. In this case, installer detection is unnecessary and it is not required.
Possible values:
Enabled
Disabled
The default configuration for this policy setting is Enabled.
Vulnerability
Some malicious software may attempt to install itself after being given permission to run, for example, malicious software with a trusted application shell. The user may give permission for the program to run because the program is trusted and is then prompted for installation of an unknown component. This provides another way to trap the software before it can do damage.
Countermeasure
Enable the User Account Control: Detect application installations and prompt for elevation policy setting.
Potential impact
Users must provide administrative passwords to install programs.
User Account Control: Only elevate executables that are signed and validated
This policy setting enforces public key infrastructure (PKI) signature checks on any interactive application that requests elevation of privilege. Enterprise administrators can control the applications that are allowed to run through the population of certificates in the local computer's Trusted Publishers store. If this policy setting is enabled, the PKI certificate chain validation of a given executable file is enforced before it is permitted to run.
Possible values:
Enabled
Disabled
The default configuration for this policy setting is Disabled.
Vulnerability
Intellectual property, personally identifiable information, and other confidential data is normally manipulated by applications on the computer, and elevated credentials are required to get access to the information. Users and administrators inherently trust applications that are used with these information sources and provide their credentials. If one of these applications is replaced by a rogue application that appears identical to the trusted application, the confidential data and the user's administrative credentials could be compromised.
Countermeasure
Enable the User Account Control: Only elevate executables that are signed and validated policy setting.
Potential impact
Enabling this policy setting requires that you have a PKI and that your enterprise administrators have populated the Trusted Publishers store with the certificates for the allowed applications. Some older applications are not signed, and they cannot be used in an environment that is hardened with this policy setting.
You should carefully test your applications in a preproduction environment before implementing this policy setting. For information about the steps that are required to test application compatibility, make application compatibility fixes, and sign installer packages to prepare your organization for UAC deployment, see Understanding and Configuring User Account Control in Windows Vista.
Control over the applications that are installed on the desktop and the hardware that joins your domain should provide similar protection from the vulnerability that is addressed by this policy setting. Additionally, the level of protection that is provided by this policy setting is not an assurance that all rogue applications will be found.
User Account Control: Only elevate UIAccess applications that are installed in secure locations
This policy setting enforces the requirement that applications that request running with a UIAccess integrity level (by means of a marking of UIAccess=true in their application manifest), must reside in a secure location on the file system. Relatively 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
The Windows operating system enforces a PKI signature check on any interactive application that requests running with a UIAccess integrity level regardless of the state of this security setting.
Possible values:
Enabled
Disabled
The default configuration for this policy setting is Enabled.
Vulnerability
UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this policy setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability is required to support accessibility features (such as screen readers) that are transmitting user interfaces to alternative forms, but it is not required by most applications. A process that is started with UIAccess rights has the following capabilities:
To set the foreground window.
To drive any application window by using the SendInput function.
To use read input for all integrity levels by using low-level hooks, raw input, GetKeyState, GetAsyncKeyState, and GetKeyboardInput.
To set journal hooks.
To use AttachThreadInput to attach a thread to a higher integrity input queue.
Countermeasure
Enable the User Account Control: Only elevate UIAccess applications that are installed in secure locations policy setting.
Potential impact
If the application that requests UIAccess meets the UIAccess policy setting requirements, the application can bypass most of the UIPI restrictions. If the application does not meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level.
User Account Control: Run all administrators in Admin Approval Mode
This policy setting determines the behavior of all UAC policies for the entire system. Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this policy setting requires restarting the computer.
Possible values:
Enabled
Disabled
Note
If this security setting is configured to Disabled, the Security Center notifies the user that the overall security of the operating system has been reduced.
The default configuration for this policy setting is Enabled.
Vulnerability
This policy setting turns UAC on or off. If this setting is disabled, UAC is not used, and any security benefits and risk mitigations that are dependent on UAC are not present on the system.
Countermeasure
Enable the User Account Control: Run all users, including administrators, as standard users policy setting.
Potential impact
Users and administrators must learn to work with UAC prompts and adjust their work habits to use least privilege operations.
User Account Control: Switch to the secure desktop when prompting for elevation
This policy setting determines whether the elevation request prompts appears on the interactive user desktop or the secure desktop.
Possible values:
Enabled
Disabled
The default configuration for this policy setting is Enabled.
Vulnerability
Elevation prompt dialog boxes can be spoofed, causing users to disclose their passwords to malicious software.
Countermeasure
Enable the User Account Control: Switch to the secure desktop when prompting for elevation policy setting. The secure desktop helps protect against input and output spoofing by presenting the credentials dialog box in a protected section of memory that is accessible only by trusted system processes.
Potential impact
None. This is the default configuration.
User Account Control: Virtualize file and registry write failures to per-user locations
This policy setting enables or disables redirecting the Write failures of earlier applications to defined locations in 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 HKEY_LOCAL_MACHINE\Software\.
Virtualization facilitates the running of applications that cannot run with standard user privileges. An administrator who runs only standard user applications may choose to disable this feature because it is unnecessary.
Possible values:
Enabled
Disabled
The default configuration for this policy setting is Enabled.
Vulnerability
Earlier applications might not write data to secure locations.
Countermeasure
Enable the User Account Control: Virtualize file and registry write failures to per-user locations policy setting.
Potential impact
None. This is the default configuration.