 |
Devices: Unsigned driver installation behavior |
This setting determines what happens when an attempt is made to install a device driver, by means of the Setup application programming interface (Setup API), which has not been certified by the Windows Hardware Quality Lab (WHQL). This option prevents the installation of unsigned drivers, or warns the administrator that an unsigned driver software is about to be installed. This can prevent the installation of drivers via the Setup API that have not been certified to run on Windows Server 2003. This setting will not prevent a method used by some attack tools where malicious .sys files are copied and registered to start as system services. |
Warn but allow installation |
|
Recovery console: Allow automatic administrative logon |
The Recovery console: Allow automatic administrative logon setting determines if the Administrator account password must be given before access to the system is granted. Enabling this setting automatically logs on to the system without requiring a password at the Recovery Console. The Recovery Console can be very useful when troubleshooting and repairing systems that can not be restarted. However, configuring this setting to enable automatic log on to the console is dangerous. Anyone could walk up to the server, shut it down by disconnecting the power, reboot it, select Recover Console from the Restart menu, and then assume full control of the server.
Set Recovery Console: Allow automatic administrative logon to Disabled. |
Disabled |
|
Recovery console: Allow floppy copy and access to all drives and all folders |
Enabling the Recovery console: Allow floppy copy and access to all drives and all folders option makes the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables.
AllowWildCards: Enables wildcard support for some commands (such as the DEL command).
AllowAllPaths: Allows access to all files and folders on the computer.
AllowRemovableMedia: Allows files to be copied to removable media, such as a floppy disk.
NoCopyPrompt: Do not prompt when overwriting an existing file.
An authorized administrator could forget to remove a CD – ROM or floppy disk with sensitive data or applications that a malicious user could then steal. An authorized administrator could accidentally leave a startup disk in the computer after having used the Recovery Console. If the computer is restarted for any reason, and the BIOS was configured to boot from the CD – ROM or floppy disk drive before the hard disk, the server would start from the removable disk. This would cause the server's network services to be unavailable.
Set Recovery Console: Allow floppy copy and access to drives and folders to Disabled. |
Disabled |
|
Devices: Restrict CD-ROM access to locally logged-on user only |
N/A |
Disabled |
|
Devices: Allowed to format and eject removable media |
This setting determines who is allowed to format and eject removable media.
The possible values for this Group Policy setting are:
* Administrators
* Administrators and Power Users
* Administrators and Interactive Users
* Not defined
Users may be able to move removable disks to a different computer where they have administrative privileges. The user could then take ownership of any file, grant himself or herself full control and view or modify any file. The advantage of this setting is diminished by the fact that most removable storage devices will eject media with the press of a button. |
Administrators |
|
Devices: Restrict floppy access to locally logged-on user only |
N/A |
Disabled |
|
Interactive logon: Number of previous logons to cache (in case domain controller is not available) |
The Interactive logon: Number of previous logons to cache (in case domain controller is not available) setting determines whether a user can log on to a Windows domain using cached account information. Logon information for domain accounts can be cached locally so that, in the event a domain controller cannot be contacted on subsequent logons, a user can still log on. This 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 is not available.
The number assigned to this setting indicates the number of users whose logon information the servers caches 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, 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 determine user passwords.
Windows mitigates this type of attack by encrypting the information and keeping the cached credentials in the systems' registries which are spread across numerous physical locations. |
10 logons |
 |
