Threats and Countermeasures

The Security Options section of Group Policy enables or disables computer security settings for digital data signatures, Administrator and Guest account names, access to floppy disk and CD-ROM drives, driver installation behavior, and logon prompts. The Microsoft® Excel® workbook "Windows Default Security and Services Configuration" (included with the downloadable version of this guide) documents the default settings.

On This Page

	Security Options Settings
	More Information

Security Options Settings

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

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

Accounts: Administrator account status

This policy setting enables or disables the Administrator account for normal operational conditions. If you start a computer in safe mode, the Administrator account is always enabled, regardless of how you configure this policy setting.

The possible values for the Accounts: Administrator account status setting are:

Vulnerability

In some organizations, it can be a daunting management challenge to maintain a regular schedule for periodic password changes for local accounts. Therefore, you may want to disable the built-in Administrator account instead of relying on regular password changes to protect it from attack. Another reason to disable this built-in account is that it cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID) and there are third-party tools that allow authentication by using the SID rather than the account name. This capability means that even if you rename the Administrator account, an attacker could launch a brute force attack by using the SID to log on.

Countermeasure

Configure the Accounts: Administrator account status setting to Disabled so that the built-in Administrator account is no longer usable in a normal system startup.

Potential Impact

Maintenance issues can arise under certain circumstances if you disable the Administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there is no other local Administrator account, you must restart in safe mode to fix the problem that broke the secure channel.

If the current Administrator password does not meet the password requirements, you will not be able to re-enable the Administrator account after it is disabled. If this situation occurs, another member of the Administrators group must set the password on the Administrator account with the Local Users and Groups tool.

Accounts: Guest account status

This policy setting determines whether the Guest account is enabled or disabled.

The possible values for the Accounts: Guest account status setting are:

Vulnerability

The default Guest account allows unauthenticated network users to log on as Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any network shares with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network, which could lead to the exposure or corruption of data.

Countermeasure

Configure the Accounts: Guest account status setting to Disabled so that the built-in Guest account is no longer usable.

Potential Impact

All network users will need to authenticate before they can access shared resources. If you disable the Guest account and the Network Access: Sharing and Security Model option is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail. This policy setting should have little impact on most organizations because it is the default setting in Microsoft Windows® 2000, Windows XP, and Windows Server™ 2003.

Accounts: Limit local account use of blank passwords to console logon only

This policy setting determines whether remote interactive logons by network services such as Terminal Services, Telnet, and File Transfer Protocol (FTP) are allowed for local accounts that have blank passwords. If you enable this policy setting, a local account must have a non-blank password to perform an interactive or network logon from a remote client.

The possible values for the Accounts: Limit local account use of blank passwords to console logon only setting are:

Note: This policy setting does not affect interactive logons that are performed physically at the console or logons that use domain accounts.

Caution: It is possible for third-party applications that use remote interactive logons to bypass this policy setting.

Vulnerability

Blank passwords are a serious threat to computer security and should be forbidden through both organizational policy and suitable technical measures. In fact, the default settings for Windows Server  2003 Active Directory® directory service domains require complex passwords of at least seven characters. However, if a user with the ability to create new accounts bypasses your domain-based password policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts could then use it to log on.

Countermeasure

Enable the Accounts: Limit local account use of blank passwords to console logon only setting.

Potential Impact

None. This is the default configuration.

Accounts: Rename administrator account

This policy setting determines whether a different account name is associated with the SID for the Administrator account.

The possible values for the Accounts: Rename administrator account setting are:

Vulnerability

The Administrator account exists on all computers that run the Windows 2000, Windows Server 2003, or Windows XP Professional operating systems. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination.

The built-in Administrator account cannot be locked out, regardless of how many times an attacker might use a bad password. This capability makes the Administrator account a popular target for brute force attacks that attempt to guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and there are third-party tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute force attack by using the SID to log on.

Countermeasure

Specify a new name in the Accounts: Rename administrator account setting to rename the Administrator account.

Note: In later chapters this policy setting is not configured in the security templates, nor is a new username for the account suggested in the guide. The templates omit this policy setting so that the numerous organizations that use this guidance would not implement the same new username in their environments.

Potential Impact

You will have to inform users who are authorized to use this account of the new account name. (The guidance for this setting assumes that the Administrator account was not disabled, which was recommended earlier in this chapter.)

Accounts: Rename guest account

The Accounts: Rename guest account setting determines whether a different account name is associated with the SID for the Guest account.

The possible values for this Group Policy setting are:

Vulnerability

The Guest account exists on all computers that run the Windows 2000, Windows Server 2003, or Windows XP Professional operating systems. If you rename this account. it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination.

Countermeasure

Specify a new name in the Accounts: Rename guest account setting to rename the Guest account.

Note: In later chapters this policy setting is not configured in the security templates, nor is a new username for the account suggested in the guide. The templates omit this policy setting so that the numerous organizations that use this guidance would not implement the same new username in their environments.

Potential Impact

There should be little impact, because the Guest account is disabled by default in Windows 2000, Windows XP, and Windows Server 2003.

Audit: Audit the access of global system objects

If you enable this policy setting, a default system access control list (SACL) will be applied when the computer creates system objects such as mutexes, events, semaphores, and MS-DOS® devices. If you also enable the Audit object access audit setting as described in Chapter 3 of this guide, access to these system objects is audited.

Global system objects, also known as “base system objects” or “base named objects,” are ephemeral kernel objects that have had names assigned to them by the application or system component that created them. These objects are most commonly used to synchronize multiple applications or multiple parts of a complex application. Because they have names, these objects are global in scope, and therefore visible to all processes on the computer. These objects all have a security descriptor but typically have a NULL SACL. If you enable this policy setting at startup time, the kernel will assign a SACL to these objects when they are created.

The possible values for the Audit: Audit the access of global system objects setting are:

Vulnerability

A globally visible named object, if incorrectly secured, could be acted upon by a malicious program that knew the name of the object. For instance, if a synchronization object such as a mutex had a poorly chosen discretionary access control list (DACL), then a malicious program could access that mutex by name and cause the program that created it to malfunction. However, the risk of such an occurrence is very low.

Countermeasure

Enable the Audit: Audit the access of global system objects setting.

Potential Impact

If you enable the Audit: Audit the access of global system objects setting, a large number of security events could be generated, especially on busy domain controllers and application servers. Such an occurrence could cause servers to respond slowly and force the Security event log to record numerous events of little significance. This policy setting can only be enabled or disabled, and there is no way to filter which events are recorded and which are not. Even organizations that have the resources to analyze events that are generated by this policy setting would not likely have the source code or a description of what each named object is used for. Therefore, it is unlikely that many organizations could benefit from a configuration of Enabled for this policy setting.

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 policy settings, an audit event is generated for every file that is backed up or restored.

If you enable this policy setting in conjunction with the Audit privilege use setting, any exercise of user rights in the Security log is recorded. If you disable this policy setting, actions by users of Backup or Restore privileges are not audited, even if Audit privilege use is enabled.

The possible values for the Audit: Audit the use of Backup and Restore privilege setting are:

Vulnerability

