2 Local Policies
2.3 Security Options
2.3.5 Domain controller
Page 155
2.3.5.1 (L1) Ensure 'Domain controller: Allow server operators to schedule tasks' is set to 'Disabled' (DC only) (Automated)
Profile Applicability:
• Level 1 - Domain Controller Description:
This policy setting determines whether members of the Server Operators group are allowed to submit jobs by means of the AT schedule facility. The impact of this policy setting configuration should be small for most organizations. Users, including those in the Server Operators group, will still be able to create jobs by means of the Task Scheduler Wizard, but those jobs will run in the context of the account with which the user authenticates when they set up the job.
Note: An AT Service Account can be modified to select a different account rather than the LOCAL SYSTEM account. To change the account, open System Tools, click
Scheduled Tasks, and then click Accessories folder. Then click AT Service Account on the Advanced menu.
The recommended state for this setting is: Disabled. Rationale:
If you enable this policy setting, jobs that are created by server operators by means of the AT service will execute in the context of the account that runs that service. By default, that is the local SYSTEM account. If you enable this policy setting, server operators could perform tasks that SYSTEM is able to do but that they would typically not be able to do, such as add their account to the local Administrators group.
Impact:
None - this is the default behavior. Note that users (including those in the Server Operators group) are still able to create jobs by means of the Task Scheduler Wizard.
However, those jobs will run in the context of the account that the user authenticates with when setting up the job.
Audit:
Navigate to the UI Path articulated in the Remediation section and confirm it is set as prescribed. This group policy setting is backed by the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa:SubmitControl
Remediation:
To establish the recommended configuration via GP, set the following UI path to
Disabled:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Domain controller: Allow server operators to schedule tasks
Default Value:
Disabled. (Server Operators are not allowed to submit jobs by means of the AT schedule facility.)
Page 157
2.3.5.2 (L1) Ensure 'Domain controller: Allow vulnerable Netlogon secure channel connections' is set to 'Not Configured' (DC Only) (Automated)
Profile Applicability:
• Level 1 - Domain Controller Description:
This security setting determines whether the domain controller bypasses secure RPC for Netlogon secure channel connections for specified machine accounts.
When deployed, this policy should be applied to all domain controllers in a forest by enabling the policy on the domain controllers OU.
When the Create Vulnerable Connections list (allow list) is configured:
• Given allow permission, the domain controller will allow accounts to use a Netlogon secure channel without secure RPC.
• Given deny permission, the domain controller will require accounts to use a Netlogon secure channel with secure RPC which is the same as the default (not necessary).
Note: Warning from Microsoft - enabling this policy will expose your domain-joined devices and can expose your Active Directory forest to risk. This policy should be used as a temporary measure for 3rd-party devices as you deploy updates. Once a 3rd-party device is updated to support using secure RPC with Netlogon secure channels, the account should be removed from the Create Vulnerable Connections list. To better understand the risk of configuring accounts to be allowed to use vulnerable Netlogon secure channel connections, please visit How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472.
The recommended state for this setting is: Not Configured. Rationale:
Enabling this policy will expose your domain-joined devices and can expose your Active Directory forest to security risks. It is highly recommended that this setting not be used (i.e. be left completely unconfigured) so as not to add risk.
Impact:
None - this is the default behavior.
Audit:
Navigate to the UI Path articulated in the Remediation section and confirm it is set as prescribed. This group policy setting is backed by the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters:Vuln erableChannelAllowList
Note: If this policy is set as prescribed, the registry key vulnerablechannelallowlist, will not be present in the above registry location.
Remediation:
To establish the recommended configuration via GP, set the following UI path to Not Configured:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Domain controller: Allow vulnerable Netlogon secure channel connections
Default Value:
Not Configured. (No machines or trust accounts are explicitly exempt from secure RPC with Netlogon secure channel connections enforcement.)
References:
1. https://go.microsoft.com/fwlink/?linkid=2133485
Page 159
2.3.5.3 (L1) Ensure 'Domain controller: LDAP server channel binding token requirements' is set to 'Always' (DC Only)
(Automated)
Profile Applicability:
• Level 1 - Domain Controller Description:
This setting determines whether the LDAP server (Domain Controller) enforces validation of Channel Binding Tokens (CBT) received in LDAP bind requests that are sent over SSL/TLS (i.e. LDAPS).
The recommended state for this setting is: Always.
Note: All LDAP clients must have the CVC-2017-8563 security update to be compatible with Domain Controllers that have this setting enabled. More information on this setting is available at: MSKB 4520412: 2020 LDAP channel binding and LDAP signing
requirements for Windows Rationale:
Requiring Channel Binding Tokens (CBT) can prevent an attacker who is able to capture users' authentication credentials (e.g. OAuth tokens, session identifiers, etc.) from reusing those credentials in another TLS session. This also helps to increase protection against "man-in-the-middle" attacks using LDAP authentication over SSL/TLS (LDAPS).
Impact:
All LDAP clients must provide channel binding information over SSL/TLS (i.e. LDAPS).
The LDAP server (Domain Controller) rejects authentication requests from clients that do not do so. Clients must have the CVC-2017-8563 security update to support this feature, and may have compatibility issues with this setting without the security update.
This may also mean that LDAP authentication requests over SSL/TLS that previously worked may stop working until the security update is installed.
When first deploying this setting, you may initially want to only set it to the alternate setting of When supported (instead of Always) on all Domain Controllers. This alternate, interim setting enables support for LDAP client channel binding but does not require it.
Then set one DC that is not currently being targeted by LDAP clients to Always, and test each of the critical LDAP clients against that DC (and remediating as necessary), before deploying Always to the rest of the DCs.
We also recommend using the new Event ID 3039 on your Domain Controllers (added with the March 2020 security update) to help locate clients that do not use Channel Binding Tokens (CBT) in their LDAPS connections. This new Event ID requires increasing the logging level of the 16 LDAP Interface Events portion of the NTDS service diagnostics to a value of 2 (Basic). For more information, please see Table 2:
CBT events at this link: MSKB 4520412: 2020 LDAP channel binding and LDAP signing requirements for Windows
Older OSes such as Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 (non-R2), will first require patches for Microsoft Security Advisory 973811, as well as all associated fixes, in order to be compatible with domain controllers that have this setting deployed.
Note: Only Always is actually considered compliant to the CIS benchmark.
Audit:
Navigate to the UI Path articulated in the Remediation section and confirm it is set as prescribed. This group policy setting is backed by the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters:LdapEnfo rceChannelBinding
Remediation:
To establish the recommended configuration via GP, set the following UI path to Always:
Computer Configuration\Policies\Windows Settings\Security Settings\Local
Page 161
Default Value:
Never. (No LDAP channel binding validation is performed.) CIS Controls:
Controls
Version Control IG 1 IG 2 IG 3
v8 3.10 Encrypt Sensitive Data in Transit
Encrypt sensitive data in transit. Example implementations can include:
Transport Layer Security (TLS) and Open Secure Shell (OpenSSH).
● ●
v7
16.5 Encrypt Transmittal of Username and Authentication Credentials
Ensure that all account usernames and authentication credentials are transmitted across networks using encrypted channels.
● ●
2.3.5.4 (L1) Ensure 'Domain controller: LDAP server signing requirements' is set to 'Require signing' (DC only) (Automated)
Profile Applicability:
• Level 1 - Domain Controller Description:
This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
The recommended state for this setting is: Require signing.
Note: Domain member computers must have Network security: LDAP signing
requirements (Rule 2.3.11.8) set to Negotiate signing or higher. If not, they will fail to authenticate once the above Require signing value is configured on the Domain Controllers. Fortunately, Negotiate signing is the default in the client configuration.
Note #2: This policy setting does not have any impact on LDAP simple bind (ldap_simple_bind) or LDAP simple bind through SSL (ldap_simple_bind_s). No Microsoft LDAP clients that are shipped with Windows XP Professional use LDAP simple bind or LDAP simple bind through SSL to talk to a Domain Controller.
Note #3: Before enabling this setting, you should first ensure that there are no clients (including server-based applications) that are configured to authenticate with Active Directory via unsigned LDAP, because changing this setting will break those
applications. Such applications should first be reconfigured to use signed LDAP, Secure LDAP (LDAPS), or IPsec-protected connections. For more information on how to
identify whether your DCs are being accessed via unsigned LDAP (and where those accesses are coming from), see this Microsoft TechNet blog article: Identifying Clear Text LDAP binds to your DC’s – Practical Windows Security
Rationale:
Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client, modifies them, and then forwards them to the client. Where LDAP servers are concerned, an attacker could cause a client to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement strong physical security measures to protect the network infrastructure. Also, you could implement Internet Protocol security (IPsec) authentication header mode
Page 163
Impact:
Unless TLS/SSL is being used, the LDAP data signing option must be negotiated.
Clients that do not support LDAP signing will be unable to run LDAP queries against the Domain Controllers. All Windows 2000-based computers in your organization that are managed from Windows Server 2003-based or Windows XP-based computers and that use Windows NT Challenge/Response (NTLM) authentication must have Windows 2000 Service Pack 3 (SP3) installed. Alternatively, these clients must have a registry change. For information about this registry change, see Microsoft Knowledge Base article 325465: Windows 2000 domain controllers require SP3 or later when using Windows Server 2003 administration tools. Also, some non-Microsoft operating systems do not support LDAP signing. If you enable this policy setting, client computers that use those operating systems may be unable to access domain resources.
Audit:
Navigate to the UI Path articulated in the Remediation section and confirm it is set as prescribed. This group policy setting is backed by the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters:LDAPServ erIntegrity
Remediation:
To establish the recommended configuration via GP, set the following UI path to
Require signing:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Domain controller: LDAP server signing requirements
Default Value:
None. (Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.)
CIS Controls:
Controls
Version Control IG 1 IG 2 IG 3
v8 3.10 Encrypt Sensitive Data in Transit
Encrypt sensitive data in transit. Example implementations can include:
Transport Layer Security (TLS) and Open Secure Shell (OpenSSH).
● ●
2.3.5.5 (L1) Ensure 'Domain controller: Refuse machine account password changes' is set to 'Disabled' (DC only) (Automated)
Profile Applicability:
• Level 1 - Domain Controller Description:
This security setting determines whether Domain Controllers will refuse requests from member computers to change computer account passwords.
The recommended state for this setting is: Disabled.
Note: Some problems can occur as a result of machine account password expiration, particularly if a machine is reverted to a previous point-in-time state, as is common with virtual machines. Depending on how far back the reversion is, the older machine
account password stored on the machine may no longer be recognized by the domain controllers, and therefore the computer loses its domain trust. This can also disrupt non- persistent VDI implementations, and devices with write filters that disallow permanent changes to the OS volume. Some organizations may choose to exempt themselves from this recommendation and disable machine account password expiration for these situations.
Rationale:
If you enable this policy setting on all Domain Controllers in a domain, domain members will not be able to change their computer account passwords, and those passwords will be more susceptible to attack.
Impact:
None - this is the default behavior.
Audit:
Navigate to the UI Path articulated in the Remediation section and confirm it is set as prescribed. This group policy setting is backed by the following registry location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters:Refu sePasswordChange
Page 165
Remediation:
To establish the recommended configuration via GP, set the following UI path to
Disabled:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Domain controller: Refuse machine account password changes
Default Value:
Disabled. (By default, member computers change their computer account passwords as specified by the Domain member: Maximum machine account password age setting (Rule 2.3.6.5), which is by default every 30 days.)
CIS Controls:
Controls
Version Control IG 1 IG 2 IG 3
v8
4.1 Establish and Maintain a Secure Configuration Process
Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile, non-computing/IoT devices, and servers) and software (operating systems and applications). Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
● ● ●
v7 5.1 Establish Secure Configurations
Maintain documented, standard security configuration standards for all authorized operating systems and software.