Security Options

Article
08/05/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 drives, driver installation behavior, and logon prompts.

Security Options Settings

You can configure the security options settings in the following location within the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

The Security Options item of Group Policy contains the following policies:

Accounts: Administrator account status
Accounts: Guest account status
Accounts: Limit local account use of blank passwords to console logon only
Accounts: Rename administrator account
Accounts: Rename guest account
Audit: Audit the access of global system objects
Audit: Audit the use of Backup and Restore privilege
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
Audit: Shut down system immediately if unable to log security audits
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL)
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL)
Devices: Allow undock without having to log on
Devices: Allowed to format and eject removable media
Devices: Prevent users from installing printer drivers
Devices: Restrict CD-ROM access to locally logged-on user only
Devices: Restrict floppy access to locally logged-on user only
Devices: Unsigned driver installation behavior
Domain controller: Allow server operators to schedule tasks
Domain controller: LDAP server signing requirements
Domain controller: Refuse machine account password changes
Domain member: Digitally encrypt or sign secure channel data (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 credentials or .NET Passports for network authentication
Network access: Let Everyone permissions apply to anonymous users
Network access: Named Pipes that can be accessed anonymously
Network access: Remotely accessible registry paths
Network access: Remotely accessible registry paths and 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 all folders
Shutdown: Allow system to be shut down without having to log on
Shutdown: Clear virtual memory pagefile
System cryptography: Force strong key protection for user keys stored on the computer
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
System objects: Default owner for objects created by members of the Administrators group
System objects: Require case insensitivity for non-Windows subsystems
System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)
System settings: Optional subsystems
System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies
User Account Control: Admin Approval Mode for the Built-in Administrator account
User Account Control: 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 users, including administrators, as standard users
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 the account out if it has exceeded the maximum number of failed logons.

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 may want to 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 will be 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 will need to 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), will 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®, and Windows Server® 2003.

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 Active Directory® directory service 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 2000, Windows Server 2003, 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 need to 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, which was recommended earlier in this section.)

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, 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, and Windows Server 2003.

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 will assign 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 that knows the name of the object. For instance, if a synchronization object such as a mutex had a poorly chosen discretionary access control list (DACL), then 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 would not likely 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 backup and restore 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 a your incident response plan, but a malicious user could use a legitimate backup copy to get access to information or spoof 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 will override the new subcategory audit policy feature. A new registry value introduced in Windows Vista, 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 there are 40 new auditing subcategories that enable you to get more precise details about activities on a computer. The following table provides a list of 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 (IAS) and Network Access Protection (NAP) user access requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and Unlock. Auditing this setting will result in a medium or high volume of records on NPS and IAS servers.	No Auditing
Logon/Logoff–Other Logon/Logoff Events	Reports other logon/logoff-related events, such as Terminal Services session disconnects and reconnects, using RunAs to run processes under a different account, and locking and unlocking a workstation.	No Auditing
Object Access–File System	Reports 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 the when packets are dropped by Windows Filtering Platform (WFP). These events can have a very high volume.	No Auditing
Object Access–Filtering Platform Connection	Reports when connections are allowed or blocked by Windows Filtering Platform (WFP). These events can have a high volume.	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 encrypt or decrypt calls into the data protections application programming interface (DPAPI). DPAPI is used to protect 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 events can have a very high volume.	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 detailed information about the information replicating between domain controllers. These events can have a very high volume.	No Auditing
DS Access–Directory Service Access	Reports when an AD DS object is accessed. Only objects with SACLs cause audit to be generated, and only when they are accessed in a manner that matches their SACL. These events are similar to the directory service access events in Windows 2000 Server.	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 that do not relate to credential validation or Kerberos tickets.	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: Act as part of the operating system, Back up files and directories, Create a token object, Debug programs, Enable computer and user accounts to be trusted for delegation, Generate security audits, Impersonate a client after authentication, Load and unload device drivers, Manage auditing and security log, Modify firmware environment values, Replace a process-level token, Restore files and directories, and Take ownership of files or other objects. Auditing this subcategory will create a high volume of events.	No Auditing
Privilege Use–Non-Sensitive Privilege Use	Reports when a user account or service uses a non-sensitive privilege. A non-sensitive privilege includes the following user rights: Access Credential Manager as a trusted caller, Access this computer from the network, Add workstations to domain, Adjust memory quotas for a process, Allow log on locally, Allow log on through Terminal Services, Bypass traverse checking, Change the system time, Create a pagefile, Create global objects, Create permanent shared objects, Create symbolic links, Deny access this computer from the network, Deny log on as a batch job, Deny log on as a service, Deny log on locally, Deny log on through Terminal Services, Force shutdown from a remote system, Increase a process working set, Increase scheduling priority, Lock pages in memory, Log on as a batch job, Log on as a service, Modify an object label, Perform volume maintenance tasks, Profile single process, Profile system performance, Remove computer from docking station, Shut down the system, and Synchronize directory service data. Auditing this subcategory will create a very high volume of 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 that are available in Windows Vista 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 client computers in a Windows Server 2003 domain or in a Windows 2000 domain. If after enabling this setting, you attempt to modify an auditing setting by using Group Policy, the Group Policy auditing setting will be ignored in favor of the custom policy setting. To modify auditing settings by using Group Policy, you must first disable this 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 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 be able to prevent the occurrence of auditable events if the audit system is unable to log them. The way 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, it cannot guarantee that every data file for every application will still be in a usable form when the computer restarts.

DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL)

This policy setting allows administrators to define additional computer-wide access controls that govern access to all Distributed Component Object Model (DCOM)–based applications on a computer. These controls restrict call, activation, or launch requests on the computer. The simplest 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 to access any COM server on the computer. This policy setting controls access permissions to cover call rights.

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 default ACLs in Windows Server 2003, you can download Default Access Control Settings in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkID=36346).
For information about the restrictions that are applied in Windows Server 2003 with SP1, see the "DCOM Security Enhancements" section (https://go.microsoft.com/fwlink/?LinkId=111965) in the "Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1" document.
For more information about launch permissions, see LaunchPermission (https://go.microsoft.com/fwlink/?LinkId=100896).

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) 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 ACL assigns correct permission to appropriate users. If it does not, you need to change your application-specific permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail.

DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL)

This policy setting is similar to the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) 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. The simplest 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 will be denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to launch any COM server on the computer. The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) policy 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) 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 default ACLs in Windows Server 2003, you can download Default Access Control Settings in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkID=36346).
For information about the restrictions that are applied in Windows Server 2003 with SP1, see the "DCOM Security Enhancements" section (https://go.microsoft.com/fwlink/?LinkId=111965) in the "Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1" document.
For more information about launch permissions, see LaunchPermission (https://go.microsoft.com/fwlink/?LinkId=100896).

Vulnerability

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

You should only disable this policy setting 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 will have to log on to the local console before they can undock their computers. For computers that do not have docking stations, this policy setting will have 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 may be able to 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 will eject media by pressing a mechanical button 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 will be able to format and eject removable media. If users are in the habit of using removable media for file transfers and storage, they will need to 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, any user 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 will be able to 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 may want to 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 will not be able to 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 will fail. This condition will cause 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 will 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 may want to 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 will not be able to 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 will 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 will fail. This condition will cause 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 will also fail.

Devices: Unsigned driver installation behavior

This policy setting determines what happens when an attempt is made to install a device driver that has not been certified and signed by the Windows Hardware Quality Lab (WHQL) by means of the Setup API. This policy setting prevents the installation of unsigned drivers, or warns the administrator that unsigned driver software is about to be installed. This capability can prevent use of the Setup API to install drivers that have not been certified to run on Windows Vista or Windows Server 2003.

Note

This setting is not available in the Local Group Policy Editor in Windows Vista.

Possible values:

Silently succeed
Warn but allow installation
Do not allow installation
Not Defined

Vulnerability

This policy setting will not prevent a method that is used by some attack tools in which malicious .sys files are copied and registered to start as system services.

Countermeasure

Configure the Devices: Unsigned driver installation behavior setting to Warn but allow installation, which is the default configuration for Windows Vista and Windows XP with SP2. The default configuration for Windows Server 2003 is Not Defined.

Potential impact

Users with sufficient privileges to install device drivers will be able to install unsigned device drivers. However, this capability could result in stability problems for servers. Another potential problem with a Warn but allow installation configuration is that unattended installation scripts will fail if they attempt to install unsigned drivers.

Note

On 64-bit versions of Windows Vista, running of unsigned kernel mode drivers is disabled when the operating system attempts to load them into memory. While installation of such drivers might be possible depending on the configuration of this policy, running of unsigned drivers on 64-bit versions of Windows Vista is not possible without regard to this policy setting.

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 schedule tool. If you enable this policy setting, jobs that are created by server operators by means of the AT service will run in the context of the account that runs that service. By default, that is the local SYSTEM account. If you enable this policy setting, server operators could perform tasks that SYSTEM is able to do but that they would typically not be able to 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 may be able to 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) will still be able to create jobs by means of the Task Scheduler Wizard. However, those jobs will 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 will be unable to run LDAP queries against the domain controllers. All Windows 2000–based computers in your organization that are managed from Windows Server 2003–based or Windows XP–based computers and that use NTLM authentication must have Windows 2000 Service Pack 3 (SP3) installed. Alternatively, these clients must have a registry change. For information about this registry change, see article 325465, Windows 2000 domain controllers require SP3 or later when using Windows Server 2003 administration tools, in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=100900). Also, some non-Microsoft operating systems do not support LDAP signing. If you enable this policy setting, client computers that use those operating systems may be unable to access domain resources.

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 will not be able to change their computer account passwords, and those passwords will be more susceptible to attack.

