Overview
Hardening a domain controller (DC) via “Local Security Policy” changes can lead to changes in “Default Domain Controllers Policy” and “Default Domain Policy”. An analysis and overview.
Symptom
During hardening an IT infrastructure, in concrete several domain controllers, the following happened after updating an existing hardening configuration:
-
- Hardening configuration was updated to include recommendations based on more recent version of CIS benchmarks
- The updated hardening configuration included changes to setting “SeDebugPrivilege” (set in „user rights assignment“)
- This new configuration was applied to a DC holding none of the famous FSMO roles (especially not the PDC emulator role)
- “Computer version” of Default Domain Controllers policies (DDCP) started increasing without any explicit changes to the DDCP
-
- After research the following assumption was made: Those locally applied changes must be the root cause for an increasing version number
Default Domain Controllers Policy
When hardening a DC, Local Security Policy is changed with many settings. All these local changes are written into the Default Domain Controllers Policy, if set on the DC with the PDC-Role. Microsoft describes this as a needed feature for synchronization (see screenshot below). Moreover, if those changes overwrite the Default Domain Controllers policy by setting local changes to the PDC at first. As soon as hardening started on a second DC with different settings, those are also written into the DDCP.
As configuration was applied using “PowerShell Desired State Configuration” (DSC) this led to an infinite change to the policy as both DCs try to overwrite the settings every time DSC (or in concrete the “Local Configuration Manager) checked a deviation and repaired it.
Default Domain Policy
This is unfortunately also true for local changes to the Password Policy for example. However, these changes are written into the Default Domain Policy and in all cases lead to changes to all systems. For this “Feature”, there is no solution planned, as this works as designed if going by Microsoft documentation. But there is a workaround which can help preventing the described “Feature”.
Summary
All this research and discussion leads to 3 different cases:
Case: A DC is hardened and none of the settings are changed which are delivered via Default Domain Controller Policy / Default Domain Policy
Result: None of above mentioned problems occur, as those local settings will not be written in the default policies
Case: A DC is hardened with changes to settings which are delivered via the Default Domain Controller Policy / Default Domain Policy
Result: These local settings will overwrite the settings in the policies. This will lead to a one-time change of policy and the loss of already defined settings.
Case: A DC is hardened with local settings which are delivered via the Default Domain Controller Policy / Default Domain Policy. Additionally another DC is hardened again with different local settings (for example applying an updated hardening configuration).
Result: Both DCs will overwrite the Default Domain Controller Policy / Default Domain Policy settings every time PowerShell DSC checks for deviations in mode „ApplyAndAutoCorrect“. This leads to infinite changes to the Policies if a workaround is not done.
(Workaround) solution
1. Use a copy of Default Domain Controller Policy
Like Microsoft “best practice” Default Domain Controller Policy should not be changed. However, if already changes were made to the policy itself, create a copy of it.
After copying unlink Default Domain Controller Policy and link the copy:
The Copy will not be affected by changes to Local Policies and local changes will stay local.
2. Use a copy of Default Domain Policy
Microsoft “best practice” also refers to use Default Domain Policy unchanged. The same procedure can also be done here, create a copy and link it afterwards.
Unlink Default Domain Policy and link the copy:
This copy will also not be affected by changes to „local policies“ and local changes will stay local.