GPO Hardening: Most Important GPO Settings

Hardening IT systems is an important topic in cybersecurity. Many companies that are new to it are confronted with security incidents. Oneconsult’s Incident Response Team is dedicated to helping organizations manage such incidents.

Hardening with GPO

In numerous incidents and customer projects, we have identified various challenges in system hardening. There is often a lack of resources to review and adapt the multitude of guidelines, tips, and standards. In addition, infrastructure has often grown without hardening. This makes it difficult to implement hardening measures quickly and effectively, as it almost always leads to service disruptions.

This article presents a summary of the most important GPO (Group Policy Object) settings from an IT security perspective. These settings represent a summary of the most important hardening measures from personal practical experience that anyone can or should distribute via GPO. The possible effects that the corresponding policies could have are also discussed. As a general rule, nothing should be implemented without first being tested. Test environments are best suited for this purpose. A subset of devices and servers that are not too critical can also be used. One advantage of Group Policy Objects is that they can be quickly removed in the event of undesirable behavior. However, this requires identifying the specific settings that caused the undesired outcome.

UAC

The UAC (User Account Control) primarily protects privileged user accounts. In some instances, it has been discovered that the UAC has been completely deactivated for administrators during a cyber incident. This resulted in malware launched by an admin being able to spread unrestrictedly on the system and usually beyond. The UAC prevents programs with elevated permissions from starting by default by requesting confirmation or password re-entry. In addition, the UAC can prevent lateral movement (spreading in the network) under certain circumstances, as it does not allow connections from local administrators via the network. However, this can only be achieved if the UAC is configured correctly.

The following recommended settings for User Account Control can be configured in “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: [various settings]”:

Setting	Value
User Account Control: Admin Approval Mode for the Built-in Administrator account	Enabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations	Enabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode	Prompt for consent on the secure desktop
User Account Control: Behavior of the elevation prompt for standard users	Automatically deny elevation requests
User Account Control: Detect application installations and prompt for elevation	Depending on use case *
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop	Disabled
User Account Control: Run all administrators in Admin Approval Mode	Enabled
User Account Control: Switch to the secure desktop when prompting for elevation	Enabled
User Account Control: Virtualize file and registry write failures to per-user locations	Enabled

* See: Microsoft, User Account Control: Detect application installations and prompt for elevation

LDAP Signing

When LDAP signing is enabled, all LDAP packets are transmitted with a digital signature. This enables the recipient of the LDAP packets to verify that the communication is taking place with the intended location. A client can therefore confirm whether the LDAP responses originate from the domain controller and have not been altered, and vice versa. This renders replay attacks in particular more challenging, whereby a cyber attacker attempts to reuse old, recorded communication. Man-in-the-middle attacks, whereby an attacker intervenes in the communication between the client and server, also become more difficult.

Furthermore, “LDAP Channel Binding Token” should be used. This increases security when authenticating to the Active Directory via LDAPs.

Possible negative effects may occur in particular with older systems that are not capable of handling LDAP signing. Domain users can no longer log on to such systems, and services can no longer function or start correctly if they were started under a domain account. In order to ascertain whether such systems exist within the network, a log can be configured, which is capable of recognizing and reporting simple LDAP requests. To do this, the following value must be set in the registry on the domain controller under the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics:

• “16 LDAP Interface Events”, value: 2

This means that the event ID 2889 is displayed in the Event Viewer if a client does not support LDAP signing.

For channel tokens, OS versions such as Windows Server 2008 or older versions do not support LDAP signing. However, updates for the 2008 line have been developed, which retrofit the function.

The recommended setting for server and client:

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements
  • Set to: Require signing

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LDAP client signing requirements
  • Set to: Require signing

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server channel binding token requirements
  • Set to: Always

SMB Signing

In essence, SMB signing has the same objective as LDAP signing. Its purpose is to prevent cybercriminals from accessing the communication between client and server or reusing the recorded communication for an attack. Again, issues may arise if legacy systems lack the capacity to support SMB signing. Another potential problem is related to performance. With standard 1GB Ethernet and a modern CPU, users are unlikely to perceive any significant impact. However, if a 10GB line with a correspondingly high throughput is used, the performance losses resulting from SMB signing may become discernible.

The recommended settings for servers and clients:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network client: Digitally sign communications (always)
  • Set to: Enabled

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network server: Digitally sign communications (always)
  • Set to: Enabled

Alternatively, the following setting could be preferred if at least partially unsigned communication is required:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options >Microsoft network client: Digitally sign communications (if server agrees)
  • Set to: Enabled

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options >Microsoft network server: Digitally sign communications (if client agrees)
  • Set to: Enabled

SChannel Signing

The SChannel (Secure Channel) is employed in instances where domain controllers replicate with each other and when they communicate with clients. This occurs when security-relevant processes, such as authentication, are carried out.

To prevent cyberattacks, communication can be transmitted in encrypted and/or signed form. As with SMB signing, there is also the option here to only use encryption and/or signing if this is possible. Old operating systems or non-Microsoft clients may not be able to communicate with the domain controller or the desired service if the setting is forced.

The following setting is recommended:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain member: Digitally encrypt or sign secure channel data (always)
  • Set to: Enabled

Alternative setting:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain member: Digitally encrypt or sign secure channel data (if client agrees)
  • Set to: Enabled

NTLMv2 Without Old Protocols

In a domain, Kerberos is the default authentication protocol. However, in certain cases, this is not a viable option or is not utilized due to an incorrect configuration. In such cases, LM (LAN Manager), NTLM (New Technology LAN Manager) or NTLMv2 (New Technology LAN Manager Version 2) are employed. NTLMv2 has been supported natively since Windows 2000. The older protocols, especially LM, have inherent weaknesses in their design, which is why it is not recommended to continue using them. As NTLMv2 is widespread and has been supported for a long time, there should be no significant implementation issues.

The following setting is recommended:

• Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level
  • Set to: Send NTLMv2 responses only. Refuse LM & NTLM

Remove CPasswords

Passwords can be stored in the Group Policy Preferences (GPPs). GPPs are the part of the GPOs where drive mappings, file copies, environment variable settings etc. but also users and passwords can be created. Passwords stored in the Group Policy can be accessed by an attacker. Although the secrets are not available in plain text, the key that Microsoft has programmed in to protect the data is generally known. In the majority of cases, there are alternative solutions to achieve the desired outcome without the necessity of storing a password in the GPPs.

A pervasive issue is the management of local administrators on the servers and clients. Frequently, the same password is utilized everywhere by default, or a user is created via GPP, which leads to the same result. It would be more optimal to manage local administrators using LAPS (Local Admin Password Solution), a tool developed by Microsoft for precisely this purpose. LAPS can be used to control via GPO which local admin account is to be managed according to the rules that can also be defined. The client will generate a password for the corresponding account and write it to a new field of the respective computer object on the domain controller. Only domain administrators can read this field. In this way, each local administrator account receives its own secure password. When used, a domain admin can read the password from the Active Directory, most easily via PowerShell.

To use LAPS, it is necessary to install the management tools on the AD server, as well as a schema extension for the new fields and new GPO templates. A GPO extension is installed on the clients. The next time the policies are synchronized, the client will read and implement the LAPS settings.

The exact installation instructions and documentation are available from Microsoft: Microsoft LAPS

Oneconsult advises against the storage of passwords in the GPPs and GPOs, and instead recommends the implementation of an alternative solution.

Password Policy

The Internet offers a plethora of resources on the subject of password policies. However, these resources do not always refer to the same initial situation. For instance, it is recommended that no complexity requirements be placed on user passwords, but that they are checked against a blacklist that is as comprehensive as possible. On an on-premises domain controller, passwords cannot be checked against a blacklist. In a cloud, on the other hand, such new approaches can be followed. In some instances, the recommendations are intended for a web store or other websites and do not align with the requirements and conditions of an Active Directory environment. Caution should also be exercised if only individual points from a recommendation are selected for implementation. This approach can weaken the password policy.