If you enable this option when the Audit privilege use setting is also enabled, an audit event is generated for every file that is backed up or restored. This information could help you to identify an account that was used to accidentally or maliciously restore data in an unauthorized manner.

Countermeasure

Enable the Audit use of Backup and Restore privilege setting. Alternatively, implement automatic log backup by configuring the AutoBackupLogFiles registry key, which is described in the Microsoft Knowledge Base article "The event log stops logging events before reaching the maximum log size" at http://support.microsoft.com/default.aspx?kbid=312571.

Potential Impact

If you enable this policy setting, a large number of security events could be generated, which could cause servers to respond slowly and force the Security event log to record numerous events of little significance. If you increase the Security log size to reduce the chances of a system shutdown, an excessively large log file may affect system performance.

Audit: Shut down system immediately if unable to log security audits

This policy setting determines whether the computer shuts down if it is unable to log security events. The Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certifications require that the computer be able to prevent the occurrence of auditable events if the audit system is unable to log them. The way that Microsoft chose to meet this requirement is to halt the computer and display a stop message in the case of a failure of the audit system. If you enable this policy setting, the computer stops if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the Security event log is full and its specified retention method is either Do Not Overwrite Events or Overwrite Events by Days.

When this policy setting is enabled, the following Stop message displays if the security log is full and an existing entry cannot be overwritten:

STOP: C0000244 {Audit Failed}

An attempt to generate a security audit failed.

To recover, an administrator must log on, archive the log (optional), clear the log, and disable this option to allow the computer to be restarted. At that point, it may be necessary to manually clear the Security event log before you can configure this policy setting to Enabled.

The possible values for the Audit: Shut down system immediately if unable to log security audits setting are:

Vulnerability

If the computer is unable to record events to the Security log, then critical evidence or important troubleshooting information may not be available for review after a security incident. Also, an attacker could potentially generate a large volume of Security event log messages to purposely force a computer shutdown.

Countermeasure

Enable the Shut down system immediately if unable to log security audits setting.

Potential Impact

If you enable this policy setting, the administrative burden can be significant, especially if you also configure the Retention method for the Security log to Do not overwrite events (clear log manually). This configuration causes a repudiation threat (a backup operator could deny that they backed up or restored data) to become a denial of service (DoS) vulnerability, because a server could be forced to shut down if it is overwhelmed with logon events and other security events that are written to the Security log. Also, because the shutdown is not graceful, it is possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system (NTFS) guarantees its integrity if an ungraceful computer shutdown occurs, it cannot guarantee that every data file for every application will still be in a usable form when the computer restarts.

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

This policy setting allows administrators to define additional computer-wide access controls that govern access to all Distributed Component Object Model (DCOM)–based applications on a computer. These controls restrict call, activation, or launch requests on the computer. The simplest way to think about these access controls is as an additional access check call that is done against a computer-wide access control list (ACL) on each call, activation, or launch of any COM server on the computer. If the access check fails, the call, activation, or launch request will be denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM server on the computer. The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) setting controls access permissions to cover call rights.

These computer-wide ACLs provide a way to override weak security settings that are specified by a specific application through CoInitializeSecurity or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific server.

These ACLs provide a centralized location for an administrator to set general authorization policy that applies to all COM servers on the computer.

The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) setting allows you to specify an ACL in two different ways. You can type in the security descriptor in SDDL, or you can choose users and groups and grant or deny them Local Access and Remote Access permissions. Microsoft recommends that you use the built-in user interface to specify the ACL contents that you want to apply with this setting.  

Vulnerability

Many COM applications include some security-specific code (for example, to call CoInitializeSecurity) but use weak settings that often allow unauthenticated access to the process. Administrators cannot override these settings to force stronger security in earlier versions of Windows without modification of the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls.

Also, COM infrastructure includes the RPCSS, a system service that runs during computer startup and always runs after that. This service manages activation of COM objects and the running object table, and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM servers allow unauthenticated remote access (as explained in the previous section), these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users who use remote, unauthenticated computers.

Countermeasure

To protect individual COM-based applications or services, set the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) setting to an appropriate computer-wide ACL.

Potential Impact

Windows XP with SP2 and Windows Server 2003 with SP1 implement default COM ACLs as specified in their respective documentation. If you implement a COM server and you override the default security settings, confirm that the application-specific call permissions ACL assigns correct permission to appropriate users. If it does not, you will need to change your application-specific permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail.

Note: For more information about the default COM machine access restrictions that are applied in Windows XP with SP2, see the "Managing Windows XP Service Pack 2 Features Using Group Policy" guide at www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx. For information about the restrictions that are applied in Windows Server 2003 with SP1, see the "DCOM Security Enhancements" section in the "Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1" guide at http://technet2.microsoft.com/WindowsServer/en/library/ed9975ba-3933-4e28-bcb4-72b80d7865b71033.mspx. For more information about launch permissions, see the “LaunchPermission” page on Microsoft MSDN® at http://go.microsoft.com/fwlink/?LinkId=20924.

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

This policy setting is similar to the DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) setting in that it allows administrators to define additional computer-wide access controls that govern access to all DCOM–based applications on a computer. However, the ACLs that are specified in this policy setting control local and remote COM launch requests (not access requests) on the computer. The simplest way to think about this access control is as an additional access check call that is done against a computer-wide ACL on each launch of any COM server on the computer. If the access check fails, the call, activation, or launch request will be denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to launch any COM server on the computer. The earlier policy differs in that it provides a minimum access check that is applied to attempts to access an already launched COM server.

These computer-wide ACLs provide a way to override weak security settings that are specified by a specific application through CoInitializeSecurity or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific COM server. These ACLs provide a centralized location for an administrator to set general authorization policy that applies to all COM servers on the computer.

The DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) setting allows you to specify an ACL in two different ways. You can type in the security descriptor in SDDL, or you can choose users and groups and grant or deny them Local Access and Remote Access permissions. Microsoft recommends that you use the built-in user interface to specify the ACL contents that you want to apply with this setting.

Vulnerability

Many COM applications include some security-specific code (for example, to call CoInitializeSecurity) but use weak settings that often allow unauthenticated access to the process. Administrators cannot override these settings to force stronger security in earlier versions of Windows without modification of the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls.

Also, COM infrastructure includes the RPCSS, a system service that runs during computer startup and always runs after that. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM servers allow unauthenticated remote component activation (as explained in the previous section), these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users who use remote, unauthenticated computers.

Countermeasure

To protect individual COM-based applications or services, set the DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) setting to an appropriate machine-wide ACL.

Potential Impact

Windows XP with SP2 and Windows Server 2003 with SP1 implement default COM ACLs as specified in their respective documentation. If you implement a COM server and you override the default security settings, confirm that the application-specific launch permissions ACL assigns activation permission to appropriate users. If it does not, you will need to change your application-specific launch permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail.

Note: For more information about the default COM machine launch restrictions that are applied in Windows XP with SP2, see the "Managing Windows XP Service Pack 2 Features Using Group Policy" guide at www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx. For information about the restrictions that are applied in Windows Server 2003 with SP1, see the "DCOM Security Enhancements" section in the "Changes to Functionality in Microsoft Windows Server 2003 Service Pack 1" guide at www.microsoft.com/technet/prodtechnol/windowsserver2003/library/
BookofSP1/ed9975ba-3933-4e28-bcb4-72b80d7865b7.mspx. For more information about launch permissions, see the “LaunchPermission” page on MSDN at http://go.microsoft.com/fwlink/?LinkId=20924.

Devices: Allow undock without having to log on

This policy setting determines whether a user must log on to request permission to remove a portable computer from a docking station. If you enable this policy setting, users will be able to press a docked portable computer's physical eject button to safely undock the computer. If you disable this policy setting, the user must log on to receive permission to undock the computer. Only users who have the Remove Computer from Docking Station privilege can obtain this permission.

Note: You should only disable this policy setting for portable computers that cannot be mechanically undocked. Computers that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.

The possible values for the Devices: Allow undock without having to log on setting are:

Vulnerability

If this policy setting is enabled, anyone with physical access to portable computers in their docking station could remove them and possibly tamper with them. For computers that do not have docking stations, this policy setting will have no impact.

Countermeasure

Disable the Devices: Allow undock without having to log on setting.

Potential Impact

Users who have docked their computers will have to log on to the local console before they can undock their computers.

Devices: Allowed to format and eject removable media

This policy setting determines who is allowed to format and eject removable media.

The possible values for the Devices: Allowed to format and eject removable media setting are:

Vulnerability

Users may be able to move data on removable disks to a different computer where they have administrative privileges. The user could then take ownership of any file, grant themselves full control, and view or modify any file. The fact that most removable storage devices will eject media by pressing a mechanical button diminishes the advantage of this policy setting.

Countermeasure

Configure the Allowed to format and eject removable media setting to Administrators.

Potential Impact

Only Administrators will be able to eject NTFS-formatted removable media.

Devices: Prevent users from installing printer drivers

For a computer to print to a network printer, that network printer driver must be installed on the local computer. The Devices: Prevent users from installing printer drivers setting determines who can install a printer driver as part of adding a network printer. If you enable this policy setting, only members of the Administrators and Power Users groups are allowed to install a printer driver when they add a network printer. If you disable this policy setting, any user can install printer drivers when they add a network printer. This policy setting prevents typical users from downloading and installing untrusted printer drivers.

Note: This policy setting has no impact if an administrator has configured a trusted path to download drivers. If you use trusted paths, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver is not installed and the network printer is not added.

The possible values for the Devices: Prevent users from installing printer drivers setting are:

Vulnerability

It may be appropriate in some organizations to allow users to install printer drivers on their own workstations. However, you should not allow users to do so on servers. Printer driver installation on a server may unintentionally cause the computer to become less stable. Only Administrators should have this privilege on servers. A malicious user could install inappropriate printer drivers in a deliberate attempt to damage the computer, or a user might accidentally install malicious code that masquerades as a printer driver.

Countermeasure

Configure the Devices: Prevent users from installing printer drivers setting to Enabled.

Potential Impact

Only users with Administrative, Power User, or Server Operator privileges will be able to install printers on the servers. If this policy setting is enabled but the driver for a network printer already exists on the local computer, users can still add the network printer.

Devices: Restrict CD-ROM access to locally logged-on user only

This policy setting determines whether a CD-ROM is accessible to both local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable CD-ROM media. If this policy setting is enabled and no one is logged on interactively, the CD-ROM can be accessed over the network.

The possible values for the Devices: Restrict CD-ROM access to locally logged-on user only setting are:

Vulnerability

A remote user could potentially access a mounted CD-ROM that contain sensitive information. This risk is small, because CD-ROM drives are not automatically made available as network shares; administrators must deliberately choose to share the drive. However, administrators may wish to deny network users the ability to view data or run applications from removable media on the server.

Countermeasure

Enable the Restrict CD-ROM drive access to locally logged-on user only setting.

Potential Impact

Users who connect to the server over the network will not be able to use any CD-ROM drives that are installed on the server whenever anyone is logged on to the local console of the server. System tools that require access to the CD-ROM drive will fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy drives that are present on the computer when it initializes, and if the service cannot access one of these drives it will fail. This condition will cause the Windows Backup utility to fail if volume shadow copies were specified for the backup job. Any third-party backup products that use volume shadow copies will also fail. This policy setting would not be suitable for a computer that serves as a CD jukebox for network users.

Devices: Restrict floppy access to locally logged-on user only

This policy setting determines whether removable floppy media are accessible to both local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable floppy media. If this policy setting is enabled and no one is logged on interactively, the floppy can be accessed over the network.

The possible values for the Devices: Restrict floppy access to locally logged-on user only setting are:

Vulnerability

A remote user could potentially access a mounted floppy that contains sensitive information. This risk is small because floppy drives are not automatically made available as network shares; administrators must deliberately choose to share the drive. However, administrators may wish to deny network users the ability to view data or run applications from removable media on the server.

Countermeasure

Enable the Restrict floppy access to locally logged-on user only setting.

Potential Impact

Users who connect to the server over the network will not be able to use any floppy disk drives that are installed on the server whenever anyone is logged on to the local console of the server. System tools that require access to floppy drives will fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy drives present on the computer when it initializes, and if the service cannot access one of these drives it will fail. This condition will cause the Windows Backup utility to fail if volume shadow copies were specified for the backup job. Any third-party backup products that use volume shadow copies will also fail.

Devices: Unsigned driver installation behavior

This policy setting determines what happens when an attempt is made to install a device driver that has not been certified and signed by the Windows Hardware Quality Lab (WHQL) by means of the Setup application programming interface (API).

The possible values for the Devices: Unsigned driver installation behavior setting are:

Vulnerability

This policy setting prevents the installation of unsigned drivers, or warns the administrator that unsigned driver software is about to be installed. This capability can prevent use of the Setup API to install drivers that have not been certified to run on Windows XP or Windows Server 2003. This policy setting will not prevent a method that is used by some attack tools in which malicious .sys files are copied and registered to start as system services.

Countermeasure

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

Potential Impact

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

Domain controller: Allow server operators to schedule tasks

This policy setting determines whether server operators are allowed to submit jobs by means of the AT schedule facility.

Note: This security option setting only affects the AT schedule facility. It does not affect the Task Scheduler facility.

The possible values for the Domain controller: Allow server operators to schedule tasks setting are:

Vulnerability

If you enable this policy setting, jobs that are created by server operators by means of the AT service will execute in the context of the account that runs that service. By default, that is the local SYSTEM account. If you enable this policy setting, server operators could perform tasks that SYSTEM is able to do but that they would typically not be able to do, such as add their account to the local Administrators group.

Countermeasure

Disable the Domain controller: Allow server operators to schedule tasks setting.

Potential Impact

The impact should be small for most organizations. Users (including those in the Server Operators group) will still be able to create jobs by means of the Task Scheduler Wizard. However, those jobs will run in the context of the account that the user authenticates with when they set up the job.

Domain controller: LDAP server signing requirements

This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.

The possible values for the Domain controller: LDAP server signing requirements setting are:

Vulnerability

Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client, modifies them, and then forwards them to the client. Where LDAP servers are concerned, an attacker could cause a client to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization’s network, you can implement strong physical security measures to protect the network infrastructure. Also, you could implement Internet Protocol security (IPsec) authentication header mode (AH), which performs mutual authentication and packet integrity for IP traffic to make all types of man-in-the-middle attacks extremely difficult.

Countermeasure

Configure the Domain controller: LDAP server signing requirements setting to Require signature.

Potential Impact

Clients that do not support LDAP signing will be unable to execute LDAP queries against the domain controllers. All Windows 2000–based computers in your organization that are managed from Windows Server 2003 or Windows XP–based computers and that use Windows NT® Challenge/Response (NTLM) authentication must have Windows 2000 Service Pack 3 (SP3) installed. Alternatively, these clients must have the registry change that is described in the Microsoft Knowledge Base article Q325465 “Windows 2000 domain controllers require SP3 or later when using Windows Server 2003 administration tools,” which is available at http://support.microsoft.com/default.aspx?scid=325465. Also, some third-party operating systems do not support LDAP signing. If you enable this policy setting, client computers that use those operating systems may be unable to access domain resources.

Domain controller: Refuse machine account password changes

This policy setting determines whether or not a domain controller will accept password change requests for computer accounts.

The possible values for the Domain controller: Refuse machine account password changes setting are:

Vulnerability

If you enable this policy setting on all domain controllers in a domain, domain members will not be able to change their computer account passwords, and those passwords will be more susceptible to attack.

Countermeasure

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

Potential Impact

None. This is the default configuration.

Domain member: Digitally encrypt or sign secure channel data (multiple related settings)

The following policy settings determine whether a secure channel can be established with a domain controller that cannot sign or encrypt secure channel traffic:

If you enable the Domain member: Digitally encrypt or sign secure channel data (always) setting, a secure channel cannot be established with any domain controller that cannot sign or encrypt all secure channel data.

To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows–based computers create a communication channel through NetLogon called Secure Channels. These channels authenticate computer accounts, and they also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called pass-through authentication, and it allows a computer that has joined a domain to have access to the user account database in its domain and in any trusted domains.

Note: To enable the Domain member: Digitally encrypt or sign secure channel data (always) setting on a member workstation or server, all domain controllers in the domain that the member belongs to must be able to sign or encrypt all secure channel data. This requirement means that all such domain controllers must run Windows NT 4.0 with Service Pack 6a or a later version of the Windows operating system.

If you enable the Domain member: Digitally encrypt or sign secure channel data (always) setting, the Domain member: Digitally sign secure channel data (when possible) setting is automatically enabled.

The possible values for this policy setting are:

Vulnerability

When a Windows Server 2003, Windows XP, Windows 2000, or Windows NT computer joins a domain, a computer account is created. After it joins the domain, the computer uses the password for that account to create a secure channel with the domain controller for its domain every time that it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel is not integrity-checked, and not all information is encrypted. If a computer is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.

Countermeasure

Potential Impact

Digital encryption and signing of the “secure channel” is a good idea where it is supported. The secure channel protects domain credentials as they are sent to the domain controller. However, only Windows NT 4.0 Service Pack 6a (SP6a) and subsequent versions of the Windows operating system support digital encryption and signing of the secure channel. Windows 98 Second Edition clients do not support it unless they have the Dsclient installed. Therefore, you cannot enable the Domain member: Digitally encrypt or sign secure channel data (always) setting on domain controllers that support Windows 98 clients as members of the domain. Potential impacts can include the following:

You can enable this policy setting after you eliminate all Windows 9x clients from the domain and upgrade all Windows NT 4.0 servers and domain controllers from trusted/trusting domains to Windows NT 4.0 with SP6a. You can enable the other two policy settings, Domain member: Digitally encrypt secure channel data (when possible) and Domain member: Digitally encrypt sign channel data (when possible), on all computers in the domain that support them and down-level clients and applications will not be affected.

Domain member: Disable machine account password changes

This policy setting determines whether a domain member periodically changes its computer account password. If you enable this policy setting, the domain member cannot change its computer account password. If you disable this policy setting, the domain member is allowed to change its computer account password as specified by the Domain Member: Maximum age for computer account password setting, which is every 30 days by default.

Caution: Do not enable this policy setting. Computer account passwords are used to establish secure channel communications between members and domain controllers and, within the domain, between the domain controllers themselves. After such communications are established, the secure channel transmits sensitive information that is needed to make authentication and authorization decisions.

Do not use this policy setting in an attempt to support dual-boot scenarios that use the same computer account. If you want to support such a scenario for two installations that are joined to the same domain, use different computer names for the two installations. This policy setting was added to Windows to make it easier for organizations that stockpile pre-built computers that are put into production months later. It eliminates the need for those computers to rejoin the domain. This policy setting is also sometimes used with imaged computers or those with hardware or software level change prevention. Correct imaging procedures make use of this policy unnecessary for imaged computers.

The possible values for the Domain member: Disable machine account password changes setting are:

Vulnerability

The default configuration for Windows Server 2003–based computers that belong to a domain is that they are automatically required to change the passwords for their accounts every 30 days. If you disable this policy setting, computers that run Windows Server 2003 will retain the same passwords as their computer accounts. Computers that are no longer able to automatically change their account password are at risk from an attacker who could determine the password for the computer’s domain account.

Countermeasure

Verify that the Domain member: Disable machine account password changes setting is configured to Disabled.

Potential Impact

None. This is the default configuration.

Domain member: Maximum machine account password age

This policy setting determines the maximum allowable age for a computer account password. This setting also applies to Windows 2000 computers, but it is not available through the Security Configuration Manager tools on these computers.

The possible values for the Domain member: Maximum machine account password age setting are:

Vulnerability

In Active Directory–based domains, each computer has an account and password just like every user. By default, the domain members automatically change their domain password every 30 days. If you increase this interval significantly, or set it to 0 so that the computers no longer change their passwords, an attacker will have more time to undertake a brute force attack to guess the password of one or more computer accounts.

Countermeasure

Configure the Domain member: Maximum machine account password age setting to 30 days.

Potential Impact

None. This is the default configuration.

Domain member: Require strong (Windows 2000 or later) session key

This policy setting determines whether a secure channel can be established with a domain controller that cannot encrypt secure channel traffic with a strong, 128-bit, session key. If you enable this policy setting, a secure channel cannot be established with any domain controller that cannot encrypt secure channel data with a strong key. If you disable this policy setting, 64-bit session keys are allowed.

Note: To enable this policy setting on a member workstation or server, all domain controllers in the domain to which the member belongs must be able to encrypt secure channel data with a strong, 128-bit, key. In other words, all such domain controllers must run Windows 2000 or a later version of the Windows operating system.

The possible values for the Domain member: Require strong (Windows 2000 or later) session key setting are:

Vulnerability

Session keys that are used to establish secure channel communications between domain controllers and member computers are much stronger in Windows 2000 than they were in previous Microsoft operating systems.

Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from attacks that attempt to hijack network sessions and eavesdropping. (Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the sender, or be redirected.)

Countermeasure