Countermeasure

Disable the Domain controller: Refuse machine account password changes setting.

Potential impact

None. This is the default configuration.

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 be able to 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

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. 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 will be disabled.
Logons from clients running versions of Windows earlier than Windows NT 4.0 with SP6a will be 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 will be 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 and applications that run on these versions of Windows will not be 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 this 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.

Warning

Do not use this 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 pre-built 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 use of this policy unnecessary for imaged computers.

Possible values:

Enabled
Disabled
Not Defined

Vulnerability

The default configuration for Windows Server 2003–based computers that belong to a domain is that they are automatically required to change the passwords for their accounts every 30 days. If you disable this policy setting, computers that run Windows Server 2003 will retain the same passwords as their computer accounts. Computers that are no longer able to 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. This setting also applies to Windows 2000-based computers, but it is not available through the Security Configuration Manager tool on these computers.

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 will have 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 will require 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 will not be able to 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 will not be able to join domains in which the domain controllers have this policy setting enabled.

Interactive logon: Do not display last user name

This policy setting enables or disables preventing the display of the name of the last user to log on to the computer in the logon dialog box.

Possible values:

Enabled
Disabled
Not Defined

Vulnerability

An attacker with access to the console (for example, someone with physical access or someone who is able to 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 will always have to type their user names when they log on to the servers.

Interactive logon: Do not require CTRL+ALT+DEL

This policy setting enables or disables the non-requirement for users to press CTRL+ALT+DEL before they log on to Windows, unless they use a smart card, a tamper-proof device that stores security information.

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 will have to simultaneously press the three keys before the logon dialog box will display.

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 will 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 desired value by 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 will 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 different unique 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 unique 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 the servers will cache locally. If the number is set to 10, then 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 will 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 will be unable to log on to any computers if there is no domain controller available to authenticate them. Organizations may want to 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 will still be in the cache, even if a member of the IT department has recently logged on to their 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 users are warned that their password is about to expire. With this advance warning, the user has time to construct a password that is sufficiently strong.

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 inadvertently be locked out of the computer 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 will 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 will be 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 is able to 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) will not be able to 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 will find it extremely difficult to decrypt the traffic and, even if they do, the next time the user logs onto the network a new session key will be 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 will have to use smart cards to log onto the local computer, which means that the organization will need 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. However, Windows Server 2003 includes Certificate Services, a highly advanced service for implementing and managing certificates. When Certificate Services is combined with Windows XP or 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 results which is equivalent to the No Action setting.

