What would you say if I told that it was possible to accidentally write changes up to domain-based GPOs by simply making local security policy changes on your Domain Controllers?

I was emailed recently by a fellow techie, who was seeing some odd behavior at a site that he worked at. What was happening is that they had installed some vendor product on their domain controllers, and when they did the install, their Group Policy auditing solution was detecting changes happening to the Default Domain Controllers Policy GPO (say what?). Now, the changes were not attributed to a particular user, but instead were coming from the LocalSystem account. This had them scratching their heads. They knew that the vendor product needed to grant the “Deny Logon Locally” user right to an account on each DC (don’t ask me why) but beyond that there was no explanation as to why the domain GPO was being modified–certainly the vendor product wasn’t doing it…or was it?

This email triggered a deep-seated memory, filed away in my brain many years ago, but nonetheless still waiting there to be extracted. Indeed, the vendor product was responsible for the change to the Default Domain Controllers GPO and in fact, it is possible for changes made to security policy locally on a DC, to be “automagically” written up to either the Default Domain Policy or Default Domain Controllers Policy. Let’s see when and how that happens.

Conformity At All Costs

The first thing to understand about this behavior, is that it’s been in Windows for a long time. While I don’t have proof at the moment, I recall it’s likely been in the box since Windows 2000 and certainly since 2003. The second thing to understand is that I haven’t really found a good Microsoft article describing this “feature”, although I’m pretty sure there’s one out there because I do recall seeing it documented at some point in the past. So what is it? Well, as you know, domain controllers are multi-master replicas of each other. Any given DC can serve up authentication, authorization and other services to any client equally. And, Group Policy is the way that we configure DCs, especially around domain-wide security policy. Microsoft has told us that there are a couple of truths to security policy and DCs. First, that account policy (e.g. password, Kerberos policy, etc.) must be set at a GPO linked at the domain level. Now, this is usually in the system-provided “Default Domain Policy” but it could be in any policy. In addition, we know that other settings, like user rights, security options, etc. should be set on the equally built-in “Default Domain Controllers Policy”, so that it applies to all DCs found in the Domain Controllers OU. So far so good. But, what would happen if you decided that you wanted to have different security policy on one DC than another, by say, security filtering a bunch of Domain Controller OU-linked GPOs so that each GPO was processed by a different DC? Chaos! You couldn’t predict what security policy would apply to a client because it would all depend upon which DC they hit. Not good. So Microsoft baked into the domain controller’s “brain”, this need to conform. If a DC encounters a local security policy setting that’s different than the corresponding one found in the Default Domain Policy or Default Domain Controllers Policy, it says, “well, that’s not good–I need this to apply to all my brethren”. So, the DC, or a process running on it, will write those local settings up to either of those two built-in GPOs! That’s right. The DC decides it knows better than you when it comes to it’s own security policy, and wants to guarantee that everyone is on the same page.

You may wonder if this is happening with all security policy or just specific areas. In my testing, I’ve found the following policy areas seem to exhibit this “write-back” behavior:

Computer Configuration\Policies\Windows Settings\Security Settings\Account Policy

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies

This includes basic stuff like password policy, as well as security delegation areas such as user rights assignment and security options.

Implementing the “Feature”

If you don’t believe that this behavior exists (I sure didn’t believe it was possible the first time I saw it), you can duplicate it yourself. The first thing to note is that it is not a simple matter of opening the local GPO Editor, and making changes to local security policy on a given DC. The GP Editor tool actually prevents you from making changes to local security policy that has been set by a domain-based GPO, as shown here:

Security settings in the local GPO are greyed out if being set at the domain level.

But there are other ways to affect change to the local security policy outside of GP editor. In the simplest case, the good old command-line net.exe command can make changes to password policy. For example, if I run the following command on a DC:

net accounts /minpwlen:9

This will change the minimum password length policy to 9 characters. But since it’s being run on a domain controller, the DC then writes this new value back up to the Default Domain Policy GPO, which is, by default, responsible for setting account policy on the domain. Crazy, huh?

The second way you can affect local security policy changes is to create custom security templates and use secedit.exe to apply them. This involves loading up the “Security Templates MMC snap-in” and setting some local security settings within a custom template, as shown here:

Using the MMC Security Templates snap-in to define custom local security policy

In this example above, I’m modifying the “Deny Logon Locally” user right to add a new group to it. I can then apply this policy change on the DC using secedit.exe as follows:

SECEDIT /configure /db secedit.sdb /cfg "c:\userrights.inf”

Now that I’ve applied these settings to user rights, they’ll be written back up to, in this case, the Default Domain Controllers Policy, overwriting any previous definition for “Deny Logon Locally” that may have been set there (not a good thing).

Beware of Ghosts

Now that you’re aware of this behavior, what do you do about it? Well, certainly, you want to avoid having it happen in the first place! As in the case of this customer, having a good Group Policy change auditing solution in place, such as our GP Auditing & Attestation (GPAA) product, will help alert you when these things happen. But educating your admins and your vendors is also a good idea, since all of these changes necessarily impact an entire domain! It’s best to try to first avoid the ghosts, and if they show up, be quick about sending them away before they do real damage! Ghostbusters anyone?

Darren