Configure the Domain member: Require strong (Windows 2000 or later) session key setting to Enabled.

If you enable this policy setting, all outgoing secure channel traffic will require a strong, Windows 2000 or later encryption key. If you disable this policy setting, the key strength is negotiated. You should only enable this policy setting if the domain controllers in all trusted domains support strong keys. By default, this policy setting is disabled.

Potential Impact

Computers that have this policy setting enabled will not be able to join Windows NT 4.0 domains, and trusts between Active Directory domains and Windows NT-style domains may not work properly. Also, computers that do not support this policy setting will not be able to join domains in which the domain controllers have this policy setting enabled.

Interactive logon: Do not display last user name

This policy setting determines whether the Log on to Windows dialog box displays the name of the last user to log on to the computer. If you enable this policy setting, the name of the last user to successfully log on does not display. If you disable this policy setting, the name of the last user to log on will display.

The possible values for the Interactive logon: Do not display last user name setting are:

Vulnerability

An attacker with access to the console (for example, someone with physical access or someone who is able to connect to the server through Terminal Services) could view the name of the last user who logged on to the server. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try and log on.

Countermeasure

Configure the Do not display last user name in logon screen setting to Enabled.

Potential Impact

Users will always have to type their user names when they log on to the servers.

Interactive logon: Do not require CTRL+ALT+DEL

This policy setting determines whether users must press CTRL+ALT+DEL before they log on. If you enable this policy setting, users can log on without this key combination. If you disable this policy setting, users must press CTRL+ALT+DEL before they log on to Windows unless they use a smart card for Windows logon. A smart card is a tamper-proof device that stores security information.

The possible values for the Interactive logon: Do not require CTRL+ALT+DEL setting are:

Vulnerability

Microsoft developed this feature to make it easier for users with certain types of physical impairments to log on to computers that run Windows. If users are not required to press CTRL+ALT+DEL, they are susceptible to attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is required before logon, user passwords are communicated by means of a trusted path.

An attacker could install a Trojan horse program that looks like the standard Windows logon dialog box and capture the user’s password. The attacker would then be able to log on to the compromised account with whatever level of privilege that user has.

Countermeasure

Configure the Disable CTRL+ALT+DEL requirement for logon setting to Disabled.

Potential Impact

Unless they use a smart card to log on, users will have to simultaneously press three keys before the logon dialog box will display.

Interactive logon: Message text for users attempting to log on

The Interactive logon: Message text for users attempting to log on and the Interactive logon: Message title for users attempting to log on settings are closely related. The first policy setting specifies a text message that displays to users when they log on, and the second policy setting specifies a title that displays in the title bar of the window that contains the text message. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.

Caution: Windows XP Professional adds support for logon banners that can exceed 512 characters in length and that can also contain carriage-return line-feed sequences. However, Windows 2000 clients cannot interpret and display these messages. You must use a Windows 2000 computer to create a logon message policy that applies to Windows 2000 computers. If you inadvertently create a logon message policy on a Windows XP Professional computer and you discover that it does not display properly on Windows 2000 computers, do the following:

You cannot simply change a Windows XP Professional-defined logon message setting on a Windows 2000 computer. You must first reconfigure the setting to Not Defined.

The possible values for these policy settings are:

Vulnerability

Displaying a warning message before logon may help prevent an attack by warning the attacker of their misconduct before it happens. It may also help to reinforce corporate policy by notifying employees of the appropriate policy during the logon process.

Countermeasure

Configure the Message text for users attempting to log on and Message title for users attempting to log on settings to an appropriate value for your organization.

Note: Any warning message that displays should be approved by your organization’s legal and human resources representatives.

Potential Impact

Users will see a message in a dialog box before they can log on to the server console.

Interactive logon: Number of previous logons to cache (in case domain controller is not available)

This policy setting determines the number of different unique users who can log on to a Windows domain by using cached account information. Logon information for domain accounts can be cached locally so that if a domain controller cannot be contacted on subsequent logons, a user can still log on. This policy setting determines the number of unique users whose logon information is cached locally.

If a domain controller is unavailable and a user’s logon information is cached, the user is prompted with the following message:

A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on may not be available.

If a domain controller is unavailable and a user’s logon information is not cached, the user is prompted with this message:

The system cannot log you on now because the domain <DOMAIN_NAME> is not available.

The possible values for the Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting are:

Vulnerability

The number that is assigned to this policy setting indicates the number of users whose logon information the servers will cache locally. If the number is set to 10, then the server caches logon information for 10 users. When an eleventh user logs on to the computer, the server overwrites the oldest cached logon session.

Users who access the server console will have their logon credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords.

To mitigate this type of attack, Windows encrypts the information and obscures its physical location.

Countermeasure

Configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting to 0, which disables the local caching of logon information. Additional countermeasures include enforcement of strong password policies and physically secure locations for the computers.

Potential Impact

Users will be unable to log on to any computers if there is no domain controller available to authenticate them. Organizations may want to configure this value to 2 for end-user computers, especially for mobile users. A configuration value of 2 means that the user’s logon information will still be in the cache, even if a member of the IT department has recently logged on to their computer to perform system maintenance. This method allows users to log on to their computers when they are not connected to the organization’s network.

Interactive logon: Prompt user to change password before expiration

This policy setting determines how many days in advance users are warned that their password is about to expire. With this advance warning, the user has time to construct a password that is sufficiently strong.

The possible values for the Interactive logon: Prompt user to change password before expiration setting are:

Vulnerability

Microsoft recommends that user passwords be configured to expire periodically. Users will need to be warned that their passwords are going to expire, or they may inadvertently be locked out of the computer when their passwords expire. This condition could lead to confusion for users who access the network locally, or make it impossible for users to access your organization’s network through dial-up or virtual private network (VPN) connections.

Countermeasure

Configure the Interactive logon: Prompt user to change password before expiration setting to 14 days.

Potential Impact

Users will see a dialog box prompt to change their password each time that they log on to the domain when their password is configured to expire in 14 or fewer days.

Interactive logon: Require Domain Controller authentication to unlock workstation

Logon information is required to unlock a locked computer. For domain accounts, the Interactive logon: Require Domain Controller authentication to unlock workstation setting determines whether it is necessary to contact a domain controller to unlock a computer. If you enable this setting, a domain controller must authenticate the domain account that is being used to unlock the computer. If you disable this setting, logon information confirmation with a domain controller is not required for a user to unlock the computer. However, if you configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting to a value that is greater than zero, then the user's cached credentials will be used to unlock the computer.

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

The possible values for the Interactive logon: Require Domain Controller authentication to unlock workstation setting are:

Vulnerability

By default, the computer caches in memory the credentials of any users who are authenticated locally. The computer uses these cached credentials to authenticate anyone who attempts to unlock the console. When cached credentials are used, any changes that have recently been made to the account—such as user rights assignments, account lockout, or the account being disabled—are not considered or applied after the account is authenticated. User privileges are not updated, and (more importantly) disabled accounts are still able to unlock the console of the computer.

Countermeasure

Configure the Interactive logon: Require Domain Controller authentication to unlock workstation setting to Enabled and configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting to 0.

