Thursday, November 7, 2019

Local Group Policy Order of Evaluation Gotcha

It's once again PCI time here at my workplace. While implementing the whitelisting strategy for Windows Apps I described in a previous post, we discovered that while a default state of "Disallowed" blocks things like Notepad from running when you click them in the Start menu, you can still open them either from the Run dialog, or by double-clicking the .exe directly. This is obviously not acceptable from a PCI/whitelisting standpoint, so we had to find some combination of the new Software Restriction Policy (SRP) method and the old User Configuration GPO method to block everything not on the whitelist.

So, we started with our old GPO-based whitelist, and applied the SRP settings on top. To our surprise, when we logged out and back in, we found that while the SRP was blocking apps correctly, it was behaving as if the User GPO was not there at all! Why would this be, when both are turned on at the same time? Does the Computer-level GPO override the User-level GPO?

On a hunch, I tried it the other way around: I started with the SRP settings, then added the User-level GPO on top. This time, it worked! Apps are blocked by the SRP, and .exes are blocked by the User-level GPO.

Why does this happen? These are local GPOs, so the normal Local-Site-Domain-OU precedence rules do not apply as such in this situation. I have not found any documentation describing the order of evaluation/precedence for local GPOs, but it looks like local GPOs are evaluated in the order you create them.

At least in this case. I can't speak for all combinations of GPOs, but if one order doesn't work for you, it may be worth it to try it another way around to see if that makes the precedences line up to do what you want.

No comments:

Post a Comment

Tableau, TabPy, and the Case of No Input Rows

 I haven't scientifically confirmed this or anything, but it sure seems like if you pass an empty dataframe to a TabPy script, then no m...