Interactive logon: Require Domain Controller authentication to unlock workstation |
Unlocking a locked computer requires logon information. 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. Enabling this setting requires a domain controller to authenticate the domain account that is being used to unlock the computer. Disabling this setting allows a user to unlock the computer using cached credentials. The computer caches the credentials of any users that have been authenticated locally in memory. 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 this authentication process. This means not only that user privileges are not updated, but more importantly that disabled accounts are still able to unlock the console of the system. |
Disabled |
|
Interactive logon: Prompt user to change password before expiration |
The Interactive logon: Prompt user to change password before expiration 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.
It is recommended that user passwords are configured to expire periodically. Users will need warning their passwords are going to expire, or they may inadvertently get locked out of the system. This could lead to confusion for users accessing the network locally, or make it impossible for users who are accessing your organization's network via dial – up or virtual private network (VPN) connections to log on to the network. |
14 days |
|
Interactive logon: Smart card removal behavior |
The Interactive logon: Smart card removal behavior security setting determines what happens when the smart card for a logged – on user is removed from the smart card reader. If smart cards are used for authentication, then the computer should automatically lock itself when the card is removed. This way if users forget to manually lock their workstations when they are away from them malicious users cannot gain access. |
No Action |
|
Interactive logon: Do not require CTRL+ALT+DEL |
This setting determines whether pressing CTRL+ALT+DEL is required before a user can log on. Enabling this setting on a computer, allows a user to log on without pressing CTRL+ALT+DEL. Disabling this setting requires users to press CTRL+ALT+DEL before logging on to Windows, unless they are using a smart card for Windows logon. A smart card is a tamper – proof device that stores security information. Microsoft developed this feature to make it easier for users with certain types of physical impairments to log on to computers running Windows. Not having to press the CTRL+ALT+DEL key combination leaves users susceptible to attacks that attempt to intercept their passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords.
An attacker could install a Trojan horse program that looks like the standard Windows logon dialog box and captures 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. |
Disabled |
|
Interactive logon: Do not display last user name |
This setting determines whether the Log on to Windows dialog box displays the name of the last user to log on to the computer. Enabling this setting does not display the name of the last user to successfully log on in the Log On to Windows dialog box. Disabling this setting displays the name of the last user to log on. An attacker with access to the console, for example someone with physical access or someone who is able to connect to the server via Terminal Services, could view the name of the last user who logged on to the server. The attacker could then attempt to log on to the server by guessing the password, using a dictionary, or by brute force attack. |
Disabled |
|
Interactive logon: Display user information when the session is locked |
N/A |
No Action |
|
Interactive logon: Message title 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. Interactive logon: Message text for users attempting to log on specifies a text message displayed to users when they log on Interactive logon: Message title for users attempting to log on specifies a title to appear in the title bar of the window that contains the text message. This text is often used for legal reasons, for example, to warn users about the ramifications of misusing company information or to warn them that their actions may be audited. Not utilizing this warning – message setting leaves your organization legally vulnerable to trespassers who unlawfully penetrate your network. Legal precedents have established that organizations displaying warnings to users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers. |
N/A |
|
Interactive logon: Message text for users attempting to log on |
N/A |
Not found |
|
Interactive logon: Require smart card |
The Interactive logon: Require smart card security setting requires users to log on to a computer using a smart card. Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This reduces the chance that an attacker will be able to guess a user's password via a brute force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with todays technology, it is nearly impossible for an attacker to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two – factor authentication: the user attempting to log on 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 for encrypting traffic between the user and the domain controller.
Potential Impact
All users will have to use smart cards to log onto the network; this means that the organization will have to have a reliable public key infrastructure (PKI) in place, smart cards, and smart card readers for all users. These are significant challenges because planning for and deploying these technologies requires expertise and resources. However, Windows Server 2003 includes Certificate Services, a highly advanced server for implementing and managing certificates that, when combined with Windows XP, includes features such as automatic user and computer enrollment and renewal. |
Disabled |
|
Shutdown: Allow system to be shut down without having to log on |
The Shutdown: Allow system to be shut down without having to log on setting determines whether a computer can be shut down without having to log on to Windows. Enabling this setting makes the Shut Down command available on the Windows logon screen. Disabling this command removes the option to shut down the computer from the Windows logon screen. In this case, users must be able to log on to the computer successfully and have the Shut down the system user right before they can perform a system shutdown.
Users who can access the console locally could shut the system down. Attackers or misguided users could connect to the server via Terminal Services and shut it down or restart it without having to identify themselves.
Attacker could also perform this action by walking up to the local console and restarting the server, causing a temporary DoS condition, or shutting down the server, leaving all of its applications and services unavailable.
Set the Allow system to be shut down without having to log on to the value Disabled. |
Disabled |
|
Devices: Allow undock without having to log on |
This setting determines whether a user must log on to request permission to remove a portable computer from a docking station. Enabling this setting allows a user to undock a computer by pressing the portable computer's physical eject button. Disabling this setting requires that the user must log on to get undocking permission. Only users who have the Remove Computer from Docking Station privilege can get this permission. Note: This setting should only be disabled for portable computers that cannot be mechanically undocked. Otherwise, enabling the setting allows a users to physically remove the computer when they cannot log in and the eject button does not work. |
Enabled |
|
System cryptography: Force strong key protection for user keys stored on the computer |
The System cryptography: Force strong key protection for user keys stored on the computer security setting determines whether users' can use private keys, such as their S – MIME key ,without a password.
Configuring this setting so that users must provide a password — distinct from their domain password — every time they use a key makes it more difficult for an attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines their logon password.
Set System cryptography: Force strong key protection for user keys stored on the computer to User must enter a password each time they use a key. |
No Action |
|
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax |
N/A |
Not found |
|
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax |
N/A |
Not found |
|
System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies |
The System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies security setting determines if digital certificates are processed when a user or process attempts to run software with an.exe file name extension. This security setting enables or disables certificate rules (a type of software restriction policies rule). With software restriction policies, you can create a certificate rule that will allow or disallow the running of Authenticode – signed software, based on the digital certificate that is associated with the software. In order for certificate rules to take effect, you must enable this security setting.
Software restriction policies help to protect users and computers from executing unauthorized code such as viruses and Trojans horses.
Set System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies to Enabled. |
Disabled |
|
Audit: Audit the access of global system objects |
Enabling this setting creates system objects, such as mutexes, events, semaphores, and MS – DOS® devices, with a default System Access Control List (SACL). If the Audit object access audit setting is also enabled, 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. By virtue of having a name, these objects are global in scope, and therefore visible to all processes on the system. These objects all have a security descriptor, but typically have a NULL SACL. Enabling this setting at boot time causes the kernel to assign a SACL to these objects when they are created. The threat is that a globally – visible named object, if incorrectly secured, could be acted upon by a malicious program which 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 which created it to malfunction, however, the risk of this occurring is very low. |
Disabled |
|
Audit: Shut down system immediately if unable to log security audits |
This setting determines whether the system shuts down if it is unable to log security events. This setting is a requirement for Trusted Computer System Evaluation Criteria (TCSEC) – C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log those events. Microsoft has chosen to meet this requirement by halting the system and displaying a stop message in the case of a failure of the auditing system. Enabling this setting stops the system if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the security audit log is full and its specified retention method is either Do Not Overwrite Events or Overwrite Events by Days. With this option enabled, if the security log is full and an existing entry cannot be overwritten, the following Stop message appears:
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 reset this option as desired. The administrative burden of enabling this setting can be very high, especially if you also configure the Retention method for security log to Do not overwrite events (clear log manually). This setting turns a repudiation threat (a backup operator could deny that they backed up or restored data) into a denial of service (DoS) vulnerability because a server could be forced to shut down by overwhelming it with logon events and other security events that are written to the security log. Additionally, since the shut down is not graceful, it is possible that irreparable damage to the operating system, applications, or data could result. While NTFS file system (NTFS) will guarantee that the file system's integrity will be maintained during an ungraceful system shutdown, it cannot guarantee that every data file for every application will still be in a usable form when the system restarts. |
Disabled |
|
Network access: Do not allow storage of credentials or .NET Passports for network authentication |
The Network access: Do not allow storage of credentials or.NET Passports for network authentication setting determines whether the Stored User Names and Passwords saves passwords or credentials for later use when it gains domain authentication. Enabling this setting prevents the Stored User Names and Passwords feature of Windows from storing passwords and credentials. Passwords cached in this manner can be accessed by the user when logged onto the computer. This may sound obvious, but the problem arises if the user unknowingly executes hostile code that reads the passwords and forwards them to another, unauthorized user. |
Disabled |
|
Network access: Let Everyone permissions apply to anonymous users |
The Network access: Let Everyone permissions apply to anonymous users setting determines what additional permissions are granted for anonymous connections to the computer. Enabling this setting allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This 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 created for anonymous connections does not include the Everyone SID. Therefore, permissions granted to the Everyone group do not apply to anonymous users. Enabling this setting adds the Everyone SID to the token created for anonymous connections. In this case, anonymous users are able to access any resource for which the Everyone group has been given permissions. 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. |
Disabled |
|
System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing |
The System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting determines if the TLS/SSL Security Provider will only support the strong cipher suite known as : TLS_RSA_WITH_3DES_EDE_CBC_SHA. In effect, this means that the provider only supports the TLS protocol as a client and as a server, if applicable. It uses only the Triple Data Encryption Standard (DES) encryption algorithm for the TLS traffic encryption, only the Rivest – Shamir – Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA – 1) hashing algorithm for the TLS hashing requirements.
For Encrypting File System Service (EFS), it supports only the Triple DES encryption algorithm for encrypting file data supported by the Windows NTFS File System. By default, the EFS uses the DESX algorithm (a variation of the DES algorithm) for encrypting file data.
Enabling this setting ensures that the computer will use the most powerful algorithms available for digital encryption, hashing and signing. This will minimize the risk of an unauthorized user compromising digitally encrypted or signed data.
Set System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing to Enabled.
Clients with this setting enabled will be unable to communicate via digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms will not be able to use servers that require them for network communications. For example, many Apache – based Web servers are not configured to support TLS. If you enable this setting you will also need to configure Internet Explorer to use TLS. |
Disabled |
|
Network access: Sharing and security model for local accounts |
The Network access: Sharing and security model for local accounts setting determines how network logons that use local accounts are authenticated. If this setting is set to Classic, network logons that use local account credentials authenticate by using those credentials. If this setting is set to Guest only, network logons that use local accounts are automatically mapped to the Guest account. The classic model allows fine control over access to resources. By using the classic model, you can grant different types of access to different users for the same resource. Using the guest only model treats all users equally. All users authenticate as Guest, and they all receive the same level of access to a given resource, which can be either Read Only or Modify.
The default setting on stand – alone Windows XP Professional is Guest only. The default for Windows XP systems joined to a domain and Windows Server 2003 systems is Classic.
Note: This setting does not affect network logons that use domain accounts.
Nor does this setting affect interactive logons that are performed remotely by using services such as Telnet or Terminal Services.
When the computer is not joined to a domain, this 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 does has no effect on Windows 2000 computers. With the guest only model, any user who can access your computer over the network does so with guest privileges. This means that they will probably be unable to write to those shares. While this does increase security it makes it impossible for authorized users to access shared resources on those systems. With the classic model, local accounts must be password protected; otherwise, anyone can use those user accounts to access shared system resources. |
Classic - local users authenticate as themselves |
|
Audit: Audit the use of Backup and Restore privilege |
This setting determines whether to audit the use of all user privileges, including Backup and Restore, when the Audit privilege use setting is in effect. Enabling both policies generates an audit event for every file that is backed up or restored. Enabling this setting in conjunction with the Audit privilege use setting records any instance of user rights being exercised in the security log. If you disable this setting, when users use Backup or Restore privileges, those events are not audited, even with Audit privilege use enabled. |
Disabled |
|
Accounts: Limit local account use of blank passwords to console logon only |
The Accounts: Limit local account use of blank passwords to console logon only 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 this setting is enabled, a local account must have a nonblank password to be used to perform an interactive or network logon from a remote client. Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. In fact, the default settings for Windows Server 2003 Active Directory® domains require complex passwords of at least seven characters. Nevertheless, if a user with the ability to create new accounts makes one that has bypassed your domain – based password policies, that account could have a blank password. For example, a user could build a stand – alone system, 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 account name can then use accounts with blank passwords to log onto systems. |
Enabled |
|
Network security: LAN Manager authentication level |
LAN Manager (LM) is a family of early Microsoft client/server software that allows users to link personal computer systems together on a single network. Networking capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains Kerberos is the default for authentication, but if Kerberos isn't negotiated for some reason Active Directory will use LM, NTLM, or NTLMv2.
LM authentication, including the LM, NTLM, and NTLM version 2 (NTLMv2) variants, is the protocol used to authenticate all Windows clients for such operations as:
*Joining a domain
*Authenticating between Active Directory forests
*Authenticating to down – level domains
*Authenticating to down – level (non – Windows 2000, Windows Server 2003, or Windows XP – based systems)
*Authenticating to systems that aren't in the domain
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 clients use, the session security level the systems negotiate, and the authentication level servers accept as follows:
Send LM & NTLM responses: Clients use LM and NTLM authentication and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send LM & NTLM – use NTLMv2 session security if negotiated: Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLM response only:Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only/refuse LM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).
Send NTLMv2 response only/refuse LM & NTLM: Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and NTLM (accept only NTLMv2 authentication). Set LAN Manager Authentication Level 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. |
Send NTLM response only |
|
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients |
The Network security: Minimum session security for NTLM SSP based (including secure RPC) clients security setting allows a client to require the negotiation of message confidentiality (encryption), message integrity, 128 – bit encryption, or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The possible values for this Group Policy setting are:
Require message confidentiality. The connection will fail if encryption is not negotiated. Encryption converts data into a form that is not readable by anyone until decrypted.
Require message integrity. The connection will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with by attaching a cryptographic signature which identifies the sender and is a numeric representation of the contents of the message.
Require 128 – bit encryption. The connection will fail if strong encryption (128 – bit) is not negotiated.
Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not negotiated.
Not defined.Enabling all of these options for this setting will help protect network traffic that uses the NTLM Security Support Provider (NTLM SSP) from being exposed or tampered with by an attacker who has gained access to the same network. That is, these settings help protect against man – in – the – middle attacks.
Enable all for options available for the Network security: Minimum session security for NTLM SSP based (including secure RPC) clients policy. |
0 |
|
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers |
The Network security: Minimum session security for NTLM SSP based (including secure RPC) servers security setting allows a server to require the negotiation of message confidentiality (encryption), message integrity, 128 – bit encryption, or NTLMv2 session security. These values are dependent on the LAN Manager Authentication Level security setting value. The possible values for this Group Policy setting are:
Require message confidentiality. The connection will fail if encryption is not negotiated. Encryption converts data into a form that is not readable by anyone until decrypted.
Require message integrity. The connection will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with by attaching a cryptographic signature which identifies the sender and is a numeric representation of the contents of the message.
Require 128 – bit encryption. The connection will fail if strong encryption (128 – bit) is not negotiated.
Require NTLMv2 session security. The connection will fail if the NTLMv2 protocol is not negotiated.
Not defined
Enabling all of these options for this setting will help protect network traffic that uses the NTLM Security Support Provider (NTLM SSP) from being exposed or tampered with by an attacker who has gained access to the same network. That is, these settings help protect against man – in – the – middle attacks.
Enable all for options available for the Network security: Minimum session security for NTLM SSP based (including secure RPC) servers policy. |
0 |
|
System objects: Default owner for objects created by members of the Administrators group |
The System objects: Default owner for objects created by members of the Administrators group setting determines whether the Administrators group or an object creator is the default owner of any system objects that are created.
Configuring this setting value Administrators group will make it impossible to hold individuals accountable for creating new system objects.
Set System objects: Default owner for objects created by members of the Administrators group to Object creator. |
Administrators group |
|
Network security: Do not store LAN Manager hash value on next password change |
The Network security: Do not store LAN Manager hash value on next password change setting determines if, at the next password change, local area network (LAN) Manager is prevented from storing hash values for the new password. By attacking the SAM file, attackers can potentially gain access to usernames and passwords hashes. Attackers can use a password cracking tool to determine what the password is. Once they have access to this information, they can use it to gain access to resources on your network by impersonating users. Enabling this setting will not prevent these types of attacks, but they will be much more difficult. |
Disabled |
|
Network access: Do not allow anonymous enumeration of SAM accounts and shares |
The Network access: Do not allow anonymous enumeration of SAM accounts and shares setting determines whether anonymous enumeration of Security Accounts Manager (SAM) accounts and shares is allowed. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. If you do not want to allow anonymous enumeration of SAM accounts and shares, then enable this setting. 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. |
Disabled |
|
Network access: Do not allow anonymous enumeration of SAM accounts |
The Network access: Do not allow anonymous enumeration of SAM accounts setting determines what additional permissions will be granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This 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, an anonymous user has the same access that is granted to the Everyone group for a given resource.
Note: This setting has no impact on domain controllers. An unauthorized user could anonymously list account names and use the information to attempt to guess passwords or perform social engineering attacks. Social engineering is a hacker term for tricking people into revealing their password or some form of security information. |
Enabled |
|
Domain controller: Allow server operators to schedule tasks |
This setting determines if server operators are allowed to submit jobs by means of the AT schedule facility. Note: This security option only affects the AT schedule facility; it does not affect the Task Scheduler facility. Enabling this setting means that jobs created by server operators via the AT service will execute in the context of the account that is running that service. By default, that is the local SYSTEM account. This means that server operators could perform tasks that SYSTEM is able to do, but that they would normally not be able to do, such as add their account to the local Administrators group. |
Disabled |
|
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 security setting determines who is can install a printer driver as part of adding a network printer. Enabling this setting allows only Administrators and Power Users to install a printer driver as part of adding a network printer. Disabling this setting allows any user to install a printer driver as part of adding a network printer. This setting prevents unprivileged users from downloading and installing an untrusted printer driver. |
Enabled |
|
Network access: Remotely accessible registry paths |
N/A |
System/CurrentControlSet/Control/ProductOptions
System/CurrentControlSet/Control/Server Applications
Software/Microsoft/Windows NT/CurrentVersion
|
|
Network access: Remotely accessible registry paths and sub-paths |
The Network access: Remotely accessible registry paths setting determines which registry paths will be accessible after referencing the WinReg key to determine access permissions to those paths. The registry is a database for computer configuration information, much of which is sensitive. An attacker could use this to facilitate unauthorized activities. To reduce the risk of this happening, suitable ACLs are assigned throughout the registry to help protect it from access by unauthorized users. |
System/CurrentControlSet/Control/Print/Printers
System/CurrentControlSet/Services/Eventlog
Software/Microsoft/OLAP Server
Software/Microsoft/Windows NT/CurrentVersion/Print
Software/Microsoft/Windows NT/CurrentVersion/Windows
System/CurrentControlSet/Control/ContentIndex
System/CurrentControlSet/Control/Terminal Server
System/CurrentControlSet/Control/Terminal Server/UserConfig
System/CurrentControlSet/Control/Terminal Server/DefaultUserConfiguration
Software/Microsoft/Windows NT/CurrentVersion/Perflib
System/CurrentControlSet/Services/SysmonLog
|
|
System objects: Require case insensitivity for non-Windows subsystems |
N/A |
Enabled |
|
Shutdown: Clear virtual memory pagefile |
The Shutdown: Clear virtual memory page file setting determines whether the virtual memory page file is cleared when the system is shut down. Virtual memory support uses a system page file to swap pages of memory to disk when they are not used. On a running system, this page file is opened exclusively by the operating system, and it is well protected. However, systems configured to allow booting to other operating systems might have to make sure that the system page file is wiped clean when this system shuts down. This ensures that sensitive information from process memory that might go into the page file is not available to an unauthorized user who manages to directly access the page file.
When this setting is enabled, it clears the system page file upon clean shutdown. Enabling this security option will force the system to also zero out the hibernation file, hiberfil.sys, out when hibernation is disabled on a portable computer system.
Important information kept in real memory may be written periodically to the page file. This helps Windows Server 2003 handle multitasking functions. An attacker who has physical access to a server that has been shut down could view the contents of the paging file. The attacker would move the system volume into a different computer and then analyze the contents of the paging file. This is a time consuming process, but it could expose data cached from random access memory (RAM) to the paging file.
Caution: An attacker who has physical access to the server could bypass this countermeasure by simply unplugging the server from its power source.
Set the Clear virtual memory page file when system shuts down to Enabled. Enabling this setting causes Windows Server 2003 to clear the page file when the system is shut down, removing all information stored in this file. Depending on the size of the page file, this process could take several minutes before the system completely shuts down. |
Disabled |
|
System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links) |
The System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links) setting determines the strength of the default DACL for objects. Windows maintains a global list of shared system resources, such as MS – DOS device names, mutexes, and semaphores. In this way, objects can be located and shared among processes.
This setting determines the strength of the default DACL for objects. Windows Server 2003 maintains a global list of shared system resources such as MS – DOS device names, mutexes, and semaphores.
In this way, 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. Enabling this setting strengthens the default DACL, allowing non – administrator users to read shared objects, but not to modify shared objects that they did not create.
Set Strengthen default permissions of global system objects (for example, Symbolic Links) to Enabled. |
Enabled |
|
System settings: Optional subsystems |
The System settings: Optional subsystems security setting determines which subsystems support your applications. With this security setting, you can specify as many support subsystems as your environment demands.
The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The POSIX Subsystem is required if the server supports applications that use that subsystem.
The subsystem introduces a security risk relating to processes that can potentially persist across logins. That is, if a user starts a process and then logs out, there is a potential that the next user who logs in to the system could access the previous user's process. This is dangerous because the process started by the first user may retain that users system privileges; anything the second user does with that process will be performed with the privileges of the first user.
Set the System settings: Optional subsystems setting to a null value. The default value is POSIX. |
Posix
|
|
Microsoft network server: Amount of idle time required before suspending session |
The Microsoft network server: Amount of idle time required before suspending session security setting determines the amount of continuous idle time that must pass in a SMB session before the session is suspended due to inactivity. Administrators can use this setting to control when a computer suspends an inactive SMB session. The session automatically re – establishes when client activity resumes.
For this setting setting, a value of 0 means to disconnect an idle session as quickly as is reasonably possible. The maximum value is 99999, which is 208 days; in effect, this value disables the setting. |
15 minutes |
|
Microsoft network server: Disconnect clients when logon hours expire |
The Microsoft network server: Disconnect clients when logon hours expire security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the SMB component. Enabling this setting causes client sessions with the SMB service to be forcibly disconnected when the client's logon hours expire. Disabling this setting maintains an established client session after the client's logon hours have expired. When enabling this setting you should also enable Network security: Force logoff when logon hours expire. If your organization has configured logon hours for users, then it makes sense to enable this setting, otherwise, users who are assumed to be unable to access 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. |
Enabled |
|
Microsoft network server: Digitally sign communications (if client agrees) |
There are four separate settings relating to digitally signing Server Message Block (SMB) communications: Microsoft Network Client: Digitally Sign Communications (Always), Microsoft Network Server: Digitally Sign Communications (Always), Microsoft Network Client: Digitally Sign Communications (If Server Agrees), and Microsoft Network Server: Digitally Sign Communications (If Client Agrees). Implementing digital signing in high security networks helps to prevent the impersonation of clients and servers. This type of impersonation is known as session hijacking — in which session hijacking tools are used to allow an attacker who had access to the same network as the client or server could interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets 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 a legitimate authentication and gain unauthorized access to data. |
Disabled |
|
Network access: Named Pipes that can be accessed anonymously |
The Network access: Named Pipes that can be accessed anonymously setting determines which communication sessions, or pipes, will have attributes and permissions that allow anonymous access. Restricting access over named pipes such as COMNAP and LOCATOR helps prevent unauthorized access to the network. Set Network access: Named Pipes that can be accessed anonymously to a null value, that is, enable the setting but do not enter named pipes in the text box. |
COMNAP
COMNODE
SQL/QUERY
SPOOLSS
NETLOGON
LSARPC
SAMR
BROWSER
|
|
Network access: Shares that can be accessed anonymously |
The Network access: Shares that can be accessed anonymously setting determines which network shares anonymous users can access. Enabling this setting is very dangerous. Any shares listed can be accessed by any network user. This could lead to the exposure or corruption of sensitive corporate data.
Set Network access: Shares that can be accessed anonymously to a null value. |
COMCFG
DFS$
|
|
Microsoft network server: Digitally sign communications (always) |
There are four separate settings relating to digitally signing Server Message Block (SMB) communications: Microsoft Network Client: Digitally Sign Communications (Always), Microsoft Network Server: Digitally Sign Communications (Always), Microsoft Network Client: Digitally Sign Communications (If Server Agrees), and Microsoft Network Server: Digitally Sign Communications (If Client Agrees). Implementing digital signing in high security networks helps to prevent the impersonation of clients and servers. This type of impersonation is known as session hijacking — in which session hijacking tools are used to allow an attacker who had access to the same network as the client or server could interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets 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 a legitimate authentication and gain unauthorized access to data. |
Disabled |
|
Network access: Restrict anonymous access to Named Pipes and Shares |
When enabled, the Network access: Restrict anonymous access to Named Pipes and Shares security setting restricts anonymous access to shares and pipes to the settings for Network access: Named pipes that can be accessed anonymously and Network access: Shares that can be accessed anonymously. This 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, is a registry value that toggles null session shares on or off to determine whether the server service restricts access to client's logged on to the system account without user name and password authentication. Null sessions are a weakness that can be exploited through the various shares that are on the computers in your environment. |
Enabled |
|
Microsoft network client: Send unencrypted password to third-party SMB servers |
Enabling the Microsoft network client: Send unencrypted password to third – party SMB servers security setting allows the SMB redirector to send plaintext passwords to non – Microsoft SMB servers that do not support password encryption during authentication. Enabling this setting allows the server could to transmit passwords in plaintext across the network to other systems offering SMB services. These others systems may not utilize any of the SMB security mechanisms included with Windows Server 2003. |
Disabled |
|
Microsoft network client: Digitally sign communications (if server agrees) |
There are four separate settings relating to digitally signing Server Message Block (SMB) communications: Microsoft Network Client: Digitally Sign Communications (Always), Microsoft Network Server: Digitally Sign Communications (Always), Microsoft Network Client: Digitally Sign Communications (If Server Agrees), and Microsoft Network Server: Digitally Sign Communications (If Client Agrees). Implementing digital signing in high security networks helps to prevent the impersonation of clients and servers. This type of impersonation is known as session hijacking — in which session hijacking tools are used to allow an attacker who had access to the same network as the client or server could interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets 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 a legitimate authentication and gain unauthorized access to data. |
Enabled |
|
Microsoft network client: Digitally sign communications (always) |
There are four separate settings relating to digitally signing Server Message Block (SMB) communications: Microsoft Network Client: Digitally Sign Communications (Always), Microsoft Network Server: Digitally Sign Communications (Always), Microsoft Network Client: Digitally Sign Communications (If Server Agrees), and Microsoft Network Server: Digitally Sign Communications (If Client Agrees). Implementing digital signing in high security networks helps to prevent the impersonation of clients and servers. This type of impersonation is known as session hijacking — in which session hijacking tools are used to allow an attacker who had access to the same network as the client or server could interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned SMB packets 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 a legitimate authentication and gain unauthorized access to data. |
Disabled |
|
Network security: LDAP client signing requirements |
The Network security: LDAP client signing requirements security setting determines the level of data signing that is requested on behalf of clients issuing LDAP BIND requests, as follows:
None: The LDAP BIND request is issued with the caller – specified options.
Negotiate signing: If Transport Layer Security/Secure Sockets Layer (TLS/SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller – specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller – specified options.
Require signature: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed. Unsigned network traffic is susceptible to man – in – the – middle attacks, where an intruder captures the packets between the client and server and modifies them before forwarding them to the server. In the case of an LDAP server, this means that an attacker could cause a server to make decisions based on false queries from the LDAP client. You can lower this risk in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, all types of man – in – the – middle attacks can be made extremely difficult by requiring digital signatures on all network packets via IPSec authentication headers.
Set Domain controller: LDAP server signing requirements to Require signature. |
Negotiate signing |
|
Domain member: Disable machine account password changes |
This setting determines whether a domain member periodically changes its computer account password. Enabling this setting prevents the domain member from changing its computer account password. Disabling this setting allows the domain member to change its computer account password as specified by the setting for Domain Member: Maximum age for computer account password, which is every thirty days by default. The default configuration for computers running Windows Server 2003 that belong to a domain is that they are automatically required to change the passwords for their accounts every thirty days. Disabling this feature causes computers running Windows Server 2003 to retain the same passwords as their computer accounts. Computers that are no longer able to automatically change their account password are in risk of an attacker determining the password for the system's domain account. |
Disabled |
|
Domain member: Maximum machine account password age |
The Domain member: Maximum machine account password age 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.
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 thirty days. Increasing this interval significantly, or setting it to 0 so that the computers no longer change their passwords, gives an attacker more time to undertake a brute force password guessing attack against one of the computer accounts. |
30 days |
|
Domain controller: Refuse machine account password changes |
This setting determines whether or not a Domain Controller will accept password change requests for computer accounts. Enabling this setting on all domain controllers in a domain prevents domain members from changing their computer account passwords. This, in turn, leaves those passwords susceptible to attack. |
Disabled |
|
Domain member: Digitally encrypt or sign secure channel data (always) |
N/A |
Enabled |
|
Domain member: Require strong (Windows 2000 or later) session key |
This setting determines whether a secure channel can be established with a domain controller that is not capable of encrypting secure channel traffic with a strong, 128 – bit, session key. Enabling this setting prevents establishing a secure channel with any domain controller that cannot encrypt secure channel data with a strong key. Disabling this setting allows 64 – bit session keys. |
Disabled |
|
Domain member: Digitally encrypt secure channel data (when possible) |
N/A |
Enabled |
|
Domain member: Digitally sign secure channel data (when possible) |
N/A |
Enabled |
|
Domain controller: LDAP server signing requirements |
This setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
Unsigned network traffic is susceptible to man – in – the – middle attacks where an intruder captures packets between the server and the client and modifies them before forwarding them to the client. In the case of an LDAP server, this means that an attacker could cause a client to make decisions based on false records from the LDAP directory. You can lower the risk of an attacker pulling this off in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPSec) authentication header mode (AH), which performs mutual authentication and packet integrity for Internet Protocol (IP) traffic, can make all types of man – in – the – middle attacks extremely difficult. |
Negotiate signing |
 |