Potential Impact

When the console on a computer is locked, either by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to re-authenticate to the domain controller. If no domain controller is available, then users cannot unlock their workstations. If you configure the Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting to 0, users whose domain controllers are unavailable (such as mobile or remote users) will not be able to log on.

Interactive logon: Require smart card

This policy setting requires users to log on to a computer with a smart card.

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

The possible values for the Interactive logon: Require smart card setting are:

Vulnerability

Requirements to use long, complex passwords for authentication enhance network security, especially if the users must 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 vulnerable to brute-force attacks if an attacker has sufficient time and computing resources.  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. In other words, the user must both 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 and, even if they do, the next time the user logs onto the network a new session key will be generated to encrypt traffic between the user and the domain controller.

Countermeasure

For sensitive accounts, issue smart cards to users and configure the Interactive logon: Require smart card setting to Enabled.

Potential Impact

All users will have to use smart cards to log onto the network, which means that the organization will need a reliable public key infrastructure (PKI) as well as smart cards and smart card readers for all users. These requirements are significant challenges, because expertise and resources are required to plan for and deploy these technologies. However, Windows Server 2003 includes Certificate Services, a highly advanced service for implementing and managing certificates. When Certificate Services is combined with Windows XP, features such as automatic user and computer enrollment and renewal become available.

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.

The possible values for the Interactive logon: Smart card removal behavior setting are:

Vulnerability

If smart cards are used for authentication, then the computer should automatically lock itself when the card is removed. This approach will prevent malicious users from accessing the computers of users who forget to manually lock their workstations when they are away from them.

Countermeasure

Configure the Smart card removal behavior setting to Lock Workstation.

If you select Lock Workstation in the Properties dialog box for this policy setting, the workstation locks when the smart card is removed. Users can leave the area, take their smart card with them, and still maintain a protected session.

If you select Force Logoff in the Properties dialog box for this policy setting, the user is automatically logged off when the smart card is removed.

Potential Impact

Users will have to re-insert their smart cards and re-enter their PINs when they return to their workstations.

Microsoft network client and server: Digitally sign communications (four related settings)

There are four separate settings that relate to digital signatures for Server Message Block (SMB) communications:

The possible values for each of these policy settings are:

Vulnerability

Implementation of digital signatures in high security networks helps to prevent the impersonation of clients and servers. This type of impersonation is known as session hijacking, and uses tools that allow attackers who have access to the same network as the client or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets and then modify the traffic and forward it so that the server might perform undesirable actions. Alternatively, the attacker could pose as the server or client after legitimate authentication and gain unauthorized access to data.

SMB is the resource sharing protocol that is supported by many Microsoft operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate both users and the servers that host the data. If either side fails the authentication process, data transmission will not take place.

Note: An alternative countermeasure that could protect all network traffic would be to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers’ CPUs. No such accelerators are available for SMB signing.

Countermeasure

Configure the settings as follows:

Some resources recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client computers and prevent communications with legacy SMB applications and operating systems.

Potential Impact

The Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, and Windows XP Professional implementations of the SMB file and print sharing protocol support mutual authentication, which prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by both the client and the server. Implementation of SMB signing may negatively affect performance, because each packet needs to be signed and verified. If you configure computers to ignore all unsigned SMB communications, older applications and operating systems will not be able to connect. If you completely disable all SMB signing, computers will be vulnerable to session hijacking attacks.

Microsoft network client: Send unencrypted password to third-party SMB servers

This policy setting allows the SMB redirector to send plaintext passwords to non-Microsoft SMB servers that do not support password encryption during authentication.

The possible values for the Microsoft network client: Send unencrypted password to third-party SMB servers setting are:

Vulnerability

If you enable this policy setting, the server can transmit passwords in plaintext across the network to other computers that offer SMB services. These other computers may not use any of the SMB security mechanisms that are included with Windows Server 2003.

Countermeasure

Configure the Microsoft network client: Send unencrypted password to connect to third-party SMB servers setting to Disabled.

Potential Impact

Some very old applications and operating systems such as MS-DOS, Windows for Workgroups 3.11, and Windows 95a may not be able to communicate with the servers in your organization by means of the SMB protocol.

Microsoft network server: Amount of idle time required before suspending session

This policy setting determines the amount of continuous idle time that must pass in a SMB session before the session is suspended because of inactivity. Administrators can use this policy setting to control when a computer suspends an inactive SMB session. The session automatically re-establishes when client activity resumes. A value of 0 will disconnect an idle session as quickly as possible. The maximum value is 99999, which is 208 days; in effect, this value disables the setting.

The possible values for the Microsoft network server: Amount of idle time required before suspending session setting are:

Vulnerability

Each SMB session consumes server resources, and numerous null sessions will slow the server or possibly cause it to fail. An attacker could repeatedly establish SMB sessions until the server's SMB services become slow or unresponsive.

Countermeasure

Configure the Microsoft network server: Amount of idle time required before disconnecting session setting to 15 minutes.

Potential Impact

There will be little impact because SMB sessions will be re-established automatically if the client resumes activity.

Microsoft network server: Disconnect clients when logon hours expire

This policy setting 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, client sessions with the SMB service will be forcibly disconnected when the client’s logon hours expire. If you disable this policy setting, established client sessions will be maintained after the client’s logon hours expire. If you enable this policy setting you should also enable Network security: Force logoff when logon hours expire.

The possible values for the Microsoft network server: Disconnect clients when logon hours expire setting are:

Vulnerability

If your organization configures logon hours for users, then it makes sense to enable this policy setting. Otherwise, users who should not have access to network resources outside of their logon hours may actually be able to continue to use those resources with sessions that were established during allowed hours.

Countermeasure

Enable the Microsoft network server: Disconnect clients when logon hours expire setting.

Potential Impact

If logon hours are not used in your organization, this policy setting will have no impact. If logon hours are used, existing user sessions will be forcibly terminated when their logon hours expire.

Network access: Allow anonymous SID/Name translation

This policy setting determines whether an anonymous user can request SID attributes for another user.

The possible values for the Network access: Allow anonymous SID/Name translation setting are:

Vulnerability

If this policy setting is enabled, a user with local access could use the well-known Administrator's SID to learn the real name of the built-in Administrator account, even if it has been renamed. That person could then use the account name to initiate a password guessing attack.

Countermeasure

Configure the Network access: Allow anonymous SID/Name translation setting to Disabled.

Potential Impact

Disabled is the default configuration for this policy setting on member computers; therefore it will have no impact on them. The default configuration for domain controllers is Enabled. If you disable this policy setting on domain controllers, legacy computers may be unable to communicate with Windows Server 2003–based domains. For example, the following computers may not work:

Network access: Do not allow anonymous enumeration of SAM accounts

This policy setting determines what additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerate the names of domain accounts and network shares. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. However, even if this setting enabled, anonymous users will still have access to any resources that have permissions that explicitly include the special built-in group ANONYMOUS LOGON.

