Filtering GPO's Based on Computer Account Security Group

Question

So, I have a GPO, which runs a quick start up script to delete locally installed IP printers from all machines on our AD domain during computer start up. This works great...the issue appears when we try to exempt a few machines from this (a few small offices without print servers.)

I have created a global security group, and put the computer accounts (since this is a startup, not a login script) into the group. I then set permissions on the GPO to deny access to that group. For some reason, this has no effect. It also has no effect if I set deny permissions for that group on the script itself.

Interestingly, though, if I cut out the group, and set deny permissions on the GPO or script for the computer account directly, permissions are denied properly.

These issues persist across multiple "gpupdate /force" commands, as well as reboots.

Am I missing something about how computer accounts group group sids? Why are the group based deny permissions not working?

Solution 1

I do what you're looking at doing all the time. When you say "I then set permissions on the GPO to deny access to that group" it's not clear what you're doing. Here's my workflow for denying a group the rights to apply a GPO:

• Create Global Security Group "Computers exempt from printer deletion"
• Open Group Policy Management, locate the GPO to delete printers, and "Edit" the GPO
• Right-click the top-level node in the Group Policy Object Editor console, move to the "Security" tab, add the "Computers exempt from printer deletion" to the permission, and set the permission for the "Computers exempt from printer deletion" group to include "Apply Group Policy" with "Deny" permission

The permission editor within the Group Policy Management console is inferior to the Group Policy Object Editor. You don't see the actual ACL in Group Policy Management unless you click the "Advanced" button on the "Delegation" tab. I'm "old school" and got used to modifying GPO permissions back in the days before the Group Policy Management console, so I still go about it the way I described above. Now get off my lawn! >smile<

If you're concerned that the computer isn't "picking up" its group memberships execute a "whoami /all" as SYSTEM on the machine and review the output. That'll show you what the computer's security token actually includes. I have not had experiences with computers not "recognizing" group memberships.

Solution 2

Group Policy Filtering: You're doing it wrong (or at the very least you're doing it the hard way).

1. Create a Security group for the computers that you DO want the policy to apply to.

2. Add the appropriate computer accounts to the group.

3. On the Scope tab of the GPO, in the Security Filtering section, remove all entities and add the Security group you created in step 1.

4. Done.

Solution 3

I am not really sure, because I have no way to test here, but as far i remember you will not be able to put computers in groups and deny the group. You should put each computer and deny each one....

Maybe you can find something using GPP.

Comments

[HopelessN00b]

I then set permissions on the GPO to deny access to that group. Wait, what? Explain that, please.

[woodsbw]

Group policy objects have permissions, just like everything else....see the "Delegation" tab while the GPO is selected...then checkout the "Advanced" button. Works quite well with group filtering for users.

[HopelessN00b]

Yes, I'm aware of that, but it's not much of an explanation. How do you think you're denying permissions?

[woodsbw]

It should (and does, with user polices) prevent the policy from applying to the machines in the group with "denied" permissions...and it is not.

[jscott]

What does gpresult /R show? You can update your question with the relevant output.

[SamErde]

Sorry to ask the obvious, but did you add a Deny ACE for the "Read" AND the "Apply" permissions?

[woodsbw]

I'm going to have to disagree. Groups to exempt from policies make far more sense when you have policies that only a dozen or so of 700 users or machines need to be exempted from. Doing small exemptions the way you suggest would mean that every new user or machine would have to be added to a dozen groups just to get company base-line policy. That being said, this still doesn't address the question at hand...which is the fact that the machine doesn't seem to get it's group memberships correctly on start-up.

[joeqwerty]

I'll have to respectfully agree to disagree. Whitelisting (which is what my method is) is more reliable, predictable and easier to troubleshoot then blacklisting (which is what your method is), IMO.

[woodsbw]

Well, regardless, it doesn't explain why the machine isn't getting it's group memberships?

[Spence]

@joeqwerty: I must voice disagreement with you re: "whitelisting" being more "reliable" than blacklisting. ACLs are processed in a deterministic manner. Neither "flavor" will parse more "reliably" than the other and the end result is the same. My issue w/ "whitelisting" versus "blacklisting" is exactly what woodsbw says-- you end up having computers (or users) being members of more groups than they really need to be. My take on this is that the design that ultimately results in the least group memberships is the best because that keeps security tokens smaller for the typical case.

[Spence]

-1 - You absolutely can use groups to deny computers access to objects (GPOs, files, etc).

[SamErde]

Using GPP with item level targeting still isn't a bad idea.

[woodsbw]

No it is't a bad idea...I love GPP and item-level targeting. But, it won't do the dynamic printer deletions that I need, in this case. A script is the only way to go.

[woodsbw]

How do I best run whoami as system? I cannot do a simple "runas" to system, can I?

[Spence]

@woodsbw: I'm immediately suspicious that the test machine has stopped updating Group Policy for some reason and is using a cached instruction to execute that script. Setting permissions on the script itself would definitely stop the execution. (I frequently assign multiple startup scripts in a single GPO and use permissions on the script files to limit execution. That generates errors in the event log, though, so I can't say it's the best idea.) re: a SYSTEM command promit - Use PSEXEC - psexec -i -s cmd.exe

[woodsbw]

I was worried you would mention psexec. I will need to do some modifications to get that working (admin shares totally disabled by policy.) I'll get back to you.

[woodsbw]

Thanks for your help Evan! It looks like everything is now working!

[Spence]

Glad I could help.