The CIS (Center for Internet Security) Password Policy Guide provides a comprehensive overview. It provides a clear and concise explanation of the potential risks associated with password security and offers guidance on how to mitigate these risks. Contrary to the CIS password policy, Oneconsult recommends a password length of at least 10 characters instead of 8 for normal users (with 2FA).

Remote Credential Guard

In modern environments with Windows 10 and Server 2016 or higher, Remote Credential Guard can be activated for RDP connections. When connecting to the RDP host, the credentials or parts thereof are no longer sent to the host, which would store them locally in the cache. This prevents an attacker who has managed to compromise a host from accessing other user accounts just because they connect to the system. Remote Credential Guard is particularly useful in scenarios where support is provided via RDP, or RDP is also used for connections to DMZ servers.

Microsoft has documented how Remote Credential Guard can be set up and which requirements must be met: Remote Credential Guard.

If Microsoft’s requirements are met and the use of Credential Guard is tested before it is rolled out, no problems should arise. It is important to study the Microsoft documentation carefully during implementation to ensure that all conditions are met.

Switch on NLA

If NLA (Network Level Authentication) is used, authentication for RDP takes place at the time of connection establishment rather than subsequently. A connection is only established if the user is able to log in successfully. Consequently, attackers and viruses are less able to exploit security vulnerabilities and cannot gain unauthorized access to information that is also available before a login (such as logged-in users). For example, the BlueKeep computer worm attack could be prevented using NLA. Problems during implementation should only occur in the rarest of cases.. NLA has been supported since Windows XP SP3 and Server 2008. It should be noted that users who need to change their password cannot log in as usual via RDP and then change their password. The connection will fail when using NLA. Furthermore, authentication with a smartcard is not possible for cross-domain connections.

The following setting is recommended:

• Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication
  • Set to: Enabled

Log Size of the “Security Log”

The default setting for the security log size especially on domain controllers is often insufficient. In the event of an incident, it is not uncommon to find that the log data available for review is limited to a period of two to four hours. Even smaller companies accumulate a significant volume of log data on the domain controller, which is overwritten when the set log size is reached. The optimal size for the security log depends on the specific company, its requirements, and the audit policy in place. A potential initial step would be to ensure that the log data from the security log is available on all servers and clients for a period of three months.

The following procedure is therefore recommended:

1. Open the security log, note the current size.
2. Search for the oldest available log entry.
3. Use the rule of three to work out how big the log would have to be to reach at least three months into the past.
4. Set the estimated log size via GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Security: Specify the maximum log file size (KB)
5. After three months, check whether the date of the oldest log entry corresponds to the expectation.

Enable PowerShell Script Block Logging

PowerShell is a powerful tool that is often used by both admins as well as attackers. To ascertain which user executed which command or script and at what time, all executed commands need to be logged. Problems or attacks in which PowerShell plays a role can thus be detected and traced.

PowerShell Script Block Logging can be set via GPO:

• Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on PowerShell Script Block Logging
  • Set to Enabled and select “Log script block invocation start/stop events”.

Create Audit Policy

In many incidents, it has been observed that, in addition to the brief storage period of log data, the available data is also relatively sparse. To resolve a cyber incident, a multitude of logs must often be consulted and correlated. A considerable proportion of possible log data is not recorded by default under Windows and must first be configured. It is therefore recommended that companies first consider what they wish to know. It may be helpful to consider whether the answers to the following questions could be relevant:

• Who has logged in when and where?
• Who accessed the important company secrets on the SMB share and when?
• Who made what changes in the Active Directory?
• What PowerShell commands were executed?
• What processes were started? When and by whom?

