On This PageAccount PoliciesAccount policies are the rules that control three major account authentication features: password policy, account lockout, and Kerberos authentication. | • | Password policy - determines settings for passwords such as enforcement, and lifetimes. | | • | Account lockout policy - determines when and for how long an account will be locked out of the system. | | • | Kerberos policy - Kerberos authentication is the authentication mechanism used by Windows 2000 and higher computers when they are members of an Active Directory domain. This policy allows administrators to configure Kerberos. |
Account policies can be applied to user accounts in domains or OUs. For account policies in one domain in a forest to have any effect on another domain, even a sub-domain, there must be an explicit link to the group policy object. In addition, the following are important points to keep in mind with respect to account policies: | • | Domain account policies applied through a Domain policy take effect only on the accounts defined on the domain controllers in that domain and any sub-domains. This also includes the following three settings: | • | Automatically log off users when logon time expires | | • | Rename administrator account | | • | Rename guest account |
| | • | Account policies defined on an OU take effect on the local accounts defined on the computers that are members of that OU. |
Password PolicyView and edit current password policy settings as follows: 1. | Open the applicable security policy, whether via a GPO, through the SCE, or through Local Security Policies | 2. | Expand Security Settings. | 3. | Within Security Settings, expand Account Policies to reveal the Password, Account Lockout, and Kerberos policies. | 4. | Click on the Password Policy object. The right-hand details pane will reveal the configurable Password Policy settings. | 5. | Set the Password Policy as recommended in Table 4.1. |
Table 4.1 Password Policy Settings Set the Password History Requirements Security Objective: Set limit on how often passwords may be reused. Setting this to any value checks new passwords against that many prior passwords and rejects a password change if the new password matches any existing passwords. (Note, this is done without storing clear-text passwords). Procedure: 1. | Double click on the Enforce password history policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. | 2. | For Domain-level policies, check the Define this policy setting box. | 3. | Change the number in the passwords remembered field (maximum is 24) to reflect the number of passwords the system will remember. |
Recommendation: Set this to 24. Rationale: This setting enhances password security by ensuring that users cannot reuse passwords, whether accidentally or on purpose. This increases the chance that passwords stolen by an attacker will not be valid by the time they are cracked. |  | | | | | | Set the Maximum Password Age Security Objective: Set the length of time users can keep their passwords before they have to change it. Procedure: 1. | Double click on the Maximum password age policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. | 2. | For Domain-level policies, check the Define this policy setting box. | 3. | Change the number in the days field to the desired number. |
Recommendation: 70 days. Rationale: this increases password security by ensuring that passwords are cycled periodically. The recommended setting prevents users from having to change their password so often that they cannot remember what it is. | | | | | | | Set the Minimum Password Age Security Objective: Set the length of time users must keep a password before they can change it. Procedure: 1. | Double click on the Minimum password age policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. | 2. | For Domain-level policies, check the Define this policy setting box. | 3. | Change the number in the days field to the desired number. |
Recommendation: 2 days. Rationale: This setting helps users remember new passwords by forcing them to use them for a period of time before they can reset them. It also prevents them from circumventing the password history by rapidly setting 25 new passwords. | | | | | | | Set the Minimum Password Length Security Objective: Set the minimum number characters required for user passwords. Procedure: 1. | Double click on the Minimum password length policy object in the right-hand details pane to open the corresponding Security Policy Setting dialog window. | 2. | For Domain-level policies, check the Define this policy setting box. | 3. | Change the number in the characters field to the desired value. |
Recommendation: 8 characters. Note: Each additional character in a password increases the complexity of the password exponentially. By requiring at least 8 characters even the weaker LMHash is much stronger, requiring crackers to crack both 7-character portions of the LMHash, as opposed to only one half. If a password is 7 characters or less, the second half of the LMHash has a specific value which allows a cracker to tell that the password is shorter than 8 characters. A significant amount of time has been spent arguing that 8 character passwords are less secure than 7 character passwords due to the way the LMHash is stored. In an 8 character password, the cracker would simply test the second half of the password while testing the first half. However, what this argument fails to take into account is that this still increases the number of checks a cracker has to perform by an additional 1/7th, significantly extending the time it takes to crack the password. Longer passwords are always better, and if LMHashes are not stored, 8 character passwords are orders of magnitude more secure than 7 character passwords. Recommending shorter passwords over longer ones is misguided. | | | | | | | Set the Password Complexity Requirements Security Objective: Requires the use of complex (strong) password. This policy will impose a requirement for at least three of the following four character sets: (1) upper case letters, (2) lower case letters, (3) numbers, and (4) non-alpha numeric characters. For more information on requiring and verifying additional complexity in passwords, please see section 0. Recommendation: Enable password complexity. Rationale: Password complexity is paramount to prevent password guessing and password cracking. | | | | | | | Enable Reversible Encryption for Passwords Security Objective: This setting is designed to decrease security for environments needing particular types of backward compatibility. Certain scenarios require knowledge of the user's clear-text password. In those scenarios enabling this setting allows the clear-text password to be obtained. Recommendation: Do not enable this setting. Verify the default setting of "Disabled" is still enforced. | | | | | | |
Account Lockout PolicyAccount lockout is used to prevent password guessing against accounts. Account lockout would lock out the account after a certain number of bad passwords have been entered. The lockout can last for a duration of time or be indefinite, until the administrator unlocks the account. The built-in Administrator account cannot be locked out from local logons, only from network logons. Furthermore, it can only be locked out from network logons by using the passprop.exe tool in the Windows 2000 Server Resource Kit. We recommend not using account lockout policy for several reasons. First, if password policies are configured as per above, account lockouts are superfluous as no attacker will be able to guess the password in a reasonable period of time. Using only upper- and lower-case letters and numbers, and assuming that users do not use dictionary words with only a number appended, it will take 3,461,760 years to guess the password if each guess takes half a second. Since passwords are changed frequently, the likelihood that an attacker can guess the password is very slim. In fact, if passwords are changed every 70 days, the attacker would need the equivalent of 52,000 T3 lines coming in to the victim system in order to guess just one random password prior to its expiration (assuming, of course, that the password does not appear in a dictionary). In other words, if passwords are so weak that an attacker manages to guess the password in a single-digit number of tries, the problem is not the lack of account lockout policies, but rather extremely poor passwords. Further, enabling account lockout policies will greatly increase the helpdesk burden due to users accidentally locking out their account by forgetting to turn off the caps-lock key or similar issues. This is particularly true when users are required to use complicated passwords, which otherwise is a good practice. Even worse than the increased helpdesk call volume directly generated by account lockout would be the effect on the network if an attacker should lock out service accounts. In this case, the services would fail to start. If a service fails to start once because of an account lockout, it will not retry starting the service, and an administrator would have to manually go to the system and start the service; after the account lockout period has expired. We highly recommend using a vulnerability scanner in all environments. However, a vulnerability scanner typically tests a small number of commonly used passwords, and if account lockout policy is used, the scanner will lock out all accounts each time it scans the network. This could have an unintended adverse impact on system availability. In addition, account lockout by default does not operate against the one account that an attacker is most likely to attack; the Administrator account. Although it is possible to obtain a list of the other administrative accounts on a system, most attackers will attempt to guess passwords on the obvious accounts, such as the default Administrator account. In order to enable lockout of the Administrator account you must use the passprop.exe utility in the Resource kit. Lastly, since a firewall should be used to block Windows networking from untrusted networks, password guessing would only be possible from trusted networks. In a trusted network, the culprit of a password guessing attack should be relatively easy to locate and deal with by tracing the logon attempts. This all being said, there is one potential use of account lockout, and it is to alert administrators that a password guessing attack is under way. However, an intrusion detection system should be used to detect this. We do not endorse using account lockout policy as a replacement for a real intrusion detection system. However, in environments where account lockout is desired for its alerting effect, we recommend setting the threshold to 50 and the timers to 30 minutes, respectively. Access the Kerberos Policy SettingsThe default settings for Kerberos Policies are adequate. Do not change these defaults. Local PoliciesLocal Policies govern security settings that apply to individual computers or users. The Local Policies section can be used to configure: | • | Audit policy. Determines which security events are logged into the security event log on the computer (i.e., successful attempts, failed attempts or both). The security log is managed through the Event Viewer MMC snap-in. | | • | User rights assignment. User rights govern the types of actions individual users or groups can perform. These used to be called privileges in prior versions of Windows NT. | | • | Security options. Used to manage various registry based security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD ROM access, driver installation, and logon prompts. Several of the settings discussed in this section are not visible by default in the tools described in this section. In order to view and manage these settings in the user interface, an administrator must first apply a custom template to modify the settings which appear in the interface. Instructions for how to apply the custom templates included with this guide are available in section 0. |
Audit PolicyTo enable auditing of security related events: 1. | Open the applicable Security Policy. | 2. | Expand Security Settings. | 3. | Within Security Settings, expand Local Policies to reveal the Audit, User Rights Assignment, and Security Options policies. | 4. | Click on the Audit Policy object. The right-hand details pane will reveal the configurable Audit Policy settings | 5. | To set auditing of a security event, double click on the desired audit policy in the right-hand details pane. This will open the Security Policy Setting dialog window. |
Table 4.4 Audit Policy Settings Audit Event Categories | Success | Failure | | | | | | | Audit Account Logon Events This audits logon events where this computer is used to authenticate the user. In other words, on a DC, this will audit all domain logon events, whereas on a domain member, it will only audit those events where a local account was used. | | | | | | | | | Audit Account Management This audits any event that involves account management, such as account creation, account lockout, account deletion, etc. | | | | | | | | | Audit Directory Service Access This enables auditing of access to Active Directory objects. By itself, this setting does not actually cause any events to be generated. Only when a SACL is defined on an object are any accesses audited. Therefore, we recommend enabling both success and failure auditing, in order to allow any SACL to be effective. | | | | | | | | | Audit Logon Events This audits logon events occurring on the system this policy is applied to, regardless of where the accounts reside. In other words, on a domain member, enabling success auditing for this would generate an event each time someone logged on to the system. If the account used to logon was local and the Audit Account Logon Events setting was also enabled, the logon would generate two events. | | | | | | | | | Audit Object Access This enables auditing of access to all auditable objects such as file system and registry objects (with the exception of Directory Service objects). This setting, by itself, will not cause any events to be audited. It will only enable auditing so that objects on which a SACL are defined can be audited. Therefore, we recommend enabling both success and failure auditing for this setting. | | | | | | | | | Audit Policy Change This setting defines whether to audit changes to user rights assignment policies, audit policies, or trust policies. We only recommend success auditing for this since failure auditing of this type of access is not really meaningful. | | | | | | | | | Audit Privilege Use This setting determines whether we generate an audit event every time someone uses a privilege. Certain privileges, such as Bypass traverse checking and Debug programs are not audited in spite of this setting (such auditing can be turned on by setting the FullPrivilegeAuditing registry value). In spite of this, enabling privilege auditing generates a very large number of events, and for that reason, we do not recommend turning it on. | | | | | | | | | Audit Process Tracking This setting enables auditing of certain process events, such as program entry and exit, handle duplication, indirect object access, and so on. Enabling this auditing will generate a very large number of events which will fill the event logs in a short period of time. For this reason, we do not recommend enabling this on a wide scale except for debugging purposes. It may also be useful to use process tracking to analyze an attack. For example, buffer overflow exploits are often used to launch command shells, which will be logged of process tracking is turned on. However, a strict log management discipline must be used if process tracking is turned on. | | | | | | | | | Audit System Events Audits events such as system shutdown, start, or events affecting the system and/or security logs, such as clearing the logs. | | | | | | | | |
Logon Rights and PrivilegesLogon rights and privileges govern rights that users have on the target system. They are used to grant the right to perform certain actions, such as logging on from the network or locally, as well as administrative tasks, such as generating new logon tokens. In order to modify User Rights: 1. | Open the applicable Security Policy. | 2. | Expand Security Settings. | 3. | Within Security Settings, expand Local Policies to reveal the Audit, User Rights Assignment, and Security Options policies. | 4. | Click on the User Rights Assignment object. The right-hand details pane will reveal the configurable user rights policy settings. |
Note: Not all groups exist on all types of systems. Therefore, this policy may need to be modified on a system where the target group exists. Alternatively, the policy templates can be hand edited to include the appropriate groups. Table 4.5 lists the User Rights and Privilege Assignments that should be modified from their defaults. Many other rights will show up in the policy editor interfaces, however, their default settings are adequate and need not be modified. The check marks in this table indicate that this modification should be applied to the particular type of system in that column. Table 4.5 User Rights and Privileges Privilege | Default | Modified | | | | | | | Access this computer from the network (Professional/Server) | Administrators Backup Operators Power Users Users Everyone | Administrators Backup Operators Power Users Users Authenticated Users | | | | | | | Access this computer from the network (Domain Controller) | Administrators Authenticated Users Everyone | Administrators Authenticated Users | | | | | | | Log on Locally (Professional) | Administrators Backup Operators Power Users Users Machinename\Guest | Administrators Backup Operators Power Users Users | | | | | | | Log on Locally (Server) | Administrators Backup Operators Power Users Users Machinename\Guest Machinename\TsInternetUser | Administrators Backup Operators Power Users NOTE: You will need to grant this privilege to Users on a Terminal Server Application Server | | | | | | | Log on Locally (Domain Controller) | Administrators Account Operators Backup Operators Print Operators Server Operators TsInternetUser | Administrators Account Operators Backup Operators Print Operators Server Operators | | | | | | | Add Workstations to the Domain (Domain Controller) | Authenticated Users | Authenticated Users | | | | | | | Increase Quotas (Domain Controller – in the Domain Security Policy) | (Not Defined) | Administrators | | | | | | | Increase Scheduling Priority (Domain Controller – in the Domain Security Policy) | (Not Defined) | Administrators | | | | | | | Load and Unload Device Drivers (Domain Controller – in the Domain Security Policy) | (Not Defined) | Administrators | | | | | | | Manage Auditing and Security Log (Domain Controller – in the Domain Security Policy) | (Not Defined) | Administrators | | | | | | | Modify Firmware Environment (Domain Controller – in the Domain Security Policy) | (Not Defined) | Administrators | | | | | | | Profile System Performance (Domain Controller – in the Domain Security Policy) | (Not Defined) | Administrators | | | | | | | Shut Down the System (Clients) | Administrators Backup Operators Power Users Users | Administrators Backup Operators Power Users Authenticated Users | | | | | | | Shut Down the System (Servers) | Administrators Power Users (other groups vary depending on system type) | Administrators | | | | | | | Take Ownership of Files and Objects (Domain Controller – in the Domain Security Policy) | (Not Defined) | Administrators | | | | | | |
Modify Security OptionsModify predefined security related Registry settings: 1. | Open the applicable Security Policy. | 2. | Expand Security Settings. | 3. | Within Security Settings, expand Local Policies to reveal the Audit, User Rights Assignment, and Security Options policies. | 4. | Click on the Security Options object. The right-hand details pane will reveal the configurable security options. | 5. | To set a Security Option, double click on the desired policy in the right-hand details pane. This will open the Security Policy Setting dialog window. | 6. | For Domain-level policies, check the Define these policy settings box. | 7. | Input to the Security Policy Setting dialog boxes for selected security options will vary depending on the configuration requirements of the option. For example some security options may require selection from a drop down menu or a text input as shown below. | 8. | Modify the Security Options as shown in Table 4.6. |
Table 4.6 Security Option Settings Set Additional Restrictions for Anonymous Connections Security Objective: Disable ability of anonymous users to enumerate SAM accounts and shares. Recommendations: | • | Domain and stand-alone servers - set this to "Do not allow enumeration of SAM accounts and shares." This setting is equivalent to RestrictAnonymous set to 1 and frequently, the setting is referred to this way. | | • | Laptops and workstations - set this to "No access without explicit anonymous permissions" (RestrictAnonymous = 2). |
Note: The "No access without explicit anonymous permissions" option has the potential to cause connectivity problems in many environments. Hence, we do not recommend this setting for systems that need to accept inbound connections generally. However, because of its great security value, we encourage testing it thoroughly to evaluate whether it can be used in your particular environment. Currently, several major incompatibilities with this setting are known: 1. | When set to "No access without explicit anonymous permissions" on Exchange 2000 servers, clients will be unable to look up addresses in the Global Address Book. This issue was fixed in Windows 2000 Service Pack 3. | 2. | When set to "Do not allow enumeration of SAM accounts and shares" on a Windows 2000 domain controller, users on Windows XP, NT, and Macintosh clients will be unable to change their domain password at logon. A fix for Windows XP can be obtained from PSS by asking for hotfix 328817. No fix is available for Windows NT and Macintosh clients. | 3. | Down-level clients (Windows 9x and earlier) will be unable to authenticate to the domain if this is set. | 4. | Users on trusting NT 4 domains will be unable to list users from the trusted Windows 2000 domain. | 5. | The Browser Service does not function reliably. | 6. | Inter-forest communication will not function correctly. |
For more information, please see Microsoft Knowledge Base 246261 Note: On a bastion host system, we recommend seriously considering configuring this to "No access without explicit anonymous permissions" | | | | | | | Allow Shutdown without Logon Security Objective: Users should not be able to shut down the system without first having logged on. This is particularly important on terminal servers. Recommendation: Set this policy to Disabled on the systems in the matrix This setting does not actually provide much security on systems without terminal services enabled. An attacker would need physical access to a non-terminal services system to shut it down, in which case he could simply unplug the system. | | | | | | | Audit the Access of Global System Objects Security Objective: Enable the capability to audit access of global system objects. When this policy is enabled, it causes system objects such as mutexes, events, semaphores, and DOS Devices to be created with a default system access control list (SACL). If the Audit object access audit policy is also enabled, then access to these system objects will be audited. Recommendation: Leave this policy disabled except on particularly sensitive systems. On those, set this policy to Enabled. Note: This setting was designed primarily for developers troubleshooting new programs. It will generate a large amount of audit information. Therefore, it should only be enabled where there is a strict audit management process in place for reviewing, archiving, and clearing the audit logs on a regular basis and where the events generated by this setting are actually useful to the forensics process. The maximum log size should also be edited to support an increase in the number of events being logged. | | | | | | | Audit the Use of Backup and Restore Privilege Security Objective: Enable the capability to create audit event entries whenever the Backup files and directories or the Restore files and directories privileges are used. By default, the use of backup and restore privileges are not audited. When the Audit privilege use audit policy is enabled and this security option is set, the use of the Backup and Restore privileges will be audited. Recommendation: This setting generates an extremely large number of events and should only be enabled when troubleshooting backup problems. | | | | | | | Automatically Log Off Users When Logon Time Expires Security Objective: Force a user to log off of the network when that user remains logged on beyond the allowed hour range. Recommendation: In environments where logon time restrictions are enforced, this setting should be enabled. In other environments, this setting has no effect. Note: Keeping users to particular logon times is not a security measure in and of itself. In other words, it does nothing to protect the systems those users touch from the users themselves. | | | | | | | Clear Virtual Memory Page File When System Shuts Down Security Objective: Removes the virtual memory pagefile when the system is shut down. The pagefile is reinitialized the next time a user logs in. The purpose is to ensure that any information that may remain within the page file is not available to the next user that logs on to the machine. Recommendation: Enable this on notebook computers and other machines which may not be physically secured while shut down. Note: Configuring this setting will significantly increase the time it takes to shut down a system. | | | | | | | Digitally sign client communications (always) Security Objective: Determines whether the computer will always digitally sign client communications. The Windows 2000 Server Message Block (SMB) authentication protocol supports mutual authentication, which closes a "man-in-the-middle" attack, and supports message authentication, which prevents active message 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. This setting is disabled by default. Enabling this option requires the Windows 2000 SMB client subsystem to perform SMB packet signing. In this case, the computer will be unable to communicate with servers which do not support digital signing. Unless this is a preferred result, this option should not be set. Rather, ensure that the "when possible" option is set on all systems that support signing (Windows 2000 and higher) to ensure that signing is used whenever it is possible. Recommendation: Do not enable this setting. | | | | | | | Digitally sign client communications (when possible) Security Objective: If this policy is enabled, it causes the Windows 2000 Server Message Block (SMB) client subsystem to perform SMB packet signing when communicating with an SMB server that is enabled or required to perform SMB packet signing. See "Digitally sign client communications (always)" for additional details. Recommendation: Leave this setting enabled, which is the default. | | | | | | | Digitally sign server communications (always) Security Objective: If this policy is enabled, it requires this system to perform Server Message Block (SMB) packet signing when the system is acting as an SMB server. This policy is disabled by default since otherwise it prevents this machine from communicating with client systems which do not perform signing. See "Digitally sign client communications (always)" for additional details. Recommendation: On systems which should not act as SMB servers to down-level systems, this setting should be enabled. Client workstations in a domain should rarely serve in this capacity. Therefore, we recommend that client workstations have this setting enabled. On domain controllers, enabling this setting would prevent certain types of attacks, such as the one discussed in Microsoft Security Bulletin MS02-070. However, this has to be weighed against the fact that down-level clients would be unable to communicate with the domain controller. For that reason, we leave the setting off in the DC configuration templates. In an environment with only Windows 2000 or newer clients, this setting should be enabled on the domain controllers. | | | | | | | Digitally sign server communications (when possible) Security Objective: If this policy is enabled, it enables this system to perform Server Message Block (SMB) packet signing when the system is acting as an SMB server. This policy is disabled by default on workstation and server platforms in Local Computer Policy. This policy is enabled by default on Domain Controllers.. See "Digitally sign client communications (always)" for additional details. Recommendation: This setting should be enabled on all systems. Note: This setting imposes a communications overhead which could be significant in some cases. Therefore, you should evaluate this setting in your environment to ensure that it will not degrade network response time beyond acceptable levels. | | | | | | | Disable CTRL+ALT+DEL Required for Logon Security Objective: Enabling this option will disable the trusted path mechanism. The purpose of the trusted path mechanism is to prevent spoofing of user login sessions. It is the mechanism which causes the operating system to always intercept CTRL+ALT+DEL key-sequences and prevents other sub-systems and processes from capturing that key-sequence. If this mechanism is disabled, it would be simply for an attacker to spoof the logon interface with a keystroke logger. Therefore, this setting should never be enabled. The default setting of this option is Disabled on a Windows 2000 computer, although a policy tool may show it as Not Defined. Recommendation: Set this policy to disabled. Note: The default is "leave as is" but disabling the setting ensures that it is overridden on machines where it has been changed. | | | | | | | Do Not Display Last User Name on Logon Screen Security Objective: By default, the Windows 2000 login interface displays the user name of the last user that logged onto the computer. Enabling this option removes the name of the last user from the login session. As a result, an intruder attempting to break into the computer locally would not only need to guess the password, but would also need to guess a correct user name. However, obtaining a list of user names is not particularly difficult and passwords are the proper defense mechanism. Further, enabling this setting has been shown to increase technical support costs since users may forget their username. Recommendation: We recommend enabling this setting only on machines that are set up for shared use, such as lab workstations or terminal servers. On other machines, this setting provides little value to offset the increased support cost. | | | | | | | LAN Manager Authentication Level Security Objective: This Security Option is used to enforce a particular type of authentication protocols used for Windows networking, as well as enable a new type of authentication protocol (NTLMv2). NTLMv2 is a new type of authentication protocol which significantly enhances the security of Windows authentication. It prevents many spoofing attacks, and allows the server to authenticate itself to the client. The nature of the NTLM protocol allows password crackers to use a captured NTLM authentication session to crack passwords. To counteract this, NTLM version 2 was developed. NTLMv2 introduces additional security features, including | • | Unique session keys per connection. Each time a new connection is established, a unique session key is generated for that session. This way a captured session key will serve no useful purpose after the connection is completed. | | • | Session keys protected with a key exchange. The session key can't be intercepted and used unless the key pair used to protect the session key is obtained. | | • | Unique keys generated for the encryption and integrity of session data. The key that's used for the encryption of data from the client to the server will be different from the one that's used for the encryption of data from the server to the client. | | • | Stronger encryption. NTLMv2 uses a stronger encryption protocol for the session keys as well as a stronger hashing algorithm for the message integrity and authentication sequences. |
For more information on NTLMv2, see Knowledge Base article 147706. NTLMv2 has been available since Windows NT 4.0 Service Pack 4, and is available for Windows 9x in the Directory Services Client which ships on the Clients\Win9x directory on the Windows 2000 CD-ROM. This setting is often referred to in the literature as "LMCompatibilityLevel" which is the name of the actual registry switch used to enable it. The setting affects both the authentication protocol and the session security protocol used after authentication. All Windows NT-based systems since Windows NT 4.0 SP4 (including Windows 2000, Windows XP, and Windows Server 2003) will accept SMB client connections using NTLMv2 authentication without further modification. The LMCompatibilityLevel setting is used to modify several aspects of authentication: 1. | Modify the authentication protocols the systems will send when they act as clients | 2. | Modify the authentication protocols they accept when acting as servers. The value of the setting on the machine that holds the account database governs this behavior. In other words, when domain accounts are used, the value of the setting on the domain controller takes effect. When using local accounts, the value of the setting on the server is the effective one. | 3. | Enable NTLMv2 session security. |
There are 6 possible settings which govern this behavior. The numbers in parentheses are the actual settings of the LMCompatibilityLevel registry value. The client behavior column shows how a machine with this setting behaves as an SMB client. The server behavior column shows how the server performing the authentication behaves if this setting is made on that server. The authentication server is always the DC when domain accounts are used and the DC is reachable. If the DC is not reachable, or local accounts are used, the authentication server is the server that the client is connecting to. Recommendation Set this as high as your environment allows, as per the following guidelines: | • | In a pure Windows NT 4.0 SP4 and higher environment (including Windows 2000 and XP) set this to 5 on all clients, and then to 5 on all servers once all clients are configured. The exception is Windows 2000 RRAS servers which will not function properly if this setting is set higher than 4. | | • | If you have Windows 9x clients, and you can install the DSClient on all such clients, set this to 5 on Windows NT-based machines (NT, 2000 and XP) and to 3 on Windows 9x machines. Otherwise, you must leave this setting at no higher than 3 on non-Windows 9x machines. | | • | If you find applications that break when this setting is enabled, roll it back one step at a time to discover what breaks. At a minimum, this setting should be set to 1 on all machines, and can typically be set to 3 on all machines. If you have a priority support contract, please contact PSS and let them know what applications break and at what level. |
Note: Setting LMCompatibility higher than 2 in a mixed Windows NT 4.0 and Windows 2000 domain environment can cause interoperability problems. For more information, see Microsoft Knowledge Base article 305379. The W2KHG-baseline.inf template sets LMCompatibilityLevel to "Send NTLMv2 response only (3)." | | | | | | | Implement an Authorized Usage Warning Security Objective: Configure the interactive logon screen to display a logon banner with a title and warning. This banner is primarily used to comply with, and notify users of, authorized usage policy. Please contact legal counsel to determine whether there are legal reasons to use it or that require it. Recommendation: Set this banner in accordance with your information security policy. | | | | | | | Disable Caching of Logon Information Security Objective: Windows 2000 has the capability to cache logon information. If the Domain Controller cannot be found during logon and the user has logged on to the system in the past, it can use those credentials to log on. This is extremely useful, for example, on portable computers, which need to be used when the user is away from the network. The CachedLogonsCount Registry valued determines how many user account entries Windows 2000 saves in the logon cache on the local computer. The logon cache is a secured area of the computer and the credentials are protected using the strongest form of encryption available on the system. If the value of this entry is 0, Windows 2000 does not save any user account data in the logon cache. In that case, if the user's Domain Controller is not available and a user tries to log on to a computer that does not have the user's account information, Windows 2000 displays the following message: The system cannot log you on now because the domain <Domain-name> is not available. If the Administrator disables a user's domain account, the user could still use the cache to log on by disconnecting the net cable. To prevent this, Administrators may disable the caching of logon information. The default setting allows caching of 10 sets of credentials. Recommendation: Set this to at least 2 to ensure that the system is usable while the domain controllers are down or unavailable. | | | | | | | Prevent System Maintenance of Computer Account Passwords Security Objective: Computers in a Windows 2000 domain need to authenticate themselves to the domain controller before they can use domain resources. This setting determines whether the computer account password should be prevented from being reset every week. As a part of Windows 2000 security, computer account passwords are changed automatically every seven days. If this policy is enabled, the machine is prevented from requesting a weekly password change. If this policy is disabled, a new password for the computer account will be generated every week. This policy is disabled by default. Recommendation: Set this policy to disabled to ensure that it is configured properly on machines where it was overridden at some point. There is virtually no reason to ever enable this policy. | | | | | | | Prevent Users from Installing Print Drivers Security Objective: Determines whether members of the Users group are prevented from installing print drivers. If this policy is enabled, it prevents users from installing printer drivers on the local machine. This prevents users from "Adding Printers" when the device driver does not exist on the local machine. If this policy is disabled, then a member of the Users group can install printer drivers on the computer. By default, this setting is enabled on servers and disabled on workstations to reduce the support overhead associated with forcing administrators to install printer drivers. While enabling this setting would marginally increase the security of workstations, it will significantly increase administrative overhead. This needs to be balanced against the third immutable law of security: "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore." Recommendation: Leave this setting unchanged. | | | | | | | Prompt User to Change Password before Expiration Security Objective: Determines how far in advance Windows 2000 should warn users that their password is about to expire. By giving the user advanced warning, the user has time to construct a sufficiently strong password. By default, this value is set to 14 days. Recommendation: None. The default setting is adequate. | | | | | | | Recovery Console: Allow Automatic Administrative Logon Security Objective: By default, the Recovery Console requires that a password be provided for the Administrator account before accessing the system. If this option is enabled, the Recovery Console does not require a password and will automatically log on to the system. By default, this setting is disabled, although a policy tool may show it as Not Defined. Recommendation: Set this option to disabled. | | | | | | | Recovery Console: Allow Floppy Copy and Access to All Drives and Folders Security Objective: Enabling this option enables the Recovery Console SET command, which allows the following Recovery Console environment variables to be set: | • | AllowWildCards - Enable wildcard support for some commands (such as the DEL command). | | • | AllowAllPaths - Allow access to all files and folders on the computer. | | • | AllowRemovableMedia - Allow files to be copied to removable media, such as a floppy disk. | | • | NoCopyPrompt - Do not prompt when overwriting an existing file. |
By default, the SET command is disabled and all these variables are not enabled, although a policy tool may show it as Not Defined. Recommendation: Enable this option to enhance the ability to recover the system through the recovery console. | | | | | | | Rename Administrator Account Security Objective: Used to change the name that is associated with the security identifier (SID) for the account "Administrator." This provides virtually no security value since it is trivial to determine the name of the Administrator account unless anonymous access is disabled. If "Set Additional Restrictions for Anonymous Connections" is set to "Do not allow enumeration of SAM accounts and shares", this setting does, however, buy you a marginal measure of security. However, a username is not a password and a strong password should be used to protect the Administrator account instead of a non-standard name. Furthermore, some programs will fail if you rename the Administrator account. Recommendation: Do not bother renaming the Administrator account for its security benefits unless you are also able to use restrict anonymous enumeration of SAM accounts. | | | | | | | Rename Guest Account Security Objective: Used to change the name that is associated with the security identifier (SID) for the account "Guest." This setting provides no security value. Recommendation: Do not bother renaming the Guest account for its security benefits. Just make sure it is disabled. | | | | | | | Restrict CD-ROM Access to Locally Logged-On User Only Security Objective: Determines whether a CD-ROM is accessible to both local and remote users simultaneously. If enabled, this policy allows only the interactively logged-on user to access removable CD-ROM media. If this policy is disabled the CD-ROM may be shared over the network if no one is logged on interactively. Recommendation: This setting provides very little security, particularly since it only takes effect when a user is logged on. Do not enable this setting | | | | | | | Restrict Floppy Access to Locally Logged-On User Only Security Objective: Determines whether a floppy disk is accessible to both local and remote users simultaneously. If enabled, this policy allows only the interactively logged-on user to access removable floppy media. If this policy is disabled the floppy may be shared over the network if no one is logged on interactively. Recommendation: This setting provides very little security, particularly since it only takes effect when a user is logged on. Do not enable this setting | | | | | | | Secure Channel: Digitally Encrypt or Sign Secure Channel Data (Always) Security Objective: Determines whether the computer will always digitally encrypt or sign secure channel data. The secure channel is used to communicate between domain controllers and domain members. When a Windows 2000 system joins a domain, a computer account is created. Thereafter, when the system boots, it uses the password for that account to create a secure channel with the domain controller for its domain. Examples of traffic flowing over the secure channel include logon traffic. Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the channel is not integrity checked and not all information is encrypted. If this policy is enabled, all outgoing secure channel traffic must be either signed or encrypted. If this policy is disabled, signing and encryption are negotiated with the domain controller. By default, this policy is disabled. Recommendation: This policy should not be enabled unless it is desirable to prevent the system from communicating with down-level domains. | | | | | | | Secure Channel: Digitally Encrypt Secure Channel Data (When Possible) Security Objective: Determines whether the computer will negotiate encryption of the secure channel with a domain controller. By default, all sensitive information is already encrypted. If this policy is enabled, the system will encrypt all traffic over the secure channel when communicating with domain controllers that support it. By default, this option is enabled. Recommendation: Do not change the default setting. | | | | | | | Secure Channel: Digitally Sign Secure Channel Data (When Possible) Security Objective: Determines whether the computer will negotiate integrity signing of secure channel data. Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the channel is not integrity checked and not all information is encrypted. If this policy is enabled secure channel traffic will be digitally signed when communicating with domain controllers that support signing. By default, this option is enabled. Recommendation: Do not change the default setting. | | | | | | | Secure Channel: Require Strong (Windows 2000 or Later) Session Key Security Objective: If this policy is enabled, all outgoing secure channel traffic will require a strong (Windows 2000 or later) encryption key. If this policy is disabled, the key strength is negotiated with the DC. This option should only be enabled if all of the DCs in all trusted domains support strong keys. By default, this value is disabled. Procedure: If all legitimate DCs are running Windows 2000 or higher, enable this policy. Otherwise, leave it disabled. | | | | | | | Send Unencrypted Password to Connect to Third-Party SMB Servers Security Objective: If this policy is enabled, the Server Message Block (SMB) redirector is allowed to send clear-text passwords to non-Microsoft SMB servers that do not support password encryption during authentication. By default, this option is disabled. Recommendation: Set this to disabled to ensure that it overrides changes made to individual machines | | | | | | | Shut Down the System Immediately if Unable to Log Security Audits Security Objective: Determines whether the system should shut down if it is unable to log security events. If this policy is enabled, it causes the system to halt if a security audit cannot be logged for any reason. Typically, an event will fail to be logged when the security audit log is full and the retention method specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days. If the security log is full and an existing entry cannot be overwritten and this security option is enabled, the following blue screen error will occur:
STOP: C0000244 {Audit Failed}
An attempt to generate a security audit failed.
To recover, an administrator must log on, archive the log (if desired), clear the log, and reset this option as desired. By default, this policy is disabled. If this policy is enabled, an attacker can easily create a denial of service condition by simply generating a large number of event log entries. Recommendation: Do not enable this policy. Proper log management strategies will prevent event loss without enabling attackers to create a denial of service condition. | | | | | | | Smart Card Removal Behavior Security Objective: Determines what should happen when the smart card for a logged-on user is removed from the smart card reader. The options are: | • | No Action | | • | Lock Workstation | | • | Force Logoff |
By default, No Action is specified. If Lock Workstation is specified, then the workstation is locked when the smart card is removed allowing users to leave the area, take their smart card with them, and still maintain a protected session. If Force Logoff is specified, then the user is automatically logged off when the smart card is removed. Recommendation: Configure smart card removal to lock the workstation Note: Smart card logon is only supported in a domain environment. Therefore, this setting has no effect on stand-alone systems | | | | | | | Strengthen Default Permissions of Global System Objects (e.g. Symbolic Links) Security Objective: Determines the strength of the default discretionary access control list (DACL) for system objects. Windows 2000 maintains a global list of shared system resources such as DOS device names, mutexes, and semaphores. Objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. If this policy is enabled, the default DACL is stronger, allowing non-admin users to read shared objects, but not modify shared objects that they did not create. By default, this option is enabled locally on Windows 2000 Professional and Server, but is not defined in the Domain Security Policy. Recommendation: Ensure that this setting is configured to enabled. | | | | | | | Unsigned Driver Installation Behavior Security Objective: Determines what should happen when an attempt is made to install a device driver (by means of the Windows 2000 device installer) that has not been signed by the publisher of the driver. The options are: | • | Silently succeed | | • | Warn but allow installation | | • | Do not allow installation |
The default setting is to Warn but allow installation. Recommendation: The default setting is adequate. | | | | | | | Unsigned Non-Driver Installation Behavior Security Objective: Determines what should happen when an attempt is made to install any non-device driver software that has not been signed. The options are: | • | Silently succeed | | • | Warn but allow installation | | • | Do not allow installation |
The default setting is to Silently succeed. Recommendation: Very little software is digitally signed today. Therefore, this setting has no real effect. Leaving it at the default is fine. | | | | | | |
Additional Security SettingsThe additional security settings described in this subsection are not available in the default security policy GUIs. These settings can be configured using the Registry Editor or by installing the customized sceregvl.inf template shipped with this guide. The custom sceregvl.inf template will add these settings to the default security policy GUI. Information on how to edit the Registry is also available through the Help tool in the registry editor itself. For example, for instructions on adding a key to the Registry: 1. | Click the Start button and select Run... | 2. | Within the Run dialog window's text box, type regedt32 and click the OK button to open the Registry Editor (Regedt32.exe). | 3. | From the editor's Help menu, select Contents. | 4. | In the right-hand pane of the Registry Editors Help tool, click on the "Add and delete information in the registry" hyperlink. | 5. | The pane will change to provide a list of help topics for adding and deleting information in the Registry. Click on the "Add a key to the registry" hyperlink to obtain the detailed instructions. |
Note: It is highly recommended to use regedt32.exe (a.k.a. the Windows NT registry editor) and not regedit.exe (a.k.a. the Windows 95 registry editor) to modify registry settings. Both editors ship with Windows 2000 and regedit.exe is generally perceived as easier to use. However, regedit.exe does not support all the registry data types and will convert certain types it does not understand. Certain values will not be read properly if they are converted and this can cause serious problems with the system, including failure to boot. Editing the registry manually is at your own risk. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, see article 256986 in the Microsoft Knowledge Base: Other Registry SettingsThe Registry settings described in this subsection can be used to further enhance the security posture of the operating system. With the exception of the settings in the "Service Pack 3 Registry entries" section these settings are available in all versions of Windows 2000. Remove OS/2 and POSIX subsystemsThe OS/2 and POSIX subsystems are included for compatibility with POSIX and OS/2 applications. It is rare that these types of applications need to be run on Windows 2000, and in most cases, these sub-systems can safely be removed. However, be sure to make a backup of this registry key before removing it manually (or use the template, which allows you to revert the setting). To remove OS/2 and POSIX support from Windows 2000, edit the Registry and delete the value as shown in the table b |
