Nested Security groups not working in AD

I am trying to nest one security group into another so I do not have to add each user manually again to the new group, which from my understanding is supported and actually recommended.  

The project I am doing this for is to give our users a custom desktop depending on which group they are in.  When I add the group to the custom desktop group, the users are not getting the icons in other words they are not showing as though they are in the group.  I tested this by removing the nested group and placing my user in the top group and then the icons show up.

Any ideas on why the nested groups would not work, I can't find anything in google or MS site (big surprise).  I am in a windows 2003 native mode AD environment.

thanks
Brian MarquardtAsked:
Who is Participating?
 
WerewolfTACommented:
Are you perhaps confusing security groups with OU's?  OU's can be nested.  Security groups must have members explicitly added to them.  Group Policies are assigned to OU's.  Security Groups are more for doing things like applying NTFS/Share permissions to a group instead of a bunch of individual users.  

Security Groups are for security, not GPO distribution.  It's the location of the users within the OUs that determines which group policies they get (in this case, desktop settings), not the location of the security groups.  Because a user can only be in one OU, there's a direct logical line between the OU they're in and the domain policies so it's very clear which policies will apply and in what order from which OU's the user's OU is nested in.  On the other hand, a user could be in a bunch of security groups and depending on the location of those groups, could be getting conflicting GPO's applying at essentially the same level (5 down from the domain or whatever) creating a deadlock as to which should apply, so security group membership doesn't determine GPO's received.

If you're wanting a set of users to get certain desktop settings, your best bet would be to place them all in the same OU.  If that's not possible, such as you have HR and Finance users that have very distinct and different GPO requirements, make a GPO that just incorporates the desktop settings and apply to their respective OU's or a sub-OU if it should only affect a subset of each department and move the appropriate users/computers in there.  For all individual GPO's, you should disable either the Computer or User settings if none are being used in that GPO to speed processing.
0
 
Brian MarquardtAuthor Commented:
Nope,

I have a security group (per office) with users from that office in the group.  I also have a custom desktop security group in which users have to be a part of to get the desktop.  I was just trying to add the different branch groups instead off adding each individual user into the custom desktop group.  It seemed to be working sporatically, but we have figured it out to be that the users that it was not working for were taken out of that group and it was not replicated by the time I looked at it.

To many people working on the same problem

thanks for the response
0
 
Brian MarquardtAuthor Commented:
Good reason why people should use a change control log, if they would have put that in our log this would not have been an issue

Ticket Closed
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.