Note

On computers running Windows Vista or later operating systems, 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 very 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 will have to re-insert their smart cards and re-enter their PINs when they return to their workstations.

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 undesirable 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 will 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 would be to implement digital signatures with Internet Protocol security (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 needs to 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 will not be able to connect. However, if you completely disable all SMB signing, computers will be 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 passwords in plaintext 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 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 re-establishes when client activity resumes. A value of 0 will disconnect 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 idle time for servers and an undefined time for workstations.

Vulnerability

Each SMB session consumes server resources, and numerous null sessions will 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.

Potential impact

There will be little impact because SMB sessions will be re-established 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 will be forcibly disconnected when the client's logon hours expire. If you disable this policy setting, established client sessions will be 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 be able to 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 will have no impact. If logon hours are used, existing user sessions will be 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 will have 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 be unable to 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 will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerate the names of domain accounts and shared folders. 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 will 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 replace 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 attacks 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 will be 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 will 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. Windows allows anonymous users to perform certain activities, such as enumerate the names of domain accounts and shared folders. 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 will 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 replace 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 will be impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain will be unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously will be unable to list the shared network resources on those servers; the users will have to be authenticated before they can view the lists of shared folders and printers.

Network access: Do not allow storage of credentials or .NET Passports 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 will be 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 credentials or .NET Passports for network authentication setting.

Potential impact

Users will be forced to enter 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 will be able to 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, will 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 default list of named pipes and their purpose is provided in the following table.

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 enter named pipes in the text box).

Potential impact

This configuration will disable null session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes will no longer function. This may break trust between Windows Server 2003 domains in a mixed mode environment. For example, with Microsoft Commercial Internet System 1.0, the Internet Mail Service runs under the Inetinfo process. Inetinfo starts in the context of the System account. When Internet Mail Service needs to query the Microsoft SQL Server database, it uses the System account, which uses null credentials to access a SQL pipe on the computer that runs SQL Server.

For information about avoiding this problem, see article 207671, How to access network files from IIS applications, in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=100903).

Network access: Remotely accessible registry paths

This policy setting determines which registry paths will be 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 and Microsoft Systems Management Server 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 sub-paths will be 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

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, you should check if any of the named pipes 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, but with the increased hardening in Windows Server 2003 with SP1 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

It is very dangerous to enable this setting. 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 will have access to shared resources on the server.

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 allows 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 Windows Vista or Windows XP Professional is Classic. Computers that are running Windows Server 2003 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 will 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.

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, as LAN Manager hashes are much weaker than NTLM hashes, but it will be 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, will not be able to 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 will be disconnected when the client's logon hours expire. If you disable this policy setting, established client sessions will be 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 will terminate. The user will be unable to log on to the computer until his or her 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
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 as follows:

Send LM & NTLM responses. Clients use LM and NTLM authentication and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send LM & NTLM – Use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLM response only. Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only\refuse LM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).
Send NTLMv2 response only\refuse LM & NTLM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).

These settings correspond to the following security levels which are denoted by level number in the associated registry settings:

Level 0—Send LM and NTLM response; never use NTLMv2 session security. Clients use LM and NTLM authentication, and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Level 1—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.
Level 2—Send NTLM response only. Clients use only NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Level 3—Send NTLMv2 response only. Clients use NTLMv2 authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Level 4—Domain controllers refuse LM responses. Clients use NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers refuse LM authentication, that is, they accept NTLM and NTLMv2.
Level 5—Domain controllers refuse LM and NTLM responses (accept only NTLMv2). Clients use NTLMv2 authentication, use and NTLMv2 session security if the server supports it. Domain controllers refuse NTLM and LM authentication (they accept only NTLMv2).

Vulnerability

In Windows Vista, this setting is undefined. However, 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 to more easily reproduce the user's password.

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 will 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 platforms need the directory service client installed to support NTLMv2.

