1

I was wondering if someone could confirm me if the following GPO behavior is normal/expected:

Situation: in an organization they have put all users in the default Users container
(Active Directory).

The users have been put in various security groups, according their function.

They then have created a GPO to map a network drive. They attached the GPO to the root off the domain, but limited the range of the GPO to a specific security group, which does contain some members.

This seems to work. (Users of the security group get the mapped drive, others don’t).

I personally prefer putting users in OU’s according their department. When applying a GPO to map a network drive. I would create the GPO, but attach it to the OU of the users and let the GPO apply to all authenticated users.

This also seems to work.

But what doesn’t seem to work here is combining both ways described above: put users in an OU, attach a GPO and limit the reach of the GPO to a security containing the same members.

For example: put all members for marketing in an OU ‘Marketing’, put the same members in a security group called ‘Marketing’. Create a GPO which does map a network drive. Attach the the GPO to the OU ‘Marketing’ and set the reach of the GPO to the security group ‘Marketing’

Can both ways be combined or is it way 1 or way 2 ?

7 Spice ups
2 
Can both ways be combined or is it way 1 or way 2 ?

both forms can be used, but when you use them together, both conditions must be valid before the GPO can be applied.

1 Spice up
3

For starters, take everybody out of the default containers and build out an OU structure. You can’t directly link GPO’s to the built-in containers so you’re missing out on a lot of flexibility.

Secondly, applying GPO’s against groups and OU’s are both good options but ultimately I always suggest applying generally to OU’s and then fine-tuning with groups (if necessary).

4 Spice ups
4

Generally speaking, the preferred method is to apply the GPO’s to OU wherever possible

However there is always the odd occasion where you need to apply security filtering by Group.

I would say it’s unusual to apply all GPO’s at root level and only use security groups - have they moved the user accounts out of the default USER’s OU - that may explain the reason, as you can’t apply GPO’s to the default OU’s

5

Hi

Usually you link your GPO’s to your OU’s and it’s inherited to Sub-OU’s (you can also break inheritance - but better not)

Then you have filtering options (WMI) or you can also target gpo to a specific group or even user …

A lot of options, but as @dimforest ​ suggests - create a tree of OU’s with some common sense (by location or department etc.) and apply the GPO accordingly …

Regards

1 Spice up
6

Hi thanks all for the answers.

It’s a legacy situation I’m dealing with where (almost) all users are in the default user container. Thinking about it now, I would think they (whoever did this in the past) didn’t know which users should be in which OU or didn’t bother creating a proper OU structure and therefore attached the GPO to the root of the domain and filtered the GPO by adding the security group.

It’s a nasty situation, which I’ll tackle asap.

At the moment it’s not really clear to me why my combined effort (users in OU, attach GPO to this OU and set the reach of the GPO to security group) didn’t work, but it’s good to know that it can be done and that an OU structure is the way to go.

Thanks all, most kind off you

7

As stated above, both ways work. I find OU’s easier as you can visually see things grouped together pretty much instantly. As also stated above, if you use both, both have ot agree for the GPO to be applied. As also stated above, you lose a ton of flexibility leaving everyone in the default user group (which you cannot apply GPOs directly to).

8

Group Policy Objects do not apply to groups. They can, however, be filtered by them. Policies apply to User or Computer objects.

If you are having trouble filtering by User Groups make sure Authenticated Users still has a read delegation. Newer MS clients use the Computer object to read the GPO now not the User object as a security enhancement.

Any new group you create, the user will have to re-log to get their new group membership as that is processed during login.

OUs, as the others stated, should match your business and the organization it needs to succeed, however that may look.

However, for anything Using Group Policy Preferences like shortcuts and drive maps, I would urge you to use Item Level Targeting rather than security filtering.

This will allow you to combine all your drive maps into one GPO and target who gets what via targeting. Cutting down the number of GPOs the system needs to process during login or updates.

gpp3.png
gpp3.png800×490 94 KB
1 Spice up
9

As a rule of thumb, I try to link a GPO to an OU first. If the policy is for certain users in that OU, link the GPO to the OU and then setup a security group for those users. I use a combination of policies applying to OUs and policies applying to security groups. Where I work mapped drives and printers would fall under security groups because not everyone needs the same printers or drives at each location.

I agree with what was mentioned above. Don’t use the default groups folder. Build out your structure how you see fit. Whether that’s creating a Users and Computers OU and having different departments or locations in both or you want departments or locations at the top level and then a users and computers OU under each department or location.