Simon,
By default there is a security group called Authenticated Users that has
both the READ and APPLY GROUP POLICY rights. This group includes user
account objects and computer account objects. So, any user account object
or computer account object that resides directly in the OU to which the GPO
is linked will be able to read the GPO and apply the GPO ( assuming that a
couple other things are correct ).
So, there are a couple ways to do this. You could make use of something
called Group Filtering ( a bit more advanced in the whole GPO thing ) and
create a security group that contains all of the user account objects that
you want to be affected by this Policy, remove the Authenticated Users from
the Security Tab and then replace it with the one that you just created.
Just make sure to give it the READ and APPLY GROUP POLICY rights. Then,
only those user account objects that are members of this security group will
be affected by this Policy ( well, so as to avoid any confusion - they must
still directly reside in the OU - and this is paramount.....we have simply
removed the default security group *Authenticated Users* on the security tab
of the policy and replaced it with this one.. ).
The other way is to leave the Policy as is and make the one change - to add
that particular user account object and to give it the DENY on the APPLY
GROUP POLICY. Better would be to create a security group ( call it 'No
policy' or whatnot ) and make this particular user account object a member
of this security group and then apply the DENY to this security group.
A quick digression: one of the confusing parts of 'Group' Policy is that
Groups really do not play a role. A lot of people who are starting think
that you can apply policies to groups. This is incorrect. You link a
policy at one of four levels - the Local level, the Site-level, the
Domain-level and the OU-level. Most people find that the OU-level is most
commonly used ( but by all means not the only! ). When you create a Group
Policy ( which effectively happens after you click on New... and give it a
friendly name - like 'No access to CD-ROM Drive' ) a couple of things
happen: you have created the GPT ( Group Policy Template ) half as well as
the GPC ( Group Policy Container ) half. The GPT is the part that you will
find in the shared SYSVOL and the GPC is the part that lives in Active
Directory. All of this is done, by default, on the DC that holds the FSMO
Role of PDC Emulator. Also, when you do this you are linking the Policy to
the level at which you are creating it! So, if you create an OU and move
all of your user account objects in it and then right click that OU and
select Properties and go to the Group Policy tab and click on New... then
you create the Policy ( which is alive and well and can be linked to
multiple 'locations' ) and a link is created for that Policy to that
specific OU ( it is the gPOLink value ). So, you see that security groups
do not really have anything to do with Policies, necessarily! We *can* use
security groups for this group filtering, though!
HTH,
Cary