Potential impact

Clients that do not support NTLMv2 authentication will not be able to 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, as follows:

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 told 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. No Microsoft LDAP clients that are included with Windows XP Professional or Windows Vista 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 will not be able to 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 will fail if encryption is not negotiated. Encryption converts data into a form that is not readable until decrypted.
Require message integrity. The connection will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with; 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 will fail if strong encryption (128-bit) is not negotiated.
Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not negotiated.
Not Defined.

Vulnerability

Network traffic that uses the NTLM Security Support Provider (NTLM SSP) might 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 will be unable to 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 will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with; 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 will fail if encryption is not negotiated. Encryption converts data into a form that is not readable by anyone until decrypted.
Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not negotiated.
Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not negotiated.
Not Defined.

Vulnerability

Network traffic that uses the NTLM Security Support Provider (NTLM SSP) might 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 will be unable to 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 need to 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 will have to enter a user name and password to access the Recovery Console.

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

This policy setting enables or disables the Recovery Console SET command, which allows you to set the following Recovery Console environment variables.

AllowWildCards. Enables wildcard support for some commands (such as the DEL command).
AllowAllPaths. Allows access to all files and folders on the computer.
AllowRemovableMedia. Allows files to be copied to removable media, such as a floppy disk.
NoCopyPrompt. Suppresses the prompt that typically displays before an existing file is overwritten.

Possible values:

Enabled
Disabled
Not Defined

Vulnerability

An attacker who can cause the system to restart into the Recovery Console could steal sensitive data and leave no audit or access trail.

Countermeasure

Disable the Recovery console: Allow floppy copy and access to drives and folders setting.

Potential impact

Users who have started a server through the Recovery Console and logged in with the built-in Administrator account will not be able to 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 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 will have to log on to servers to shut them down or restart them.

Shutdown: Clear virtual memory pagefile

This policy setting determines whether the virtual memory page file is cleared when the computer is shut down. Virtual memory support uses a system page file to swap pages of memory to disk when they are not used. On a running computer, this page 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 might have to make sure that the system page file is cleared when the computer shuts down. This confirmation ensures that sensitive information from process memory that might be placed in the page file is not available to an unauthorized user who manages to directly access the page file after shutdown.

When you enable this policy setting, the system page file is cleared when the system shuts down normally. Also, this policy setting will force 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 page file to help Windows Server 2003 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 server could bypass this countermeasure by simply unplugging the server from its power source.

Countermeasure

Enable the Shutdown: Clear virtual memory page file when system shuts down setting. This configuration causes Windows Server 2003 to clear the page 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 will take longer to shut down and restart the server, especially on servers with large paging files. For a server 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 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 will have to enter 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 will be forced to enter 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 will support 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 will use the most powerful algorithms that are available for digital encryption, hashing and signing. Use of these algorithms will 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 will be unable to 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 will not be able to 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 also need to configure Internet Explorer® 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 will fail if both computers are not configured to use the same encryption algorithms.

To enable Internet Explorer to use TLS

On the Internet Explorer Tools menu, click Internet Options.
Click the Advanced tab.
Select the Use TLS 1.0 check box.

It is also possible to configure this policy setting through Group Policy or by using the Internet Explorer Administrators Kit.

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

This policy setting determines whether the Administrators group or an object creator is the default owner of any system objects that are created.

Possible values:

Administrators group
Object creator
Not Defined

Vulnerability

If you configure this policy setting to Administrators group, it will be impossible to hold individuals accountable for the creation of new system objects.

Countermeasure

Configure the System objects: Default owner for objects created by members of the Administrators group setting to Object creator.

Potential impact

When system objects are created, the ownership will reflect which account created the object instead of the more generic Administrators group. A consequence of this policy setting is that objects will become orphaned when user accounts are deleted. For example, when a member of the information technology group leaves, any objects that they created anywhere in the domain will have no owner. This situation could become an administrative burden as administrators have to manually take ownership of orphaned objects to update their permissions. This potential burden can be minimized if you can ensure that Full Control is always assigned to new objects for a domain group such as Domain Admins.

