Security Options
Applies To: Windows Server 2008
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 settings in the following location within either 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) syntax
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
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: 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
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 and 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: Do not store LAN Manager hash value on next password change
Network security: Force logoff when logon hours expire
Network security: LAN Manager authentication level
Network security: LDAP client signing requirements
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
Recovery console: Allow automatic administrative logon
Recovery console: Allow floppy copy and access to all drives and 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: 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. Also, 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 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 re-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 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, such as those performed by the Microsoft Network Server (SMB Service), fail. This policy setting should have little impact on most organizations because it is the default setting in Microsoft Windows® 2000, Windows® XP, Windows Vista®, Windows Server® 2008, and Windows Server® 2003 operating systems.
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, 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 should be forbidden through both organizational policy and suitable technical measures. In fact, the default settings for Windows Server 2003 and Windows Server 2008Active 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 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
The Administrator account exists on all computers that run the Windows Server 2008, Windows Server 2003, Windows 2000, or Windows XP Professional operating systems. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination. In Windows Vista, the person 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 Vista installations. If a computer is upgraded from a previous version of Windows to Windows Vista, the account with the name Administrator is retained with all rights and privileges that were defined for the account in the previous installation.
The built-in Administrator account cannot be locked out, regardless of how many times an attacker might use a bad 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 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 setting assumes that the Administrator account was not disabled.)
Accounts: Rename guest account
This policy setting determines the account name is associated with the SID for the Guest account.
Possible values:
User-defined text
Not Defined
Vulnerability
The Guest account exists on all computers that run the Windows 2000, Windows Server 2003, Windows XP Professional, Windows Server 2008, or Windows Vista operating systems. Because the account name is well known, it provides a vector for a malicious user to get access to 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 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 in Windows 2000, Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008.
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, visible to all processes on the computer. These objects all have a security descriptor but typically have a NULL SACL. If you enable this policy setting at startup time, 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 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 setting.
Potential impact
If you enable the Audit: Audit the access of global system objects 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 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 setting, any exercise of user rights is recorded in the Security log. If you disable this policy setting, actions by users of 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 backups 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 setting. Alternatively, implement automatic log backup by configuring the AutoBackupLogFiles registry key. If you enable this option when the Audit privilege use 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, "The event log stops logging events before reaching the maximum log size", in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=100879).
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
Windows Vista and Windows Server 2008 allow audit policy to be managed in a more precise way by using audit policy subcategories. Setting audit policy at the category level overrides the new subcategory audit policy feature. The registry value SCENoApplyLegacyAuditPolicy, allows audit policy to be managed by using subcategories without requiring a change to Group Policy. This registry value can be set to prevent the application of category-level audit policy from Group Policy and from the Local Security Policy administrative tool.
In Windows Vista and Windows Server 2008 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 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 Network Policy Servers. |
No Auditing |
Logon/Logoff–Other Logon/Logoff Events |
Reports other logon/logoff-related events, such as disconnecting and reconnecting to 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 matching 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 matching 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 matching 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 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 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–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 audit policy including SACL changes. |
Success |
Policy Change–Authentication Policy Change |
Reports changes in authentication policy. |
Success |
Policy Change–Authorization Policy Change |
Reports changes in authorization policy including permissions (DACL) changes. |
No Auditing |
Policy Change–MPSSVC Rule-Level Policy Change |
Reports changes in policy rules 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 Windows Filtering Platform (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). DS Change 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 on 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 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 tickets submitted for a user account logon request. |
No Auditing |
Account Logon–Other Account Logon Events |
Reports the events that occur in response to credentials submitted for a user account logon request. These events do not relate to credential validation or Kerberos tickets, as those events have separate sub-categories that can be audited) |
No Auditing |
Account Logon–Credential Validation |
Reports the results of validation tests on credentials 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 available in Windows Vista and Windows Server 2008 are not exposed in the interface of Group Policy tools. Administrators can deploy a custom audit policy that applies detailed security auditing settings to Windows Vista–based or Windows Server 2008 computers in a Windows Server 2008, Windows Server 2003, or Windows 2000 domain. If you attempt to modify an auditing setting by using Group Policy after enabling 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 either 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 message 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 either Do Not Overwrite Events or Overwrite Events by Days.
When this policy setting is enabled, the following Stop message 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 to Enabled.
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 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 (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) syntax
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 as an additional access check call that is done 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 in order 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 general authorization policy that applies to all COM servers on the computer.
This policy setting allows you to specify an ACL in two different ways. You can type in 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 contents that you want to apply with this setting.
The default ACL settings vary, depending on the version of Windows you are running. To learn more about ACLs, see the following resources:
In Windows Vista these ACLs are modified to provide support for User Account Control. For an overview of these changes, see New ACLs Improve Security in Windows Vista (https://go.microsoft.com/fwlink/?LinkId=100880).
For information about the changes in Access Control in Windows Server 2008, see What’s New for Access Control in Windows Server 2008.
Vulnerability
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity) but use weak settings that often allow unauthenticated access to the process. Administrators cannot override these settings to force stronger security in earlier versions of Windows 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 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) syntax 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 it does not, 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) syntax
This policy setting is similar to the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax 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 as an additional access check call that is done 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 in order to launch any COM server on the computer. The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy 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 general authorization policy that applies to all COM servers on the computer.
The DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL) syntax setting allows you to specify an ACL in two different 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 contents that you want to apply with this setting.
The default ACL settings vary, depending on the version of Windows you are running. To learn more about ACLs, see the following resources:
In Windows Vista these ACLs are modified to provide support for User Account Control. For an overview of these changes, see https://go.microsoft.com/fwlink/?LinkId=100880.
For information about the changes in Access Control in Windows Server 2008 see What’s New for Access Control in Windows Server 2008.
Vulnerability
Many COM applications include some security-specific code (for example, to call CoInitializeSecurity) but use weak settings that often allow unauthenticated access to the process. Administrators cannot override these settings to force stronger security in earlier versions of Windows 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 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 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 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 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 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 and Power Users 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 setting.
Potential impact
Only users with Administrative, Power User, or Server Operator privileges 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 both 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 setting.
Potential impact
Users who connect to the server over the network cannot use any CD drives that are installed on the server whenever anyone 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 jukebox for network users.
Devices: Restrict floppy access to locally logged-on user only
This policy setting determines whether removable floppy disks are accessible to both 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 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 setting.
Potential impact
Users who connect to the server over the network cannot use any floppy disk drives that are installed on the server whenever anyone 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 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 SYSTEM 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 setting.
Potential impact
The impact should be small for most organizations. Users (including those in the Server Operators group) can still b create jobs by means of the Task Scheduler snap-in. However, those jobs run in the context of the account that the user authenticates with 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. Data signatures are not required to bind with the server. If the client requests data signing, the server supports it.
Require signature. The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is in use.
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), 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 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 the blocking of 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 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) 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, Windows–based computers 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) 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 must run Microsoft Windows NT® 4.0 with Service Pack 6a (SP6a) or a later version of the Windows operating system.
If you enable the Domain member: Digitally encrypt or sign secure channel data (always) setting, the Domain member: Digitally sign secure channel data (when possible) 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 that 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 when possible.
Enable the Domain member: Digitally encrypt or sign secure channel data (always) setting.
Enable the Domain member: Digitally encrypt secure channel data (when possible) setting.
Enable the Domain member: Digitally sign secure channel data (when possible) setting.
Potential impact
Using both digital encryption and signing of the secure channel is a good idea where it is supported. The secure channel protects domain credentials as they are sent to the domain controller. However, only Windows NT 4.0 with SP6a and subsequent versions of the Windows operating system support digital encryption and signing of the secure channel. Microsoft Windows® 98 Second Edition clients do not support it unless they have the Dsclient installed. Therefore, you cannot enable the Domain member: Digitally encrypt or sign secure channel data (always) setting on domain controllers that support Windows 98 clients as members of the domain. Potential impacts can include the following:
The ability to create or delete trust relationships with clients running versions of Windows earlier than Windows NT 4.0 with SP6a is disabled.
Logons from clients running versions of Windows earlier than Windows NT 4.0 with SP6a are disabled.
The ability to authenticate other domains' users from a domain controller running a version of Windows earlier than Windows NT 4.0 with SP6a in a trusted domain is disabled.
You can enable this policy setting after you eliminate all Windows 9x clients 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 other two 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 them and clients 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 the blocking of 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 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, between the domain controllers themselves. 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 stockpile 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 configuration for Windows Server 2008–based computers that belong to a domain automatically require them to change the passwords for their accounts every 30 days. If you disable this policy setting, computers that run Windows Server 2008 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 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–based domains, each computer has an account and password just as every user does. 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 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. In other words, all such domain controllers must run Windows 2000 or a later version of the Windows operating system.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Session keys that are used to establish secure channel communications between domain controllers and member computers are much stronger in Windows 2000 than they were in previous Windows operating systems.
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 be redirected.)
Countermeasure
Enable the Domain member: Require strong (Windows 2000 or later) session key setting.
If you enable this policy setting, all outgoing secure channel traffic requires a strong, Windows 2000 or later 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. Also, computers that do not support this policy setting cannot join domains in which the domain controllers have this policy setting enabled.
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 laptop 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 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 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 use a smart card, a tamper-proof device that stores security information, to log on.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
This setting makes it easier for users with certain types of physical impairments to log on to computers that run Windows. 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 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 setting.
Potential impact
Unless they use a smart card to log on, users must simultaneously press the three keys before the logon dialog box displays.
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 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
Windows Vista and Windows XP Professional support logon banners that can exceed 512 characters in length and that can also contain carriage-return line-feed sequences. However, Windows 2000-based clients cannot interpret and display these messages. You must use a Windows 2000-based computer to create a logon message policy that applies to Windows 2000-based computers. If you inadvertently create a logon message policy on a Windows Vista-based or Windows XP Professional-based computer and you discover that it does not display properly on Windows 2000-based computers, do the following: Change the setting to Not Defined and then change the setting to the wanted value using a Windows 2000-based computer.
Important
If you do not reconfigure this setting to Not Defined before reconfiguring the setting using a Windows 2000-based computer, 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 that the servers cache locally. 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) 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 that their password is about to expire. With this advance 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 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 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) setting to a value that is greater than zero, the user's cached credentials are used to unlock the computer.
Note
This setting can be applied to Windows 2000-based computers, but it is not available through the Security Configuration Manager tool on those computers.
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 setting to Enabled and configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting to 0.
Potential impact
When the console on a computer is locked, either by a user or automatically by a screen-saver timeout, the console can be unlocked only if the user can re-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) 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 both 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, even 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.
Note
This setting can be applied to Windows 2000-based computers, but it is not available through the Security Configuration Manager tool on those computers.
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 to users and configure the Interactive logon: Require smart card setting to Enabled.
Potential impact
All users of a computer with this 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) as well as 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. Windows Server 2003 and Windows Server 2008 include Active Directory® Certificate Services (AD CS) for implementing and managing certificates. When AD CS is combined with Windows Vista, features such as automatic user and computer enrollment and renewal become available. For more information about deploying smart cards with Windows Vista, see Windows Vista Smart Card Infrastructure (https://go.microsoft.com/fwlink/?LinkId=111969).
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 setting is Not Defined, which is equivalent to the No Action setting.
Note
On computers running Windows Vista or Windows Server 2008, the Smart Card Removal Policy service must be started for this 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 using those credentials.
Countermeasure
Configure the Interactive logon: Smart card removal behavior 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 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 to 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 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 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 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 2000 Server, Windows 2000 Professional, Windows Server 2003, Windows XP Professional, and Windows Vista implementations 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 and the server.
Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these 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 the sending of 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 that are included with Windows Server 2003.
Countermeasure
Disable the Microsoft network client: Send unencrypted password to connect to third-party SMB servers setting.
Potential impact
Some very old applications and operating systems such as MS-DOS, Windows for Workgroups 3.11, and Microsoft Windows® 95a 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 client activity resumes. A value of 0 disconnects an idle session as quickly as possible. The maximum value is 99999, which is 208 days; in effect, this value disables the 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 in Windows Server 2003 and Windows Server 2008.
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 setting is enabled in Windows Vista.
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 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.
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 setting is enabled on domain controllers and 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 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 Windows Server 2003–based domains. For example, the following computers may not work:
Windows NT 4.0–based Remote Access Service servers
Servers that host Microsoft SQL Server® and run on Windows NT 3.x–based or Windows NT 4.0–based computers
Servers that host Remote Access Service or Microsoft SQL Server run on Windows 2000–based computers and are located in Windows NT 3.x domains or Windows NT 4.0 domains.
Network access: Do not allow anonymous enumeration of SAM accounts
This policy setting determines what additional permissions are granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as querying the Security Account Manager (SAM) database store of user accounts and security descriptors for users on the local computer and 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 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 HKLM\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 both located in the HKLM\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 setting.
Potential impact
It is impossible to establish trusts with Windows NT 4.0–based domains. 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 HKLM\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 registry values RestrictAnonymousSAM and RestrictAnonymous, respectively, which are both located in the HKLM\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 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 and credentials for network authentication
This policy setting determines whether the Stored User Names and Passwords feature may 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 of Windows does not store passwords and credentials.
Possible values:
Enabled
Disabled
Not Defined
Vulnerability
Passwords that are cached can be accessed by the user when logged on to the 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 another, 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 and credentials for network authentication setting.
Potential impact
Users are forced to type passwords whenever they log on to their Windows Live ID or other 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 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 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 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 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 setting to a null value (enable the 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 Windows Server 2003 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 setting to a null value (enable the setting but do not enter any paths in the text box).
Potential impact
Remote management tools such as the Microsoft Baseline Security Analyzer (MBSA) and Microsoft Systems Management Server (SMS) 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 assigned throughout the registry are fairly restrictive and help to 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 setting to a null value (enable the setting but do not enter any paths in the text box).
Potential impact
Remote management tools such as MBSA and SMS 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 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 HKLM\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 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 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 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 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 running Windows Vista or Windows XP Professional is Guest only. The default configuration for domain-joined computers running the Windows Vista or Windows XP Professional operating system is Classic. Computers that run the Windows Server 2008 or Windows Server 2003 operating system also use the Classic security model.
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 or Terminal Services. This setting also has no effect on Windows 2000-based computers.
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 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: 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 setting. Require all users to 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, as well as 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 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 (LM) is a family of early Microsoft client/server software that 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 LM, NTLM, or NTLM version 2 (NTLMv2).
LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and is the protocol that is used to authenticate all Windows clients 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 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 setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that clients 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 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 |
Clients use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
0 |
Send LM & NTLM – use NTLMv2 session security if negotiated |
Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
1 |
Send NTLM response only |
Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
2 |
Send NTLMv2 response only |
Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. |
3 |
Send NTLMv2 response only.Refuse LM |
Clients use NTLMv2 authentication only. NTLMv2 session security is used if the server supports it. Domain controllers refuse to accept LM authentication and will accept only NTLM and NTLMv2 authentication. |
4 |
Send NTLMv2 response only. Refuse LM & NTLM |
Clients use NTLMv2 authentication only NTLMv2 session security is used if the server supports it. Domain controllers refuse to accept LM and NTLM authentication and will accept only NTLMv2 authentication. |
5 |
Vulnerability
In Windows Vista, this setting is undefined. In Windows Server 2008 this setting is configured to Send NTLMv2 responses only. In Windows 2000, Windows Server 2003, and Windows XP, clients are configured by default to send LM and NTLM authentication responses (Windows 95-based and Windows 98-based clients only send LM). The default setting on servers allows all clients 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 in order 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 both 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 earlier clients and servers, Windows-based clients 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 setting to Send NTLMv2 responses only. We and a number of independent organizations strongly recommend this level of authentication when all clients support NTLMv2.
For more information about how to enable NTLMv2 on older versions of Windows, see article 239869, How to enable NTLM 2 authentication, in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=100904). Windows NT 4.0 requires Service Pack 4 (SP4) to support NTLMv2, and 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.
Note
For information about a hotfix to ensure that this setting works in networks that include Windows NT 4.0-based computers along with Windows 2000, Windows XP, and Windows Server 2003-based computers, see article 305379, Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain, in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=100907).
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 that are included with Windows XP Professional or Windows Vista 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 setting to Require signature.
Potential impact
If you configure the server to require LDAP signatures, you must also configure the client. If you do not configure the client, 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 message confidentiality (encryption), message integrity, 128-bit encryption, or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level policy setting value.
Possible values:
Require message confidentiality. The connection fails if encryption is not negotiated. Encryption converts data into a form that is not readable until decrypted.
Require message integrity. The connection fails if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with. It attaches a cryptographic signature that identifies the sender and is a numeric representation of the contents of the message.
Require 128-bit encryption. The connection fails if strong encryption (128-bit) is not negotiated.
Require NTLMv2 session security. The connection fails if the NTLMv2 protocol is not negotiated.
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) clients policy setting.
Potential impact
Client computers that are enforcing these settings cannot communicate with older servers that do not support them.
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. The connection fails if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with. It attaches a cryptographic signature that identifies the sender and is a numeric representation of the contents of the message.
Require message confidentiality. The connection fails if encryption is not negotiated. Encryption converts data into a form that is not readable by anyone until decrypted.
Require NTLMv2 session security. The connection fails if the NTLMv2 protocol is not negotiated.
Require 128-bit encryption. The connection fails if strong encryption (128-bit) is not negotiated.
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.
Potential impact
Older clients that do not support these security settings cannot communicate with the computer.
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 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, it is dangerous to allow automatic logon to the console. Anyone could walk up to the server, disconnect the power to shut it down, restart it, select Recover Console from the Restart menu, and then assume full control of the server.
Countermeasure
Disable the Recovery console: Allow automatic administrative logon 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 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 setting.
Potential impact
Users who have started a server through the Recovery Console and logged in 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 option is removed from the Windows logon screen. This configuration requires that users to be able to log on to the computer successfully and 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 could also walk to the local console and 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 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 page file when system shuts down setting. This configuration causes the operating system to clear the paging file when the computer is shut down. The amount of time that is required to complete this process depends on the size of the page file. As the process overwrites the storage area used by the page file 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 stored for the user to access protected resources.
Countermeasure
Configure the System cryptography: Force strong key protection for user keys stored on the computer 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 their 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 e-mail, they are forced to type the password for that certificate every time they send a signed e-mail message. For some organizations the overhead that is involved using this configuration may be too high. At a minimum, this 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 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 (DES) 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 setting is enabled, the Encrypting File System (EFS) Service supports only the Triple DES encryption algorithm for encrypting file data. By default, the Windows Vista and the Windows Server 2003 implementation of EFS uses the Advanced Encryption Standard (AES) with a 256-bit key. The Windows XP implementation uses DESX.
Possible values:
Enabled
Disabled
Not Defined
Note
This setting is configured differently in Windows Vista and Windows Server 2008 than in Windows Server 2003 and Windows XP. For more information, see Configure FIPS policy for a mixed environment later in this guide.
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 minimize 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 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 them for network communications. For example, many Apache-based Web servers are not configured to support TLS. If you enable this 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 protocol to communicate with servers that run 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: 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 setting, case insensitivity is enforced for all directory objects, symbolic links, and IO as well as file objects. If you disable this 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 make 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 upper and lower case 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 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. Windows 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 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 setting is enabled by default to protect against a known vulnerability that can be used with either 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 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 (for example, Symbolic Links) 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 potential is dangerous because anything the second user does with that process is performed with 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 a 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 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 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 has the ability to elevate privileges without logging on using a different account. In this mode any operation that requires elevation of privilege displays a prompt that provides the administrator the option to choose either Permit or Deny the elevation of privilege. When this setting is disabled, the built-in Administrator account logs on in XP-compatible mode and runs all applications by default with full administrative privileges. By default this setting is set to Disabled. However, if a computer is upgraded from a previous version of Windows to Windows Vista and the "Administrator" account is the only account on the computer, the built-in Administrator account remains enabled, and this setting is also enabled.
Vulnerability
One of the risks that the User Account Control (UAC) feature included with Windows Vista and Windows Server 2008 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 account named "Administrator" because that user account was created for all installations of Windows. To address this risk, in Windows Vista the built-in Administrator account is disabled. In Windows Server 2008 the Administrator account is enabled, and the password must be changed the first time the Administrator account logs in. In a default installation of a Windows Vista, 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 one if a local administrator account is warranted.
After Windows Vista is installed, the built-in Administrator account may 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 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 being used by a standard user.
Note
This setting does not change the behavior of the UAC elevation prompt for administrators.
Possible values:
Enabled.
Disabled or Not Configured.
When this 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 also 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 setting, you should also review the effect of the User Account Control: Behavior of the elevation prompt for standard users setting. If it is configured as Automatically deny elevation requests, elevation requests are not presented to the user. If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the User Account Control: Switch to the secure desktop when prompting for elevation setting. By default this setting is set to Enabled.
Vulnerability
UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but allowing elevation requests to appear on the regular interactive desktop instead of the secure desktop increases the risk that a malicious program could intercept data 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. In order to be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths:
..\Program Files\ (and subfolders)
..\Program Files (x86)\ (and subfolders, in 64-bit versions of Windows only)
..\Windows\System32\
The requirement to be in a protected path can be disabled by the "User Account Control: Only elevate UIAccess applications that are installed in secure locations" setting. Although this setting applies to any UIA program, it is used primarily in certain Windows Remote Assistance scenarios. The Windows Remote Assistance program in Windows Vista is a UIA program.
Countermeasure
Disable the User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop 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 may select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. However, selecting this check box itself requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation.
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. This option assumes that the administrator will permit an operation that requires elevation and additional consent or credentials are not required.
Note
Selecting Elevate without prompting minimizes the protection provided by the UAC feature. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.
Prompt for credentials. An operation that requires elevation of privilege prompts the administrator to type the user name and password. If the administrator enters valid credentials, the operation continues with the applicable privilege.
Prompt for consent. An operation that requires elevation of privilege prompts the administrator to select either Permit or Deny. If the administrator selects Permit, the operation continues with the administrator's highest available privilege.
The default value for this setting is Prompt for consent.
Vulnerability
One of the risks that the UAC feature introduced with Windows Vista tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. This setting raises awareness to 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 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. This option results in an access denied error message being returned to standard users when they try to perform an operation that requires elevation of privilege. Many organizations whose policy requires that user run their computers using a standard user account enable this policy to reduce help desk calls.
Prompt for credentials. An operation that requires elevation of privilege prompts the user to type an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
The default configuration for this setting is Prompt for credentials.
Vulnerability
One of the risks that the UAC feature introduced with Windows Vista tries to mitigate is that of malicious programs running under elevated credentials without the user or administrator being aware of their activity. This setting raises awareness to the user that a program requires the use of elevated privilege operations and requires that the user be able to supply administrative credentials in order 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 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 in with their administrator accounts but instead shift their behavior to using the standard user account.
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.
Possible values:
Enabled. Application installation packages that require an elevation of privilege to install are detected and the user is prompted for administrative credentials.
Disabled. Enterprises running standard users desktops that capitalize on delegated installation technologies like Group Policy Software Install (GPSI) or SMS may disable this feature. In this case, installer detection is unnecessary and thus not required.
The default configuration for this 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 then is 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 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.
Possible values:
Enabled. Enforces the PKI certificate chain validation of a given executable before it is permitted to run.
Disabled. Does not enforce PKI certificate chain validation before a given executable is permitted to run.
The default configuration for this setting is Disabled.
Vulnerability
Intellectual property, personally identifiable information, and other confidential data are normally manipulated by applications on the computer and require elevated credentials to get access to the information. Users and administrators inherently trust applications 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 could be compromised and the user's administrative credentials would also be compromised.
Countermeasure
Enable the UserAccount Control: Only elevate executables that are signed and validated.
Potential impact
Enabling this setting requires that you have a PKI infrastructure 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 cannot be used in an environment that is hardened with this setting. You should carefully test your applications in a preproduction environment before implementing this setting. For information about the steps required to test application compatibility, make application compatibility fixes, and sign installer packages to prepare your organization for deployment of Windows Vista User Account Control, see Understanding and Configuring User Account Control in Windows Vista (https://go.microsoft.com/fwlink/?LinkID=79026).
Control over the applications that are installed on the desktops and the hardware that joins your domain should provide similar protection from the vulnerability addressed by this setting. Additionally, the level of protection provided by this 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
Windows enforces a PKI signature check on any interactive application that requests running with UIAccess integrity level regardless of the state of this security setting.
Possible values:
Enabled. An application can start with UIAccess integrity only if it resides in a secure location in the file system.
Disabled. An application can start with UIAccess integrity even if it does not reside in a secure location in the file system.
The default configuration for this 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 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 is not required by most applications. A process that is started with UIAccess rights has the following abilities:
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 setting.
Potential impact
If the application that requests UIAccess meets the UIAccess setting requirements, Windows Vista starts the application with the ability to bypass most of the UIPI restrictions. If the application does not meet the security restrictions, the application is started without UIAccess rights and 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 User Account Control (UAC) policies for the entire system.
Possible values:
Enabled. Admin Approval Mode and all other UAC policies are dependent on this option being enabled. Changing this setting requires restarting the system.
Disabled. Admin Approval Mode user type and all related UAC policies are 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 setting is Enabled.
Vulnerability
This is the setting that 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 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 on the interactive user desktop or the secure desktop.
Possible values:
Enabled. All elevation requests by default go to the secure desktop.
Disabled. All elevation requests go to the interactive user desktop.
The default configuration for this 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 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 the redirection of the write failures of earlier applications to defined locations in both the registry and file system. This feature mitigates those applications that historically ran as administrator and wrote runtime application data back to either %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software\.
Virtualization facilitates the running of pre-Windows Vista-based applications that historically failed to run with standard user privileges. An administrator running only Windows Vista–compliant applications may choose to disable this feature because it is unnecessary.
Possible values:
Enabled. Setting this value facilitates the runtime redirection of application write failures to defined user locations for both the file system and registry.
Disabled. Applications that write data to protected locations fail, as they did in previous versions of Windows.
The default configuration for this 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 setting.
Potential impact
None. This is the default configuration.