In Windows 2000, a similar policy setting called Additional Restrictions for Anonymous Connections managed a registry value called RestrictAnonymous, which was located in the HKLM\SYSTEM\CurrentControlSet\Control\LSA registry key. In Windows Server 2003, the policy settings Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares replace the Windows 2000 policy setting. They manage the registry values RestrictAnonymousSAM and RestrictAnonymous, respectively, which are both located in the HKLM\System\CurrentControlSet\Control\Lsa\ registry key.

The possible values for the Network access: Do not allow anonymous enumeration of SAM accounts setting are:

Vulnerability

An unauthorized user could anonymously list account names and use the information to perform social engineering attacks or attempt to guess passwords. (Social engineering attacks try to deceive users in some way to obtain passwords or some form of security information.)

Countermeasure

Configure the Network access: Do not allow anonymous enumeration of SAM accounts setting to Enabled.

Potential Impact

It will be impossible to establish trusts with Windows NT 4.0–based domains. Also, client computers that run older versions of the Windows operating system such as Windows NT 3.51 and Windows 95 will experience problems when they try to use resources on the server.

Network access: Do not allow anonymous enumeration of SAM accounts and shares

This policy setting determines whether anonymous enumeration of Security Accounts Manager (SAM) accounts and shares is allowed. As stated in the previous section, Windows allows anonymous users to perform certain activities, such as enumerate the names of domain accounts and network shares. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. You can enable this policy setting if you do not want to allow anonymous enumeration of SAM accounts and shares. However, even if it is enabled, anonymous users will still have access to any resources that have permissions that explicitly include the special built-in group ANONYMOUS LOGON.

In Windows 2000, a similar policy setting called Additional Restrictions for Anonymous Connections managed a registry value called RestrictAnonymous, which was located in the HKLM\SYSTEM\CurrentControlSet\Control\LSA registry key. In Windows Server 2003, the policy settings Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares replace the Windows 2000 policy setting. They manage registry values RestrictAnonymousSAM and RestrictAnonymous, respectively, which are both located in the HKLM\System\CurrentControlSet\Control\Lsa\ registry key.

The possible values for the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting are:

Vulnerability

An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords or perform social engineering attacks.

Countermeasure

Configure the Network access: Do not allow anonymous enumeration of SAM accounts and shares setting to Enabled.

Potential Impact

It will be impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain will be unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously will be unable to list the shared network resources on those servers; the users will have to authenticate before they can view the lists of shared folders and printers.

Network access: Do not allow storage of credentials or .NET Passports for network authentication

This policy setting determines whether the Stored User Names and Passwords feature may save passwords or credentials for later use when it gains domain authentication. If you enable this policy setting, the Stored User Names and Passwords feature of Windows does not store passwords and credentials.

The possible values for the Network access: Do not allow storage of credentials or.NET Passports for network authentication setting are:

Vulnerability

Passwords that are cached can be accessed by the user when logged on to the computer. Although this information may sound obvious, a problem can arise if the user unknowingly executes hostile code that reads the passwords and forwards them to another, unauthorized user.

Note: The chances of success for this exploit and others that involve hostile code will be reduced significantly for organizations that effectively implement and manage an enterprise antivirus solution combined with sensible software restriction policies. For more information about software restriction policies, see Chapter 8, “Software Restriction Policies.”

Countermeasure

Configure the Network access: Do not allow storage of credentials or.NET Passports for network authentication setting to Enabled.

Potential Impact

Users will be forced to enter passwords whenever they log on to their Passport account or other network resources that aren’t accessible to their domain account. This policy setting should have no impact on users who access network resources that are configured to allow access with their Active Directory–based domain account.

Network access: Let Everyone permissions apply to anonymous users

This policy setting determines what additional permissions are granted for anonymous connections to the computer. If you enable this policy setting, anonymous users can enumerate the names of domain accounts and network shares and perform certain other activities. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust.

By default, the token that is created for anonymous connections does not include the Everyone SID. Therefore, permissions that are assigned to the Everyone group do not apply to anonymous users. If you enable this policy setting, the Everyone SID is added to the token that is created for anonymous connections, and anonymous users will be able to access any resource for which the Everyone group has been assigned permissions.

The possible values for the Network access: Let Everyone permissions apply to anonymous users setting are:

Vulnerability

An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords, perform social engineering attacks, or launch DoS attacks.

Countermeasure

Configure the Network access: Let Everyone permissions apply to anonymous users setting to Disabled.

Potential Impact

None. This is the default configuration.

Network access: Named Pipes that can be accessed anonymously

This policy setting determines which communication sessions, or pipes, will have attributes and permissions that allow anonymous access.

The possible values for the Network access: Named Pipes that can be accessed anonymously setting are:

For this policy setting to take effect, you must also enable the Network access: Restrict anonymous access to named pipes and shares setting.

Vulnerability

You can restrict access over named pipes such as COMNAP and LOCATOR to help prevent unauthorized access to the network. The default list of named pipes and their purpose is provided in the following table.

Table 5.1: Default Named Pipes That Are Accessible Anonymously

Countermeasure

Configure the Network access: Named Pipes that can be accessed anonymously setting to a null value (enable the setting but do not enter named pipes in the text box).

Potential Impact

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

To avoid this problem, refer to the Microsoft Knowledge Base article “How to access network files from IIS applications,” which is located at http://support.microsoft.com/default.aspx?scid=207671.

Network access: Remotely accessible registry paths

This policy setting determines which registry paths will be accessible when an application or process references the WinReg key to determine access permissions.

The possible values for the Network access: Remotely accessible registry paths setting are:

Vulnerability

The registry is a database that contains computer configuration information, and much of the information is sensitive. An attacker could use this information to facilitate unauthorized activities. To reduce the risk of such an attack, suitable ACLs are assigned throughout the registry to help protect it from access by unauthorized users.

Countermeasure

Configure the Network access: Remotely accessible registry paths setting to a null value (enable the setting but do not enter any paths in the text box).

Potential Impact

Remote management tools such as the Microsoft Baseline Security Analyzer and Microsoft Systems Management Server require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail.

Note: If you want to allow remote access, you must also enable the Remote Registry service.

Network access: Remotely accessible registry paths and sub-paths

This policy setting determines which registry paths and sub-paths will be accessible when an application or process references the WinReg key to determine access permissions.

The possible values for the Network access: Remotely accessible registry paths and sub-paths setting are:

Vulnerability

As stated earlier, the registry contains sensitive computer configuration information that could be used by an attacker to facilitate unauthorized activities. The fact that the default ACLs assigned throughout the registry are fairly restrictive and help to protect the registry from access by unauthorized users reduces the risk of such an attack.

Countermeasure

Configure the Network access: Remotely accessible registry paths and sub-paths setting to a null value (enable the setting but do not enter any paths in the text box).

Potential Impact

Remote management tools such as the Microsoft Baseline Security Analyzer and Microsoft Systems Management Server require remote access to the registry to properly monitor and manage those computers. If you remove the default registry paths from the list of accessible ones, such remote management tools could fail.

Note: If you want to allow remote access, you must also enable the Remote Registry service.

Network access: 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 in the Network access: Named pipes that can be accessed anonymously and Network access: Shares that can be accessed anonymously settings. This policy setting controls null session access to shares on your computers by adding RestrictNullSessAccess with the value 1 in the registry key HKLM\System\CurrentControlSet\Services\LanManServer\Parameters. This registry value toggles null session shares on or off to control whether the server service restricts unauthenticated clients' access to named resources.

The possible values for the Network access: Restrict anonymous access to Named Pipes and Shares setting are:

Vulnerability

Null sessions are a weakness that can be exploited through shares (including the default shares) on computers in your environment.

Countermeasure

Configure the Network access: Restrict anonymous access to Named Pipes and Shares setting to Enabled.

Potential Impact

You can enable this policy setting to restrict null session access for unauthenticated users to all server pipes and shares except those that are listed in the NullSessionPipes and NullSessionShares entries.

Network access: Shares that can be accessed anonymously

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

The possible values for the Network access: Shares that can be accessed anonymously setting are:

Vulnerability

It is very dangerous to enable this setting. Any shares that are listed can be accessed by any network user, which could lead to the exposure or corruption of sensitive data.

Countermeasure

Configure the Network access: Shares that can be accessed anonymously setting to a null value.

Potential Impact

There should be little impact because this is the default configuration. Only authenticated users will have access to shared resources on the server.

Network access: Sharing and security model for local accounts

This policy setting determines how network logons that use local accounts are authenticated. If you configure this policy setting to Classic, network logons that use local account credentials authenticate with those credentials. If you configure this policy setting to Guest only, network logons that use local accounts are automatically mapped to the Guest account. The Classic model provides precise control over access to resources, and allows you to grant different types of access to different users for the same resource. Conversely, the Guest only model treats all users equally as the Guest user account, and they all receive the same level of access to a given resource, which can be either Read Only or Modify.

The default configuration in stand-alone Windows XP Professional is Guest only. The default for Windows XP computers that are joined to a domain and Windows Server 2003 computers is Classic.

Note: This policy setting does not affect network logons that use domain accounts. Nor does this policy setting affect interactive logons that are performed remotely through services such as Telnet or Terminal Services.

When the computer is not joined to a domain, this policy setting also tailors the Sharing and Security tabs in Windows Explorer to correspond to the sharing and security model that is being used.

This setting has no effect on Windows 2000 computers.

The possible values for the Network access: Sharing and security model for local accounts setting are:

Vulnerability

With the Guest only model, any user who can authenticate to your computer over the network does so with guest privileges, which probably means that they will not have write access to shared resources on that computer. Although this restriction does increase security, it makes it more difficult for authorized users to access shared resources on those computers because ACLs on those resources must include access control entries (ACEs) for the Guest account. With the Classic model, local accounts should be password protected. Otherwise, if Guest access is enabled, anyone can use those user accounts to access shared system resources.

Countermeasure

For network servers, configure the Network access: Sharing and security model for local accounts setting to Classic – local users authenticate as themselves. On end-user computers, configure this policy setting to Guest only – local users authenticate as guest.

Potential Impact

None. This is the default configuration.

Network security: Do not store LAN Manager hash value on next password change

This policy setting determines whether LAN Manager can store hash values for the new password the next time the password is changed.

The possible values for the Network security: Do not store LAN Manager hash value on next password change setting are:

Vulnerability

The SAM file can be targeted by attackers who seek access to username and password hashes. Such attacks use special tools to crack passwords, which can then be used to impersonate users and gain access to resources on your network. These types of attacks will not be prevented if you enable this policy setting, but it will be much more difficult for these types of attacks to succeed.

Countermeasure

Configure the Network security: Do not store LAN Manager hash value on next password change setting to Enabled. Require all users to set new passwords the next time they log in to the domain so that LAN Manager hashes are removed.

Potential Impact

Earlier operating systems such as Windows 95, Windows 98, and Windows ME as well as some third-party applications will fail.

Network security: Force logoff 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, client sessions with the SMB server will be disconnected when the client’s logon hours expire. If you disable this policy setting, established client sessions will be maintained after the client’s logon hours expire.

The possible values for the Network security: Force logoff when logon hours expire setting are:

Vulnerability

If you disable this policy setting, a user could remain connected to the computer outside of their allotted logon hours.

Countermeasure

Configure the Network security: Force logoff when logon hours expire setting to Enabled. This policy setting does not apply to administrator accounts.

Potential Impact

When a user's logon time expires, SMB sessions will terminate. The user will be unable to log on to the computer until their next scheduled access time commences.

Network security: LAN Manager authentication level

LAN Manager (LM) is a family of early Microsoft client/server software that allows users to link personal computers together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory will use LM, NTLM, or NTLMv2.

LAN Manager authentication includes the LM, NTLM, and NTLM version 2 (NTLMv2) variants, and is the protocol that is used to authenticate all Windows clients when they perform the following operations:

The possible values for the Network security: LAN Manager authentication level setting are:

The Network security: LAN Manager authentication level setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level that clients use, the session security level that the computers negotiate, and the authentication level that servers accept as follows:

These settings correspond to the levels discussed in other Microsoft documents as follows:

Vulnerability

Windows 2000, Windows Server 2003, and Windows XP clients are configured by default to send LM and NTLM authentication responses (Windows 9x clients only send LM). The default setting on servers allows all clients to authenticate with servers and use their resources. However, this means that LM responses—the weakest form of authentication response—are sent over the network, and it is potentially possible for attackers to sniff that traffic to more easily reproduce the user’s password.

The Windows 9x and Windows NT operating systems cannot use the Kerberos version 5 protocol for authentication. For this reason, in a Windows Server 2003 domain, these computers authenticate by default with both the LM and NTLM protocols for network authentication. You can enforce a more secure authentication protocol for Windows 9x and Windows NT by using NTLMv2. For the logon process, NTLMv2 uses a secure channel to protect the authentication process. Even if you use NTLMv2 for legacy clients and servers, Windows-based clients and servers that are members of the domain will use the Kerberos authentication protocol to authenticate with Windows Server 2003 domain controllers.

For more information about how to enable NTLMv2, see the Microsoft Knowledge Base article “How to enable NTLM 2 authentication,” which is located at http://support.microsoft.com/default.aspx?scid=239869. Microsoft Windows NT 4.0 requires Service Pack 4 (SP4) to support NTLMv2, and Windows 9x platforms need the Directory Service client installed to support NTLMv2.

Countermeasure

Configure the Network security: LAN Manager Authentication Level setting to Send NTLMv2 responses only. This level of authentication is strongly recommended by Microsoft and a number of independent organizations when all clients support NTLMv2.

Potential Impact

Clients that do not support NTLMv2 authentication will not be able to authenticate in the domain and access domain resources by using LM and NTLM.

Note: For information about a hotfix to ensure that this setting works in networks that include Windows NT 4.0 computers along with Windows 2000, Windows XP, and Windows Server 2003 computers, refer to the Microsoft Knowledge Base article “Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain” at http://support.microsoft.com/default.aspx?scid=305379.

Network security: LDAP client signing requirements

This policy setting determines the level of data signing that is requested on behalf of clients that issue LDAP BIND requests, as follows:

Note: This policy setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No Microsoft LDAP clients that are included with Windows XP Professio