In my previous post I talked about security policy and its tattooing ways. But how about a scenario where a policy should not have tattooed, and did? That was the situation when I got an email from someone about a policy that was tattooing their systems. The situation was, they had created a custom ADM file that set a registry value under the policy keys, which should get removed when the policy is removed. Let’s say it was set under HKLMSoftwarePoliciesMyapp1. They then needed to update the app and also the ADM file to make changes to HKLMSoftwarePoliciesMyapp2. So they removed the original ADM from the GPO that had delivered this setting and added the new one. And low and behold, after applying the new policy to the GPO their target systems had both settings! Why?
Well, let’s think about the way that this works. The ADM file basically lets you set a registry policy for a particular registry key and value. Its your window into the underlying registry.pol file, which stores the actual registry settings in the GPO. When that user removed the first ADM, they were only removing that window into the setting–the setting itself was not removed from the GPO and so as long as the GPO was applying to that system, so was the old setting. They added the new ADM file, enabled the new registry location and Voila!–registry settings in both the old and new locations.
The moral of that story is, when you need to retire a policy setting, you have two choices. Either set the policy setting to not configured and then remove the ADM. Or, remove the GPO altogether so that the policy no longer applies to the target.
In the next blog on this topic, I’ll talk about how a similiar thing can affect machines that you remove from the domain, that end up having policy settings tattooed all over them…
Tag: