Domain Controller and Member Server Policy Settings
Published: February 27, 2008
The security settings in this section of the appendix apply to domain controllers and member servers in the domain. Many recommendations are the same for both domain controllers and member servers. However, some settings apply only to domain controllers. These settings are applied through the Computer Configuration node in the Group Policy Object Editor. Within this node, these settings appear in the Windows Settings and Administrative Templates sub-nodes. Computer Configuration\Windows SettingsThe following setting groups appear in the Computer Configuration\Windows Settings\Security Settings\Local Policies subdirectory, and are discussed in this appendix:
The following setting groups appear in the Computer Configuration\Windows Settings\Security Settings subdirectory:
User Rights Assignment SettingsIn conjunction with many of the privileged groups in Windows Server 2008, you can assign a number of user rights to specific users or groups. These rights would typically be assigned to perform a specific administrative task or tasks without giving full administrative control to that user or group. To set the value of a user right to No one, enable the setting but do not add any users or groups to it. To set the value of a user right to Not Defined, do not enable the setting. You can configure the user rights assignment settings in Windows Server 2008 at the following location in the Group Policy Object Editor: Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment The following table summarizes user rights assignment setting recommendations for user rights that begin with the letters A through E. Recommendations are provided for both domain controllers and member servers in the two types of secure environments that are discussed in this guide. The following subsections provide more detailed information about each setting. Recommendations for user rights that begin with the rest of the letters in the alphabet are summarized in Table A5, and additional detailed information about those user rights is provided in the subsections after that table. Note Many features in IIS require certain accounts such as IIS_WPG, IIS IUSR_<ComputerName>, and IWAM_<ComputerName> to have specific privileges. For more information about what user rights are required by accounts that are related to IIS, see IIS and Built-in Accounts (IIS 6.0). User Rights A – EThe following table summarizes the values and recommendations for user rights assignment settings that start with the letters A through E in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A4. Windows Server 2008 User Rights Assignment Setting Recommendations, A – E
Note § - Denotes Group Policy settings that are new in Windows Vista or Windows Server 2008. Access Credential Manager as a trusted caller This policy setting is used by Credential Manager during Backup and Restore. No accounts should have this user right, as it is only assigned to Winlogon. Users' saved credentials might be compromised if this user right is assigned to other entities. By default, no accounts are assigned this right. However, to enforce the default setting, the Access Credential Manager as a trusted caller setting is restricted to No One for the SSLF environment discussed in the security guide. Access this computer from the network This policy setting allows other users on the network to connect to a specific computer and is required by various network protocols that include Server Message Block (SMB)–based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+). By default, the Everyone group is granted the Access this computer from the network setting. However, this guide recommends to remove the Everyone group and then to instead assign this right to the Authenticated Users group. In the case of domain controllers, the Enterprise Domain Controllers group must also be granted this right. Not granting this right to any of these specified groups can prevent users from accessing services that servers provide across your environment. Act as part of the operating system This policy setting allows a process to assume the identity of any user and thus gain access to the resources that the user is authorized to access. For this reason, the Act as part of the operating system setting is restricted to No one for both of the environments that are discussed in this guide. Add workstations to domain This policy setting only takes effect when applied to domain controllers. Adjust memory quotas for a process This policy setting allows a user to adjust the maximum amount of memory that is available to a process. The ability to adjust memory quotas is useful for system tuning, but it can be abused. In the wrong hands, this setting could be used to launch a denial of service (DoS) attack. For this reason, the Adjust memory quotas for a process setting is restricted to Administrators, Local Service, and Network Service groups for the SSLF environment. The setting is configured to Not Defined for the EC environment. Allow log on locally This policy setting determines which users can interactively log on to computers in your environment. Logons that are initiated by pressing the CTRL+ALT+DEL key sequence on the computer keyboard require this user right. Microsoft recommends that you enable this setting through Group Policy and restrict this right to members of the Administrators group. Assign this user right to the other Operator level administrative security groups, such as Backup Operators or Server Operators, if your organization requires that they have this capability. Allow log on through Terminal Services This policy setting determines which users or groups have the right to log on as a Terminal Services client. Remote desktop users require this user right. Microsoft recommends that you restrict this user right to the Administrators group to prevent unwanted users from gaining access to computers on your network by means of the Remote Assistance feature. Dedicated Terminal Servers will require additional configuration. Back up files and directories This policy setting allows users to circumvent file and directory permissions to back up the system. This user right is enabled only when an application (such as NTBACKUP) attempts to access a file or directory through the NTFS file system backup application programming interface (API). Otherwise, the assigned file and directory permissions apply. Bypass traverse checking This policy setting allows users who do not have the special "Traverse Folder" access permission to "pass through" folders when they browse an object path in the NTFS file system or in the registry. This user right does not allow users to list the contents of a folder, but only allows them to traverse directories. Change the system time This policy setting determines which users and groups can change the time and date of the internal clock of the computers in your environment. Users who are assigned this user right can affect the appearance of event logs. When a computer’s time setting is changed, logged events reflect the new time, which may not be the actual time that the events occurred. Note Discrepancies between the time on the local computer and on the domain controllers in your environment may cause problems for the Kerberos authentication protocol, which could make it impossible for users to log on to the domain or obtain authorization to access domain resources after they are logged on. Also, problems will occur when Group Policy is applied to client computers if the system time is not synchronized with the domain controllers. By default, Windows will automatically synchronize clock settings within the domain. Change the time zone This setting determines which users can change the time zone of the computer. This setting capability poses no great risk for the computer. However, modifications to this setting affect all users and applications on the computer, which could cause confusion in shared terminal server environments. Create a pagefile This policy setting allows users to change the size of the pagefile. By making the pagefile extremely large or extremely small, an attacker could easily affect the performance of a compromised computer. Create a token object This policy setting allows a process to create an access token, which may provide elevated rights to access sensitive data. In environments in which security is a high priority, this user right should not be assigned to any users. Any processes that require this capability should use the Local System account, which is assigned this user right by default. Create global objects This policy setting determines whether users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they do not have this user right. Users who can create global objects could affect processes that run under other users' sessions. This capability could lead to a variety of problems, such as application failure or data corruption. Create permanent shared objects This policy setting allows users to create directory objects in the object manager. This user right is useful to kernel-mode components that extend the object namespace. However, components that run in kernel mode have this user right inherently. Therefore, it is typically not necessary to specifically assign this user right. Create symbolic links This policy setting determines which users can create symbolic links. In Windows Server 2008, existing NTFS file system objects, such as files and folders, can be accessed by referring to a new kind of file system object called a symbolic link. A symbolic link is a pointer (much like a shortcut or .lnk file) to another file system object, which can be a file, folder, shortcut or another symbolic link. The difference between a shortcut and a symbolic link is that a shortcut only works from within the Windows shell. To other programs and applications, shortcuts are just another file, whereas with symbolic links, the concept of a shortcut is implemented as a feature of the NTFS file system. Symbolic links can potentially expose security vulnerabilities in applications that are not designed to use them. For this reason, the privilege for creating symbolic links should only be assigned to trusted users. By default, only members of the Administrators group can create symbolic links. Debug programs This policy setting determines which user accounts will have the right to attach a debugger to any process or to the kernel, which provides complete access to sensitive and critical operating system components. Developers who are debugging their own applications do not need to be assigned this user right. However, developers who are debugging new system components need it. Note Microsoft released several security updates in October 2003 that used a version of Update.exe that required the administrator to have the Debug programs user right. Administrators who did not have this user right were unable to install these security updates until they reconfigured their user rights. This is not typical behavior for operating system updates. For more information, see "Windows Product Updates may stop responding or may use most or all the CPU resources": Knowledge Base article 830846. Because an attacker could exploit this user right, it is assigned only to the Administrators group by default. For the SSLF environment, Microsoft recommends assigning this user right to No One. Deny access to this computer from the network This security setting determines which users are prevented from accessing a computer over the network. This policy setting supersedes the Access this computer from the network policy setting if a user account is subject to both policies. Deny log on as a batch job This policy setting prohibits users from logging on to a computer through a batch-queue facility, which is a feature in Windows Server 2008 that you can use to schedule jobs to run automatically one or more times in the future. Deny log on as a service This policy setting determines whether users can log on as a service. Accounts that can log on as a service could be used to configure and launch new unauthorized services, such as a keylogger or other malware. Deny log on locally This policy setting prohibits users from logging on locally to the computer console. If unauthorized users can log on locally to a computer, they can download malicious code or elevate their privileges on the computer. In addition, if attackers have physical access to the console, there are other risks to consider. This user right should not be assigned to those users who need physical access to the computer console. Deny log on through Terminal Services This policy setting prohibits users from logging on to computers in your environment through Remote Desktop connections. If you assign this user right to the Everyone group, you also prevent members of the default Administrators group from using Terminal Services to log on to computers in your environment. Enable computer and user accounts to be trusted for delegation This policy setting allows users to change the Trusted for Delegation setting on a computer object in Active Directory®. Abuse of this privilege could allow unauthorized users to impersonate other users on the network. User Rights F – ZThe following table summarizes the values and recommendations for user rights assignment settings that start with the letters F through Z in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A5. Windows Server 2008 User Rights Assignment Setting Recommendations, F – Z
Note § - Denotes Group Policy settings that are new in Windows Vista or Windows Server 2008. Force shutdown from a remote system This policy setting allows users to shut down Windows–based computers from remote locations on the network. An unauthorized shut down of a server is a type of denial of service (DoS) condition that makes the computer unavailable to service user requests. Microsoft recommends to only assign this user right to highly trusted administrators. Generate security audits This policy setting determines which users or processes can generate audit records in the Security log. An attacker could use this capability to create a large number of audited events, which would make it more difficult for a system administrator to locate any illicit activity. Also, if the event log is configured to overwrite events as needed, any evidence of unauthorized activities could be overwritten by a large number of unrelated events. Impersonate a client after authentication This policy setting allows programs to impersonate a user so that the program can act on behalf of the user. Requiring authentication first helps prevent elevation of privilege attacks. Services that the Service Control Manager starts have the built-in group "Service" added by default to their access tokens. COM servers that the COM infrastructure starts and configures to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started. In addition, a user can impersonate an access token if any of the following conditions exist:
An attacker with the Impersonate a client after authentication user right could create a service that impersonates any logged on user in order to elevate the attacker's level of access to that of the logged on user or to the level of the client computer's system account. Increase a process working set This policy setting determines which user accounts can increase or decrease the size of a process working set. The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process. This right is granted to all users by default. However, increasing the working set size for a process decreases the amount of physical memory available to the rest of the system. It would be possible for malicious code to increase the process working set to a level that could severely degrade system performance and potentially cause a denial of service. Certain environments can help mitigate this risk by limiting which users can increase the process working set. Increase scheduling priority This policy setting allows users to change the amount of processor time that a process uses. An attacker could use this capability to increase the priority of a process to real-time and create a denial of service (DoS) condition for a computer. Load and unload device drivers This policy setting allows users to dynamically load a new device driver on a system. An attacker could potentially use this capability to install malicious code that appears to be a device driver. This user right is required to add local printers or printer drivers in Windows Server 2008. Lock pages in memory This policy setting allows a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. If this user right is assigned and abused, significant degradation of system performance can occur. Log on as a batch job This policy setting allows accounts to log on using the Task Scheduler service. Because the Task Scheduler is often used for administrative purposes, you may need this right in the EC environment. However, Microsoft recommends restricting its use in the SSLF environment to prevent misuse of system resources or to prevent attackers from using the right to launch malicious code after gaining user level access to a computer. Log on as a service This policy setting allows accounts to launch network services or to register a process as a service running on the system. This user right should be restricted on all computers in an SSLF environment, but because many applications may require this right, you should carefully evaluate and test this setting before configuring it in an EC environment. On servers running Windows Server 2008, no users or groups have this right by default. Manage auditing and security log This policy setting determines which users can change the auditing options for files and directories and clear the Security log. Because this capability represents a relatively small threat, this setting enforces the default value of the Administrators group for both the EC and SSLF environments. Modify an object label This policy setting determines which users can change the integrity level of objects, such as files, registry keys or processes owned by other users. Note that a user can change the integrity level of an object that is owned by that user to a lower level without holding this privilege. Modify firmware environment values This policy setting allows users to configure the system-wide environment variables that affect hardware configuration. This information is typically stored in the Last Known Good Configuration. Modification of these values could lead to a hardware failure that would result in a DoS condition. Because this capability represents a relatively small threat, this setting enforces the default value of the Administrators group for both the EC and SSLF environments. Perform volume maintenance tasks This policy setting allows users to manage the system's volume or disk configuration, which could allow a user to delete a volume and cause data loss as well as a DoS condition. Profile single process This policy setting determines which users can use tools to monitor the performance of non-system processes. Typically, you do not need to configure this user right to use the Microsoft Management Console (MMC) Performance snap-in. However, you do need this user right if System Monitor is configured to collect data using Windows Management Instrumentation (WMI). Restricting the Profile single process user right prevents intruders from gaining additional information that they could use to mount an attack on the system. Profile system performance This policy setting allows users to use tools to view the performance of different system processes, which could be abused to allow attackers to determine a system's active processes and provide insight into the potential attack surface of the computer. This setting enforces the default of the Administrators group for both the EC and SSLF environments. Remove computer from docking station This policy setting allows the user of a portable computer to click Eject PC on the Start menu to undock the computer. This setting is not usually relevant in server scenarios. Replace a process level token This policy setting allows one process or service to start another service or process with a different security access token, which an intruder can use to modify the security access token of that sub-process to escalate privileges. This setting enforces the default values of Local Service and Network Service for both the EC and SSLF environments. Restore files and directories This policy setting determines which users can bypass file, directory, registry, and other persistent object permissions when restoring backed up files and directories on computers that run Windows Server 2008. This right also determines which users can set valid security principals as object owners; it is similar to the Back up files and directories user right. Shut down the system This policy setting determines which users who are logged on locally to the computers in your environment can shut down the operating system with the Shut Down command. Misuse of this user right can result in a DoS condition. Synchronize directory service data This policy setting determines which users have the authority to synchronize all directory service data. Take ownership of files or other objects This policy setting allows users to take ownership of files, folders, registry keys, processes, or threads. This user right bypasses any permissions that are in place to protect objects and give ownership to the specified user. This setting enforces the default value of the Administrators group for both the EC and SSLF environments. Security Options SettingsThe security option settings that are applied through Group Policy on servers in your environment enable or disable capabilities and features such as floppy disk drive access, CD-ROM drive access, and logon prompts. These settings also configure various other settings, such as those for the digital signing of data, administrator and guest account names, and how driver installation works. You can configure the security option settings in the following location in the Group Policy Object Editor: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options The following sections provide security option setting recommendations, and are grouped by type of object. Each section includes a table that summarizes the settings, and detailed information is provided in the subsections that follow each table. Recommendations are provided for both domain controllers and member servers for both the EC and SSLF environments. This section of the appendix includes tables and recommendations for the following object type settings that reside in the Security Options subdirectory:
AccountsThe following table summarizes the values and recommendations for security setting options affecting account settings in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A6. Windows Server 2008 Security Options Setting Recommendations – Accounts
Accounts: Administrator account status This policy setting enables or disables the Administrator account during normal operation. When you start a computer in safe mode, the Administrator account is always enabled, regardless of how this setting is configured. Accounts: Guest account status This policy setting determines whether the Guest account is enabled or disabled. The Guest account allows unauthenticated network users to gain access to the system. Accounts: Limit local account use of blank passwords to console logon only This policy setting determines whether local accounts that are not password protected can be used to log on from locations other than the physical computer console. If you enable this policy setting, users with local accounts that have blank passwords will not be able to log on to the network from remote client computers. Instead, users with such accounts will only be able to log on at the keyboard of the computer. Accounts: Rename administrator account The built-in local administrator account is a well-known account name that attackers target. Microsoft recommends that you choose another name for this account, and avoid using names that denote administrative or elevated access accounts. Be sure to also change the default description for the local administrator (through the Computer Management console). Sophisticated attacks will identify accounts by using API calls or the security identifier (SID) regardless of the account names. However, changing the default name does add a layer of protection, particularly against script-based attacks. Note This policy setting is not configured in the Security Templates, nor does this guide suggest a user name for the account. Suggested user names are omitted to ensure that organizations that implement this guidance will not use the same new user name in their environments. Accounts: Rename guest account The built-in local guest account is another well-known name to attackers. Microsoft also recommends that you rename this account to something that does not indicate its purpose. Even if you disable this account, which is recommended, ensure that you rename it for added security. Sophisticated attacks will identify accounts by using API calls or the security identifier (SID) regardless of the account names. However, changing the default name does add a layer of protection, particularly against script-based attacks. The recommendation to use this setting applies to both the EC and SSLF environments. Note This policy setting is not configured in the Security Templates, nor does this guide suggest a user name for the account. Suggested user names are omitted to ensure that organizations that implement this guidance will not use the same new user name in their environments. AuditThe following table summarizes the values and recommendations for security setting options that affect auditing functionality in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A7. Security Option Setting Recommendations – Audit
Note § - Denotes Group Policy settings that are new in Windows Vista or Windows Server 2008. Audit: Audit the access of global system objects This policy setting creates a default system access control list (SACL) for system objects such as mutexes (mutual exclusive), events, semaphores, and MS-DOS® devices, and causes access to these system objects to be audited. If you enable this setting, a very large number of security events could quickly fill the Security event log. Therefore, this policy setting is configured to Not Defined for the EC environment and Disabled for the SSLF environment. Audit: Audit the use of Backup and Restore privilege This policy setting determines whether to audit the use of all user privileges, including Backup and Restore, when the Audit privilege use setting is in effect. If you enable both policies, this will generate an audit event for every file that is backed up or restored. If you enable the Audit: Audit the use of Backup and Restore privilege setting, a very large number of security events could quickly fill the Security event log. Therefore, this policy setting is configured to Not Defined for the EC environment and Disabled for the SSLF environment. Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings This policy setting allows administrators to enable more precise auditing capabilities in Windows Vista and Windows Server 2008. The Audit Policy settings available in Windows Server 2003 Active Directory do not contain settings for managing new auditing subcategories. To properly apply the auditing policies prescribed in this guide, this setting is configured to Enabled for both the EC and SSLF environments. Note An extensive discussion of auditing methods appears separately in this appendix. Audit: Shut down system immediately if unable to log security audits This policy setting determines whether the system shuts down if it is unable to log Security events. It is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log them. Microsoft has chosen to meet this requirement by halting the system and displaying a stop message if the auditing system experiences a failure. When this policy setting is enabled, the system will shut down if a security audit cannot be logged for any reason. If you enable setting, unplanned system failures can occur. Therefore, this policy setting is configured to Not Defined for the EC environment and Disabled for the SSLF environment. DevicesThe following table summarizes the values and recommendations for security setting options that affect devices in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A8. Windows Server 2008 Security Options Setting Recommendations - Devices
Devices: Allow undock without having to log on This policy setting determines whether a user can undock a portable computer from a docking station if the user does not first log on to the system. You can enable this policy setting to eliminate a logon requirement and allow use of an external hardware eject button to undock the computer. If you disable this policy setting, a user must log on and have been assigned the Remove computer from docking station user right to undock the computer. This setting is not usually relevant for production servers. Devices: Allowed to format and eject removable media This policy setting determines who is allowed to format and eject removable media. You can use this policy setting to prevent unauthorized users from removing data on one computer to access it on another computer on which they have local administrator privileges. Devices: Prevent users from installing printer drivers It is feasible for an attacker to disguise a Trojan horse program as a printer driver. The program may appear to users as if they must use it to print, but such a program could unleash malicious code on your computer network. To reduce the possibility of such an event, only administrators should be allowed to install printer drivers. Devices: Restrict CD-ROM access to locally logged on user only This policy setting determines whether the CD-ROM drive is accessible to both local and remote users simultaneously. If you enable this policy setting, and someone is interactively logged on, no users are allowed to access media from the CD-ROM drive over the network. When this policy setting is enabled and no one is logged on, a user can access a shared CD-ROM drive over the network. If you enable this setting, the Windows Backup utility can fail if volume shadow copies were specified for the backup job and someone was interactively logged on. Any third-party backup products that use volume shadow copies can also fail. Devices: Restrict floppy access to locally logged on user only This policy setting determines whether the floppy drive is accessible to both local and remote users simultaneously. If you enable this policy setting, only interactively logged on users are allowed to access floppy drive media. When this policy setting is enabled and no one is logged on, a user can access floppy drive media over the network. If you enable this setting, the Windows Backup utility will fail if volume shadow copies were specified for the backup job. Any third-party backup products that use volume shadow copies will also fail. Domain ControllerThe following table summarizes the values and recommendations for security setting options that apply to domain controllers in Windows Server 2008. The subsections after the table provide more detailed information about each setting. Table A9. Windows Server 2008 Security Options Setting Recommendations - Domain Controller
Domain Controller: Allow server operators to schedule tasks This policy setting determines if members of the Server Operators group can schedule tasks with the AT command. This does not affect the Task Scheduler service. Domain Controller: LDAP server signing requirements This policy setting determines whether the LDAP server requires signing to be negotiated with LDAP clients. If you set the server to Require Signature, you must also set the client. Not setting the client results in loss of connection with the server. This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL. If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected. Domain controller: Refuse machine account password changes This policy setting determines whether domain controllers will refuse requests from member computers to change computer account passwords. By default, member computers change their computer account passwords every 30 days. If enabled, the domain controller will refuse computer account password change requests. Domain MemberThe following table summarizes the values and recommendations for security setting options that affect domain members running Windows Server 2008. Domain controllers are also domain members. The subsections after the table provide more detailed information about each setting. Table A10. Windows Server 2008 Security Options Setting Recommendations - Domain Members
Domain member: Digitally encrypt or sign secure channel data (always) This policy setting determines whether all secure channel traffic that is initiated by the domain member must be signed or encrypted. If a system is set to always encrypt or sign secure channel data, it cannot establish a secure channel with a domain controller that is not capable of signing or encrypting all secure channel traffic, because all secure channel data is signed and encrypted. Domain member: Digitally encrypt secure channel data (when possible) This policy setting determines whether a domain member should attempt to negotiate encryption for all secure channel traffic that it initiates. If you enable this policy setting, the domain member will request encryption of all secure channel traffic. If you disable this policy setting, the domain member will be prevented from negotiating secure channel encryption. Domain member: Digitally sign secure channel data (when possible) This policy setting determines whether a domain member should attempt to negotiate whether all secure channel traffic that it initiates must be digitally signed. Digital signatures protect the traffic from being modified by anyone who captures the data as it traverses the network. Domain member: Disable machine account password changes This policy setting determines whether a domain member can periodically change its computer account password. If you enable this policy setting, the domain member will be prevented from changing its computer account password. If you disable this policy setting, the domain member can change its computer account password as specified by the Domain Member: Maximum machine account password age setting, which by default is every 30 days. Computers that cannot automatically change their account passwords are potentially vulnerable, because an attacker might be able to determine the password for the system's domain account. Domain member: Maximum machine account password age This policy setting determines the maximum allowable age for a computer account password. By default, domain members automatically change their domain passwords 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 would have more time to undertake a brute force attack against one of the computer accounts. Domain member: Require strong (Windows 2000 or later) session key When this policy setting is enabled, a secure channel can only be established with domain controllers that are capable of encrypting secure channel data with a strong (128-bit) session key. To enable this policy setting, all domain controllers in the domain must be able to encrypt secure channel data with a strong key, which means all domain controllers must be running Microsoft Windows 2000 or later. If communication to non-Windows 2000–based domains is required, Microsoft recommends that you disable this policy setting. Interactive LogonThe following table summarizes the values and recommendations for security setting options that affect interactive logons in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A11. Windows Server 2008 Security Options Setting Recommendations - Interactive Logon
Interactive Logon: Do not display last user name This policy setting determines whether the account name of the last user to log on to the client computers in your organization will be displayed in each computer's respective Windows logon screen. Enable this policy setting to prevent intruders from collecting account names visually from the screens of desktop or laptop computers in your organization. Interactive Logon: Do not require CTRL+ALT+DEL The CTRL+ALT+DEL key combination establishes a trusted path to the operating system for users to type their user name and password. When this policy setting is enabled, users are not required to use this key combination to log on to the network. However, this configuration poses a security risk because it provides an opportunity for users to log on with weaker logon credentials. Interactive Logon: Message text for users attempting to log on This policy setting specifies a text message that displays to users when they log on. This text is often used for legal reasons—for example, to warn users about the ramifications of misusing company information or to warn them that their actions may be audited. The settings for Interactive logon: Message text for users attempting to log on and Interactive logon: Message title for users attempting to log on must both be enabled for either one to work properly. Note Any warning that you display should first be approved by your organization's legal and human resources representatives. Interactive Logon: Message title for users attempting to log on This policy setting allows text to be specified in the title bar of the window that users see when they log on to the system. The reason for this policy setting is the same as for the previous message text setting. Organizations that do not use this policy setting may be more legally vulnerable to trespassers who attack the system. The settings for Interactive logon: Message text for users attempting to log on and Interactive logon: Message title for users attempting to log on must both be enabled for either one to work properly. Note Any warning that you display should first be approved by your organization's legal and human resources representatives. Interactive Logon: Number of previous logons to cache (in case domain controller is not available) This policy setting determines whether a user can log on to a Windows domain using cached account information. Logon information for domain accounts can be cached locally to allow users to log on even if a domain controller cannot be contacted. This policy setting determines the number of unique users for whom logon information is cached locally. The default value for this policy setting is 10. If this value is set to 0, the logon cache feature is disabled. 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 determine user passwords. In all cases covered by this guide, Microsoft recommends that servers must always be securely connected to the network. Because cached information on the server creates a security risk, the recommended value for this setting is 0. Interactive Logon: Prompt user to change password before expiration This policy setting determines how far in advance users are warned that their password will expire. Microsoft recommends that you configure this policy setting to 14 days to sufficiently warn users when their passwords will expire. Interactive Logon: Require Domain Controller authentication to unlock workstation When this policy setting is enabled, a domain controller must authenticate the domain account used to unlock the computer. When this policy setting is disabled, cached credentials can be used to unlock the computer. 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. When configured to Lock Workstation, this policy setting locks the workstation when the smart card is removed, which allows users to leave the area, take their smart cards with them, and automatically lock their workstations. If you configure this policy setting to Force Logoff, users will be automatically logged off when the smart card is removed. Interactive Logon: Require smart card This policy setting requires users to log on to a computer with a smart card. Security is enhanced when users are required to use long, complex passwords for authentication, especially if they are required to change their passwords regularly. This approach reduces the chance that an attacker will be able to guess a user’s password by means of a brute force attack. However, it is difficult to make users choose strong passwords, and even strong passwords are still vulnerable to brute-force attacks. The use of smart cards instead of passwords for authentication dramatically increases security, because current technology makes it almost impossible for an attacker to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user must possess the smart card and know its PIN. An attacker who captures the authentication traffic between the user’s computer and the domain controller will find it extremely difficult to decrypt the traffic. Even if they can decrypt the traffic, the next time the user logs on to the network, a new session key will be generated to encrypt traffic between the user and the domain controller. Microsoft encourages organizations to migrate to smart cards or other strong authentication technologies. However, you should only enable the Interactive logon: Require smart card setting if smart cards are already deployed. In this guide, this policy setting is configured to Not Defined in the baseline policy for the EC environments and to Disabled in the baseline policy for the SSLF environment. However, if you have deployed smart cards in your environment, Microsoft recommends enabling this policy for maximum security. Microsoft Network ClientThe following table summarizes the values and recommendations for security setting options that affect the behavior of the Microsoft Network Client in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A12. Windows Server 2008 Security Options Setting Recommendations - Microsoft Network Client
Microsoft network client: Digitally sign communications (always) This policy setting determines whether packet signing is required by the SMB client component. If you enable this policy setting, the Microsoft network client computer cannot communicate with a Microsoft network server unless that server agrees to sign SMB packets. Note When Windows Vista–based computers have this policy setting enabled and they connect to file or print shares on remote servers, it is important that the setting is synchronized with its companion setting, Microsoft network server: Digitally sign communications (always), on those servers. For more information about these settings, see the companion guide, Threats and Countermeasures. Microsoft network client: Digitally sign communications (if server agrees) This policy setting determines whether the SMB client will attempt to negotiate SMB packet signing. Digital signing in Windows–based networks helps to prevent sessions from being hijacked. If you enable this policy setting, the Microsoft network client will use signing only if the server with which it communicates accepts digitally signed communication. Note Enable this policy setting on SMB client computers on your network to make them fully effective for packet signing with all client computers and servers in your environment. Microsoft network client: Send unencrypted password to third-party SMB servers Disable this policy setting to prevent the SMB redirector from sending plaintext passwords during authentication to third-party SMB servers that do not support password encryption. Microsoft recommends that you disable this policy setting unless there is a strong business case to enable it. If this policy setting is enabled, unencrypted passwords will be allowed across the network. Microsoft Network ServerThe following table summarizes the values and recommendations for security setting options that affect the behavior of Microsoft Network Server in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A13. Windows Server 2008 Security Options Setting Recommendations - Microsoft Network Server
Microsoft network server: Amount of idle time required before suspending session This policy setting allows you to specify 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. If client activity resumes, the session is automatically reestablished. Microsoft network server: Digitally sign communications (always) This policy setting determines if the server side SMB service is required to perform SMB packet signing. By default, domain controllers have this setting enabled in the default domain controller policy. To improve protection for the member servers in the EC and SSLF environments, Microsoft recommends that this policy is also enabled in the member server baseline policy. Microsoft network server: Digitally sign communications (if client agrees) This policy setting determines if the server side SMB service is able to sign SMB packets if it is requested to do so by a client that attempts to establish a connection. If no signing request comes from the client, a connection will be allowed without a signature if the Microsoft network server: Digitally sign communications (always) setting is not enabled. Note Enable this policy setting on SMB clients on your network to make them fully effective for packet signing with all client computers and servers in your environment. Microsoft network server: Disconnect clients when logon hours expire This policy setting determines whether to disconnect 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, the client computer session with the SMB service will be forcibly disconnected when the computer's logon hours expire. If you disable this policy setting, established client computer sessions will be maintained after the client computer’s logon hours expire. If you enable this setting you should also enable the Network security: Force logoff when logon hours expire setting. If your organization wants to enforce logon hours for users, it makes sense to enable this policy setting. MSS SettingsThe following settings include registry value entries that do not display by default through the Security Configuration Editor (SCE). These settings, which are all prefixed with MSS:, were developed by the Microsoft Solutions for Security group for previous security guidance. The GPOAccelerator for this guide modifies the SCE so that it properly displays the MSS settings. The following table summarizes the values and recommendations for MSS settings in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A14. Windows Server 2008 MSS Settings
MSS: (AutoAdminLogon) Enable Automatic Logon The registry value entry AutoAdminLogon was added to the template file in the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ registry key. The entry appears as MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) in the Security Configuration Editor. If you configure a computer for automatic logon, anyone who can physically gain access to the computer can also gain access to everything that is on the computer, including any network or networks to which the computer is connected. Also, if you enable automatic logon, the password is stored in the registry in plaintext, and the specific registry key that stores this value is remotely readable by the Authenticated Users group. For additional information, see "How to turn on automatic logon in Windows XP": Knowledge Base article 315231. MSS: (DisableIPSourceRouting) IP source routing protection level The registry value entry DisableIPSourceRouting was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing) in the SCE. IP source routing is a mechanism that allows the sender to determine the IP route that a datagram should take through the network. MSS: (EnableDeadGWDetect) Allow automatic detection of dead network gateways The registry value entry EnableDeadGWDetect was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (EnableDeadGWDetect) Allow automatic detection of dead network gateways (could lead to DoS) in the SCE. When dead gateway detection is enabled, the IP may change to a backup gateway if a number of connections experience difficulty. MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes The registry value entry EnableICMPRedirect was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes in the SCE. Internet Control Message Protocol (ICMP) redirects causes the stack to plumb host routes. These routes override the Open Shortest Path First (OSPF)–generated routes. MSS: (Hidden) Hide Computer From the Browse List The registry value entry Hidden was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters\ registry key. The entry appears as MSS: (Hidden) Hide Computer From the Browse List (not recommended except for highly secure environments) in the SCE. You can configure a computer so that it does not send announcements to browsers on the domain. If you do so, you hide the computer from the Browse list, which means that the computer will stop announcing itself to other computers on the same network. An attacker who knows the name of a computer can more easily gather additional information about the system. You can enable this setting to remove one method that an attacker might use to gather information about computers on the network. Also, this setting can help reduce network traffic when enabled. However, the security benefits of this setting are small because attackers can use alternative methods to identify and locate potential targets. For additional information, see "HOW TO: Hide a Windows 2000-Based Computer from the Browser List": Knowledge Base article 321710. MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds The registry value entry KeepAliveTime was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds (300,000 is recommended) in the SCE. This value controls how often TCP attempts to verify that an idle connection is still intact by sending a keep-alive packet. If the remote computer is still reachable, it acknowledges the keep-alive packet. MSS: (NoDefaultExempt) Configure IPSec exemptions for various types of network traffic The registry value entry NoDefaultExempt was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\ registry key. The entry appears as MSS: (NoDefaultExempt) Configure IPSec exemptions for various types of network traffic in the SCE. The default exemptions to IPsec policy filters are documented in the online help for the specific operating system. These filters make it possible for Internet Key Exchange (IKE) and the Kerberos authentication protocol to function. The filters also make it possible for the network Quality of Service (QoS) to be signaled (RSVP) when the data traffic is secured by IPsec, and for traffic that IPsec might not secure such as multicast and broadcast traffic. IPsec is increasingly used for basic host-firewall packet filtering, particularly in Internet-exposed scenarios, and the affect of these default exemptions has not been fully understood. Therefore, some IPsec administrators may create IPsec policies that they think are secure, but are not actually secure against inbound attacks that use the default exemptions. Microsoft recommends that you enforce the default setting in Windows Server 2008, Windows Vista, and Windows XP with SP2. Multicast, broadcast, and ISAKMP are exempt for both of the environments that are discussed in this guide. For more information, see "IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios": Knowledge Base article 811832. MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives The registry value entry NoDriveTypeAutoRun was added to the template file in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\ registry key. The entry appears as MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives (recommended) in the SCE. AutoRun starts to read from a drive on your computer as soon as media is inserted into it. As a result, the setup file of programs and the sound on audio media starts immediately. This setting is configured to 255, Disable Autorun for all drives for both the EC and SSLF environments. MSS: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers The registry value entry NoNameReleaseOnDemand was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters\ registry key. The entry appears as MSS: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers in the SCE. NetBIOS over TCP/IP is a network protocol that among other things provides a way to easily resolve NetBIOS names that are registered on Windows–based systems to the IP addresses that are configured on those systems. This setting determines whether the computer releases its NetBIOS name when it receives a name-release request. MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames The registry value entry NtfsDisable8dot3NameCreation was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\ registry key. The entry appears as MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames (recommended) in the SCE. Windows Server 2008 supports 8.3 file name formats for backward compatibility with older applications. However on systems that do not required these legacy applications, such as the SSLF environment, Microsoft recommends to enable this option. Note Scripts that attempt to access a long file name using its 8.3 file name equivalent also are affected by this setting. Ensure to test any critical installation or login scripts when implementing this setting. MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure Default Gateway addresses The registry value entry PerformRouterDiscovery was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure Default Gateway addresses (could lead to DoS) in the SCE. This setting is used to enable or disable the Internet Router Discovery Protocol (IRDP), which allows the system to detect and configure default gateway addresses automatically as described in RFC 1256 on a per-interface basis. MSS: (SafeDllSearchMode) Enable Safe DLL Search Order The registry value entry SafeDllSearchMode was added to the template file in the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\ registry key. The entry appears as MSS: (SafeDllSearchMode) Enable Safe DLL search mode (recommended) in the SCE. You can configure the DLL search order to search for DLLs that are requested by running processes in one of two ways:
When enabled, the registry value is set to 1. With a setting of 1, the system first searches the folders that are specified in the system path and then searches the current working folder. When disabled the registry value is set to 0 and the system first searches the current working folder and then searches the folders that are specified in the system path. MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires The registry value entry ScreenSaverGracePeriod was added to the template file in the HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ registry key. The entry appears as MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended) in the SCE. Windows includes a grace period between when the screen saver is launched and when the console is actually locked automatically when screen saver locking is enabled. MSS: (SynAttackProtect) Syn attack protection level The registry value entry SynAttackProtect was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (SynAttackProtect) Syn attack protection level (protects against DoS) in the SCE. This setting causes TCP to adjust retransmission of SYN-ACKs. When you configure this value, the connection responses time out more quickly if a connect request (SYN) attack is detected. MSS: (TCPMaxConnectResponseRetransmissions) SYN-ACK retransmissions when a connection request is not acknowledged The registry value entry TCPMaxConnectResponseRetransmissions was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (TcpMaxConnectResponseRetransmissions) SYN-ACK retransmissions when a connection request is not acknowledged in the SCE. This setting determines the number of times that TCP retransmits a SYN before the attempt to connect is aborted. The retransmission time-out is doubled with each successive retransmission in a given connect attempt. The initial time-out value is three seconds. MSS: (TCPMaxDataRetransmissions) How many times unacknowledged data is retransmitted The registry value entry TCPMaxDataRetransmissions was added to the template file in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key. The entry appears as MSS: (TcpMaxDataRetransmissions) How many times unacknowledged data is retransmitted (3 recommended, 5 is default) in the SCE. This setting controls the number of times that TCP retransmits an individual data segment (non-connect segment) before the connection is aborted. The retransmission time-out is doubled with each successive retransmission on a connection. It is reset when responses resume. The base time-out value is dynamically determined by the measured round-trip time on the connection. MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning The registry value entry WarningLevel was added to the template file in the HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\Eventlog\Security\ registry key. The entry appears as MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning in the SCE. This setting can generate a security audit in the Security event log when the log reaches a user-defined threshold. Note If log settings are configured to Overwrite events as needed or Overwrite events older than x days, this event will not be generated. Network AccessThe following table summarizes the values and recommendations for security setting options that affect network access in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A15. Windows Server 2008 Security Options Setting Recommendations - Network Access
Note § - Denotes Group Policy settings that are new in Windows Vista or Windows Server 2008. Network access: Allow anonymous SID/Name translation This policy setting determines whether an anonymous user can request security identifier (SID) attributes for another user, or use a SID to obtain its corresponding user name. Disable this policy setting to prevent unauthenticated users from obtaining user names that are associated with their respective SIDs. Network access: Do not allow anonymous enumeration of SAM accounts This policy setting controls the ability of anonymous users to enumerate the accounts in the Security Accounts Manager (SAM). If you enable this policy setting, users with anonymous connections cannot enumerate domain account user names on the workstations in your environment. This policy setting also allows additional restrictions on anonymous connections. Network access: Do not allow anonymous enumeration of SAM accounts and shares This policy setting controls the ability of anonymous users to enumerate SAM accounts as well as shares. If you enable this policy setting, anonymous users will not be able to enumerate domain account user names and network share names on the workstations in your environment. Network access: Do not allow storage of credentials or .NET Passports for network authentication This policy setting controls whether or not authentication credentials can be stored (cached) by Credential Manager or by Stored User Names and Passwords on the local system for later use. This includes the storage of Windows logon credentials for local accounts on other Windows computers, and user name and password information for Web sites or programs. Network access: Let Everyone permissions apply to anonymous users This policy setting determines what additional permissions are assigned for anonymous connections to the computer. If you enable this policy setting, anonymous Windows users are allowed to perform certain activities, such as enumerate the names of domain accounts and network shares. An unauthorized user could anonymously list account names and shared resources and use the information to guess passwords or perform social engineering attacks. 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. For the EC environment the Network access: Named Pipes that can be accessed anonymously setting is configured to Not Defined. However, the following default values are enforced for the member servers in SSLF environment:
Network access: Remotely accessible registry paths This policy setting determines which registry paths will be accessible after referencing the WinReg key to determine access permissions to the paths. 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. Network access: Restrict anonymous access to Named Pipes and Shares When enabled, this policy setting restricts anonymous access to only those shares and pipes that are named by the following settings:
This policy setting controls null session access to shares on your computers by adding RestrictNullSessAccess with the value 1 in the HKLM\System\CurrentControlSet\Services\LanManServer\Parameters registry key. This registry value toggles null session shares on or off to control whether the server service restricts unauthenticated client computer access to named resources. Null sessions are a weakness that can be exploited through shares (including the default shares) on computers in your environment. Network access: Shares that can be accessed anonymously This policy setting determines which network shares that anonymous users can access. The default configuration for this policy setting has little effect because all users have to be authenticated before they can access shared resources on the server. This setting is configured to Not Defined for the EC environment. However, ensure that this setting is configured to None for the SSLF environment. Caution It can be very dangerous to add other shares to this Group Policy setting. Any network user can access any shares that are listed, which could expose or corrupt sensitive data. Network access: Sharing and security model for local accounts This policy setting determines how network logons that use local accounts are authenticated. The Classic option allows precise control over access to resources, including the ability to assign different types of access to different users for the same resource. The Guest only option allows you to treat all users equally. In this context, all users authenticate as Guest only to receive the same access level to a given resource. Network SecurityThe following table summarizes the values and recommendations for security setting options that affect network security in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A16. Windows Server 2008 Security Options Setting Recommendations - Network Security
Network security: Do not store LAN Manager hash value on next password change This policy setting determines whether the LAN Manager (LM) hash value for the new password is stored when the password is changed. The LM hash is relatively weak and prone to attack compared to the cryptographically stronger Microsoft Windows NT® hash. Note Older operating systems and some third-party applications may fail when this policy setting is enabled. Also you will need to change the password on all accounts after you enable this setting. Network security: Force logoff when logon hours expire This policy setting, which determines whether to disconnect users who are connected to the local computer outside their user account’s valid logon hours, affects the SMB component. If you enable this policy setting, client computer sessions with the SMB server will be disconnected when the client computer’s logon hours expire. If you disable this policy setting, established client computer sessions will be maintained after the client’s logon hours expire. Network security: LAN Manager authentication level This policy setting specifies the type of challenge/response authentication for network logons. LAN Manager (LM) authentication is the least secure method. This method allows encrypted passwords to be cracked because they can be easily intercepted on the network. NT LAN Manager (NTLM) is somewhat more secure. NTLMv2 is a more robust version of NTLM that is available in Windows Vista, Windows XP Professional, Windows Server 2003, Windows 2000, and Windows NT 4.0 Service Pack 4 (SP4) or later. NTLMv2 is also available for Windows 95 and Windows 98 with the optional Directory Services Client. Microsoft recommends that you configure this policy setting to the strongest possible authentication level for your environment. In environments that run only Windows 2000 Server, Windows Server 2008 or Windows Server 2003 with Windows Vista or Windows XP Professional–based workstations, configure this policy setting to the Send NTLMv2 response only. Refuse LM and NTLM option for the highest security. The Network security: LAN Manager authentication level setting is configured to Send NTLMv2 response only. Refuse the LM option for the EC environment. However, this policy setting is configured to the more restrictive Send NTLMv2 response only, and also refuses the LM and NTLM options for the SSLF environment. 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. Because unsigned network traffic is susceptible to man-in-the-middle attacks, an attacker could cause an LDAP server to make decisions that are based on false queries from the LDAP client. Network security: Minimum session security for NTLM SSP based (including secure RPC) clients This policy setting determines the minimum application-to-application communications security standards for client computers. The options for this policy setting are:
If all of the computers on your network can support NTLMv2 and 128-bit encryption (for example, Windows Vista, Windows XP Professional SP2 and Windows Server 2003 SP1 and Windows Server 2008), you can select all four setting options for maximum security. Network security: Minimum session security for NTLM SSP based (including secure RPC) servers This policy setting is similar to the previous setting, but affects the server side of communication with applications. The options for the setting are the same:
If all of the computers on your network can support NTLMv2 and 128-bit encryption (for example, Windows Vista, Windows XP Professional SP2 and Windows Server 2003 SP1 or Windows Server 2008), you can select all four options for maximum security. Recovery ConsoleThe following table summarizes the values and recommendations for security setting options that affect the recovery console in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A17. Windows Server 2008 Security Options Setting Recommendations - Recovery Console
Recovery console: Allow automatic administrative logon The recovery console is a command-line environment that is used to recover from system problems. If you enable this policy setting, the administrator account is automatically logged on to the recovery console when it is invoked during startup. Microsoft recommends that you disable this policy setting, which will require administrators to enter a password to access the recovery console. Recovery console: Allow floppy copy and access to all drives and all folders This policy setting makes the Recovery Console SET command available, which allows you to set the following recovery console environment variables:
ShutdownThe following table summarizes the values and recommendations for security setting options that affect system shutdown in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A18. Windows Server 2008 Security Options Setting Recommendations - Shutdown
Shutdown: Allow system to be shut down without having to log on This policy setting determines whether a computer can be shut down when a user is not logged on. If this policy setting is enabled, the shutdown command is available on the Windows logon screen. Microsoft recommends that you disable this policy setting to restrict the ability to shut down the computer to users with credentials on the system. Shutdown: Clear virtual memory pagefile This policy setting determines whether the virtual memory pagefile is cleared when the system is shut down. When this policy setting is enabled, the system pagefile is cleared each time that the computer shuts down properly. The process to clear the pagefile can take a significant amount of time especially on servers with many gigabytes of memory. Therefore, Microsoft recommends to disable this setting for servers that are in protected environments. Only enable this setting on computers that are used in high risk environment, such as portable laptop computers. System CryptographyThe following table summarizes the values and recommendations for security setting options that affect cryptography in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A19. Windows Server 2008 Security Options Setting Recommendations - Network Security
System cryptography: Force strong key protection for user keys stored on the computer This policy setting determines whether users' private keys (such as their S-MIME keys) require a password to be used. If you configure this policy setting so that users must provide a password — distinct from their domain password — every time that they use a key, it will be more difficult for an attacker to access locally stored keys, even an attacker who discovers logon passwords. For usability requirements in the EC environment, the System cryptography: Force strong key protection for user keys stored on the computer setting is configured to User is prompted when the key is first used in the baseline policy. To provide additional security, this policy setting is configured to User must enter a password each time they use a key for the SSLF environment. System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing This policy setting determines whether the Transport Layer Security/Secure Sockets Layer (TLS/SSL) Security Provider supports only the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. Although this policy setting increases security, most public Web sites that are secured with TLS or SSL do not support these algorithms. Client computers that have this policy setting enabled will also be unable to connect to Terminal Services on servers that are not configured to use the FIPS compliant algorithms. Note If you enable this policy setting, computer performance will be slower because the 3DES process is performed on each block of data in the file three times. This policy setting should only be enabled if your organization is required to be FIPS compliant. System ObjectsThe following table summarizes the values and recommendations for security setting options that affect the behavior of system objects in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A20. Windows Server 2008 Security Options Setting Recommendations - System Objects
System objects: Require case insensitivity for non-Windows subsystems This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32® subsystem is case insensitive. However, the kernel supports case sensitivity for other subsystems, such as the Portable Operating System Interface for UNIX (POSIX). Because Windows is case insensitive (but the POSIX subsystem will support case sensitivity), failure to enforce this policy setting makes it possible for a user of the POSIX subsystem to create a file with the same name as another file by using mixed case to label it. Such a situation can block access to these files by another user who uses typical Win32 tools, because only one of the files will be available. System objects: Strengthen default permissions of internal system objects This policy setting determines the strength of the default discretionary access control list (DACL) for system objects (for example, Symbolic Links). The setting helps secure objects that can be located and shared among processes and its default configuration strengthens the DACL, because it allows users who are not administrators to read shared objects but does not allow them to modify any that they did not create. System SettingsThe following table summarizes the values and recommendations for security setting options that affect system settings in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A21. Windows Server 2008 Security Options Setting Recommendations - Network Security
System settings: Optional subsystems This policy setting determines which subsystems are used to support applications in your environment. The default value for this policy setting is POSIX. To disable the POSIX subsystem, the System settings: Optional subsystems setting is configured to None in the baseline policy for both environments that are defined in this guide. Note The recommended configuration interferes with the proper functionality of the Subsystems for UNIX-based Applications (SUA) feature in Windows Server 2008 and Windows Vista. For this feature to work properly, this policy setting must include POSIX in its configuration. 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. It 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 the execution of Authenticode®-signed software, based on the digital certificate that is associated with the software. For certificate rules to take effect in software restriction policies, you must enable this policy setting. The System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies setting is configured to Enabled in the SSLF environment. However, it is configured to Not Defined in the EC environment because of the potential performance impact. User Account ControlUser Account Control (UAC) reduces the exposure and attack surface of the operating system by requiring that all users run in standard user mode, even if they have logged on with administrative credentials. This limitation helps minimize the ability for users to make changes that could destabilize their computers or inadvertently expose the network to viruses through undetected malware that has infected the computer. When a user attempts to perform an administrative task, the operating system must raise their security level to allow the task to take place. The UAC settings in GPOs configure how the operating system responds to a request to heighten security privileges. The following table summarizes the values and recommendations for security setting options that affect User Account Control in Windows Server 2008 for domain controllers and member servers. The subsections after the table provide more detailed information about each setting. Table A22. Windows Server 2008 Security Options Setting Recommendations - User Account Control
Note § - Denotes Group Policy settings that are new in Windows Vista or Windows Server 2008. User Account Control: Admin Approval Mode for the Built-in Administrator account This policy setting configures whether the built-in Administrator account runs in Admin Approval Mode. User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop This policy setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts for a standard user. If you enable this setting, UIA programs, including Windows Remote Assistance, can automatically disable the secure desktop for elevation prompts. Therefore, unless you have also disabled elevation prompts, the prompts will appear on the interactive user's desktop instead of the secure desktop. UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but allowing elevation requests to appear on the regular interactive desktop instead of the secure desktop increases your security risk. While this setting applies to any UIA program, it will be used primarily in certain Windows Remote Assistance scenarios. If a user requests remote assistance from an administrator and the remote assistance session is established, any elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user may select the Allow IT Expert to respond to User Account Control prompts check box when setting up the remote assistance session. However, selecting this check box itself requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation. If you enable the User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop setting, requests for elevation are automatically sent to the interactive desktop (not the secure desktop) and also appear on the remote administrator's view of the desktop during a Windows Remote Assistance session, and the remote administrator is able to provide the appropriate credentials for elevation. This setting does not change the behavior of the UAC elevation prompt for administrators. User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode This policy setting determines the behavior of Windows when a logged on administrator attempts to complete a task that requires raised privileges. There are three options for this setting:
User Account Control: Behavior of the elevation prompt for standard users This policy setting determines the behavior of Windows when a logged on user (that is, a user who is not an administrator) attempts to complete a task that requires raised privileges. There are two options for this setting:
This policy setting prevents standard users from elevating their privileges. In other words, a standard user cannot provide administrative account credentials to perform an administrative task. Right-clicking a program file and selecting Run as administrator will not work for the standard user. Standard users who need to perform administrative tasks must log off and then log back on using their administrative account to complete an administrative task. Although this process is somewhat inconvenient, it does help better secure your environment. User Account Control: Detect application installations and prompt for elevation This policy setting determines how Windows responds to application installation requests that occur while a standard user (non-administrator) is logged on. Application installation requires an elevation of privilege. There are two options for this setting:
User Account Control: Only elevate executables that are signed and validated This policy setting enables the prevention of the execution of unsigned or invalidated applications. Before enabling this setting, it is essential that administrators are certain that all required applications are signed and valid. There are two options for this setting:
User Account Control: Only elevate UIAccess applications that are installed in secure locations This policy security setting will enforce the requirement that applications that request execution with a UIAccess integrity level (via a marking of UIAccess=true in their application manifest), must reside in a secure location on the file system, such as the Program Files or the Windows System directories. If this setting is enabled, an application that asserts it is a UIAccess application will only be allowed to launch if it resides in one of the secure locations in the file system. Note Windows enforces a PKI signature check on any interactive application that requests execution with UIAccess integrity level regardless of the state of this security setting. User Account Control: Run all administrators in Admin Approval Mode This policy setting effectively disables UAC. There are two options for this setting:
User Account Control: Switch to the secure desktop when prompting for elevation This policy setting helps protect the computer and user from malicious use of the elevation prompt. The Windows secure desktop can only run SYSTEM processes, which generally eliminates messages from malicious software. As a result, consent and credential prompts generally cannot be easily input spoofed on the secure desktop. In addition, the consent prompt is protected from output spoofing. However, note that there is still a risk when using elevation and the credential prompt because malware may be able to spoof the secure desktop by imitating the visual style and graphics. It is more secure to perform administrative tasks only when logged on as the administrator. There are two options for this setting:
User Account Control: Virtualize file and registry write failures to per-user locations Applications that lack an application compatibility database entry or a requested execution level marking in the application manifest are not UAC-compliant. Applications that are not UAC-compliant try to write to protected areas including Program Files and %systemroot%. These applications will display an error message or fail if they cannot complete the write process. If you enable this policy setting, you allow Windows Vista to virtualize file and registry writes to user locations enabling the application to run. UAC-compliant applications should not write to protected areas and cause write failures. As a result, environments that are only utilizing UAC-compliant applications should disable this setting. There are two possible values for this setting:
If you are not certain that all applications in your environment are UAC-compliant, you should configure this setting to Enabled. Event Log Security SettingsThe event log records events on the system, and the Security log records audit events. The event log container of Group Policy is used to define attributes that are related to the Application, Security, and System event logs, such as maximum log size, access rights for each log, and retention settings and methods. You can configure the event log settings in the following location in the Group Policy Object Editor: Computer Configuration\Windows Settings\Security Settings\Event Log This section provides details about the prescribed settings for the environments that are discussed in this guide. For a summary of the prescribed settings in this section, see the Windows Server 2008 Security Guide Settings workbook. For information about the default settings and a detailed explanation of each of the settings discussed in this section, see the companion guide, Threats and Countermeasures. This companion guide also includes detailed information about the potential for lost event log data when the log sizes are set to very large values. The following table summarizes the recommended event log security settings for the domain controllers and member server computers in both the EC and SSLF environments of this guide. The following subsections provide detailed information about each of the settings. Table A23. Windows Server 2008 Security Option Setting Recommendations – Event Log Security Settings
Maximum application log size This policy setting specifies the maximum size of the Application event log, which has a maximum capacity of 4 GB. However, this size is not recommended because of the risk of memory fragmentation, which causes slow performance and unreliable event logging. Requirements for the Application log size vary, and depend on the function of the platform and the need for historical records of application-related events. The Maximum application log size setting is configured to 32768 KB for all computers in the two environments that are discussed in this guide. Maximum security log size This policy setting specifies the maximum size of the Security event log, which has a maximum capacity of 4 GB. However, this size is not recommended because of the risk of memory fragmentation, which causes slow performance and unreliable event logging. Requirements for the Security log size vary, and depend on the function of the platform and the need for historical records of application-related events. The Maximum security log size setting is configured to 81920 KB for all computers in the two environments that are discussed in this guide. Maximum system log size This policy setting specifies the maximum size of the System event log, which has a maximum capacity of 4 GB. However, this size is not recommended because of the risk of memory fragmentation, which leads to slow performance and unreliable event logging. Requirements for the application log size vary depending on the function of the platform and the need for historical records of application related events. The Maximum system log size setting is configured to 32768 KB for all computers in the two environments that are discussed in this guide. Retention method for application log This policy setting determines the "wrapping" method for the Application log. It is imperative that the Application log is archived regularly if historical events are desirable for either forensics or troubleshooting purposes. Overwriting events as needed ensures that the log always stores the most recent events, although this configuration could result in a loss of historical data. The Retention method for application log is configured to As Needed for both of the environments that are discussed in this guide. Retention method for security log This policy setting determines the "wrapping" method for the Security log. It is imperative that the Security log is archived regularly if historical events are desirable for either forensics or troubleshooting purposes. Overwriting events as needed ensures that the log always stores the most recent events, although this configuration could result in a loss of historical data. The Retention method for security log is configured to As Needed for both of the environments that are discussed in this guide. Retention method for system log This policy setting determines the "wrapping" method for the System log. It is imperative that the System log is archived regularly if historical events are desirable for either forensics or troubleshooting purposes. Overwriting events as needed ensures that the log always stores the most recent events, although this configuration could result in a loss of historical data. The Retention method for system log is configured to As Needed for both of the environments that are discussed in this guide.
|
|
.jpg)