System objects: Require case insensitivity for non-Windows subsystems

This policy setting enables or disables the enforcement of case insensitivity for all subsystems. The Microsoft Win32® subsystem is case-insensitive. However, the kernel supports case sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). If you enable this 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 will support case sensitivity, failure to enable this policy setting would 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 will be available.

Countermeasure

Enable the System objects: Require case insensitivity for non-Windows subsystems setting.

Potential impact

All subsystems will be 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. It is a file on its own and can exist independently of its target. If a symbolic link is deleted, its target 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 will be 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 will no longer operate. For example, Microsoft Services for Unix (SFU) installs an updated version of the POSIX subsystem that is required, so you would need to 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 will allow or disallow 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, such as viruses and Trojans 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 ensure 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 desired 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. The built-in Administrator account will log on in Admin Approval Mode. By default any operation that requires elevation of privilege will prompt the Consent Admin to choose either Permit or Deny.
Disabled. The built-in Administrator account will log on in XP compatible mode and run all applications by default with full administrative privilege.

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 will remain enabled and this setting will also be enabled.

Vulnerability

One of the risks that the User Account Control (UAC) feature introduced with Windows Vista is trying 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 these programs was 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 a default installation of a new computer, 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.

Once 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 will be prompted for consent whenever a program requests an elevation in privilege.

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 and is not recommended unless administrator accounts are tightly controlled and the operating environment is highly secure.

Prompt for credentials. An operation that requires elevation of privilege will prompt the administrator to enter the user name and password. If the administrator enters valid credentials the operation will continue with the applicable privilege.
Prompt for consent. An operation that requires elevation of privilege will prompt the administrator to select either Permit or Deny. If the administrator selects Permit, the operation will continue 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 is trying 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 the standard user when they try to perform an operation that requires elevation of privilege. Most enterprises running desktops as standard user will configure this policy to reduce help desk calls.
Prompt for credentials. An operation that requires elevation of privilege will prompt the user to enter an administrative user name and password. If the user enters valid credentials the operation will continue with the applicable privilege.

The default configuration for this setting is Prompt for credentials.

Vulnerability

One of the risks that the UAC feature introduced with Windows Vista is trying 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 will require 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, then the Prompt for credentials setting is recommended so that the users will not choose to always log in with their administrator accounts and will shift their behavior to using the standard user account.

Potential impact

Users will need to provide administrative passwords to be able 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 will be detected and the user will be prompted for administrative credentials.
Disabled. Enterprises running standard users desktops that leverage 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 will attempt to install itself after being given permission to run; for example, malicious software with a trusted application shell. The user may have given permission for the program to run because the program is trusted, but if they are then prompted for installation of an unknown component this provides another way of trapping the software before it can do damage.

Countermeasure

Enable the User Account Control: Detect application installations and prompt for elevation setting.

Potential impact

Users will need to provide administrative passwords to be able 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 will not be able to be used in an environment that is hardened with this setting. You should carefully test your applications in a pre-production 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 is able to join 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 will be able to 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 will be started without UIAccess rights and can interact only with applications at the same or lower privilege level.

User Account Control: Run all users, including administrators, as standard users

This policy setting determines the behavior of all 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 will be disabled.

Note

If this security setting is configured to Disabled, the Security Center will notify 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 on or off UAC. If this setting is disabled, UAC will not be used and any security benefits and risk mitigations that are dependent on UAC will not be present on the system.

Countermeasure

Enable the User Account Control: Run all users, including administrators, as standard users setting.

Potential impact

Users and administrators will need to 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 will prompt on the interactive user desktop or the secure desktop.

Possible values:

Enabled. All elevation requests by default will go to the secure desktop.
Disabled. All elevation requests will 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 as it is unnecessary.

Possible values:

Enabled. Facilitates the runtime redirection of application write failures to defined user locations for both the file system and registry.
Disabled. Applications that write data to protected locations will simply fail as they did in previous versions of Windows.

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.

Share via

Security Options