Accounts: Administrator account status |
This setting enables or disables the Administrator account under normal operation. Under safe mode boot, the Administrator account is always enabled, regardless of this setting. For some organizations periodically changing the password for local accounts can be a daunting management challenge, therefore they may want to disable the built – in Administrator account. Another reason to consider disabling this built – in account is that by default it cannot be locked out no matter how many failed logons it accrues. This makes it a prime target for brute force, password – guessing attacks. Additionally, this account has a well – known security identifier (SID) and there are third – party tools that allow you authenticate over the network by specifying the SID rather than the account name. This means that even if you have renamed the Administrator account an attacker could launch a brute force attack using the SID. |
Not defined |
|
Accounts: Guest account status |
This setting determines if the Guest account is enabled or disabled. This account allows unauthenticated network users to gain access to the system by logging in as Guest with no password. Unauthorized users could access any resources that are accessible to the Guest account over the network. This means that any network shares with permissions allowing access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This could lead to the exposure or corruption of data. |
Not defined |
|
Accounts: Rename administrator account |
This setting determines whether a different account name is associated with the SID for the Administrator account. Because the Administrator account exists on all Windows 2000, Windows Server 2003, and Windows XP Professional computers, renaming the account makes it slightly more difficult for unauthorized persons to guess this privileged user name and password combination. By default, the built – in Administrator account cannot be locked – out no matter how many times an attacker might use a bad password This makes the Administrator account a popular target for brute force password – guessing attacks. The value of this countermeasure is lessened because this account has a well – known SID and there are third – party tools that allow you initiate a brute force attack over the network by specifying the SID rather than the account name. This means that even if you have renamed the Administrator account, an attacker could launch a brute force attacking using the SID. |
Not defined |
|
Accounts: Rename guest account |
This setting determines whether a different account name is associated with the SID for the Guest account. Because the Guest account exists on all Windows 2000, Windows Server 2003, and Windows XP Professional computers, renaming the Guest account makes it slightly more difficult for unauthorized persons to guess this privileged user name and password combination. |
Not defined |
|
Network access: Allow anonymous SID/Name translation |
The Network access: Allow anonymous SID/Name translation security setting determines whether an anonymous user can request SID attributes for another user. If this setting is enabled, a user could use the well – known Administrators SID to get the real name of the built – in Administrator name, even if the account has been renamed. That person could then use the account name to initiate a password guessing attack. |
Not defined |
|
and sub-paths |
N/A |
Not defined |
|
Network security: Force logoff when logon hours expire |
The Force logoff when logon hours expire setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the SMB component. Enabling this setting forcibly disconnects client sessions with the SMB server when the client's logon hours expire. Disabling this setting maintains an established client session after the client's logon hours have expired. If this setting is disabled a user could remain connected to the system outside of their allotted logon hours. |
Not defined |
|
System cryptography: Use FIPS compliant algorithms for encryption |
N/A |
Not defined |