A simple evaluation, a SIEM (Security Information and Event Management) or even a SOC (Security Operation Center) can later be set up based on the audit policy. There is no right or wrong when it comes to the settings. It is a balance between what one wants to know and the size of the log or the number of log entries, which can reach considerable proportions. The only potential harm that could be caused would be a lack of consideration and failure to recognize the importance of log data altogether. It is not necessary to implement a SOC at the outset. In the case of incidents, forensic experts and incident responders are content with the mere availability of log data.

The various setting options can be found under the following path:

• Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies

• This document provides a good introduction: WINDOWS LOGGING CHEAT SHEET – Win 7 thru Win 2019

Prohibit Users From Adding New Devices to the Active Directory

It is important to note that, by default, each user can add up to five devices to the domain with their normal domain user account. Adding new devices to the domain is not a privilege of domain administrators unless it is configured that way. The new devices added by users will rarely comply with the company’s security strategy. For example, they will not be covered by the central administration of the anti-virus program, may not have active BitLocker encryption, or may already be infected with viruses.

Adding new devices to the domain can only be allowed for administrators:

• Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment Add workstations to domain
  • Set to: Administrators

Further Sources and Measures

There is a wealth of information on the Internet regarding the subject of hardening via GPO. The following three resources are frequently used at Oneconsult:

• CIS Benchmarks
• Microsoft Security Baselines
• Another blog post by the author explaining how to effectively manage and activate the Windows Firewall via GPO: Configuring Protective Windows Firewall

The following resources are recommended on the subject of Active Directory, the heart of almost every company:

• Improve the Security of Your Own Active Directory (AD), a Oneconsult blog post about a self-audit option that is both timely and cost-effective in delivering the relevant results, along with guidance on how to improve the security of the Active Directory.
• Oneconsult’s Protecting Active Directory Training, which covers the basics, explains how attackers proceed, and teaches how to prevent and recognize attacks.

Further Settings

In addition to the settings mentioned in the previous chapters, the following measures should be mentioned, which cannot be set directly or only via GPO. Nevertheless, they are part of the basics in the hardening process.

Deactivate LLMNR and NetBIOS

LLMNR (Link-Local Multicast Name Resolution) and NetBIOS are protocols for name resolution in ad hoc networks where no DNS server is used. Queries via LLMNR or NetBIOS are sent to the entire network. Responses are not checked for authenticity. Attackers can exploit this mechanism by eavesdropping on such queries and forging responses – thus tricking the victim into trusting malicious servers.

If LLMNR and NetBIOS are not used, the protocols should be deactivated:

• Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client > Turn Off Multicast Name Resolution
  • Set to: Enabled

NetBIOS cannot be deactivated easily via GPO. It must be switched off for each adapter. This is particularly useful for servers where the adapter does not change. The following setting is made in the registry:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\ <ID>\NetbiosOptions
  • Set to: 2

Deactivate WPAD

WPAD (Web Proxy Autodiscovery) is a protocol for automatic proxy configuration. Depending on the network, it can facilitate man-in-the-middle attacks. On servers that are usually installed in static networks, the proxy can be configured permanently and WPAD can be switched off. WPAD should also be deactivated on clients that do not require the function.

WPAD should be deactivated on servers and clients that do not require it:

• In the Control Panel, “Automatically detect settings” must be set to “Off” in the proxy settings.
• The following registry key must also be set:
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc
  • Value of “Start” from 3 (manual) to 4 (deactivated)

Conclusion

The most effective hardening of systems is achieved when the IT security concept is integrated into the processes from the outset, rather than being introduced at the end or after the occurrence of a cyber incident. When new clients, services, and servers are being rolled out and set up, IT security should already play a role in the design phase. The presence of security requirements from the beginning of the process reduces the likelihood of any issues during implementation. The GPOs mentioned above can serve as a foundation for achieving a basic level of hardening. It should be noted that hardening systems is not limited to GPOs; there are also countless policy settings that can enhance the security of a network and have not been covered here. By following the provided links, a wealth of useful information and tools can be accessed to help secure clients, servers, and the entire environment.