Where does a Domain Controller's Local Security Policy come from?

Question

In Group Policy we have the Deny logon through Remote Desktop setting enabled for the Domain Computers group . I promoted a computer that was a member of this group to be a Domain Controller. After the promotion and computer was of course no longer a member of the Domain Computers group, but:

1. The Deny logon through Remote Desktop setting was still in effect
2. The setting was not listed in Group Policy results

I eventually found out you can edit the setting in the Local Security Policy MMC, but now I am worried because:

1. You cannot easily determine whether the value has been changed from the default because the settings in Local Security Policy do not have the Define these policy settings box
2. Remote auditing is difficult because the settings don't show up in Group Policy Results

Does anyone know any workarounds for this behavior? If none are available, is there an easy way to audit these settings?

Answer 1

Domain Controllers have their own local security policies, just like regular domain members do. Group Policies will also take precedence/override local security policies, just as they do on regular domain members.

As you have witnessed, there are plenty of Group Policy settings that have the ability to "tattoo," or leave their mark on a system's local security policy even after the GPO no longer applies to the computer. Group Policies that do not tattoo a system after the GPO no longer applies generally modify settings under a special "Policies" subkey in the Windows registry. Most Group Policies are well behaved and follow this pattern, but not all of them.

The first obvious solution to manage configuration settings in a domain environment is, if you care about a setting, set it in Group Policy so that it will override any local policy settings.

Another possible solution would be to create and apply Security Templates with the Security Configuration and Analysis tool (mmc snap-in.) I don't see the advantage of doing this over simply defining your baseline configuration settings via Group Policy, but that's the tool to use if you want to apply consistent templates to the local security policies of many machines.

Most admins only promote computers with a known good security configuration to be domain controllers, so yours is not a very common problem.

For auditing, running gpresult /h policy.html will generate an HTML report that lists all the effective policy settings, including a merging of both Group Policies and Local Policies. So if a computer has a modified Local Policy setting, and no Group Policy overrides it, it will show up there:

From TechNet:

All settings applied through local policy or a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database, then the setting does not revert to anything and remains defined as is. This behavior is sometimes called "tattooing."