Serving the Exchange & Active Directory market since 1997, Imanami's 500+ customers give a great view of who is using AD for what.  That's what we blog about.

Twitter RSS Twitter flickr

Imanami GroupID

Active Directory Whitepaper DownloadFree 30 Day TrialGroupID Free Trial

Exciting New Video!

accurate AD group.

Get all the latest via email!

Your email:
Loading

SharePoint or AD groups poll?

SharePoint groups poll

Current Articles | RSS Feed RSS Feed

Nest an Active Directory security group? Do it thoughtfully.

 

I just read a great article by Rick Vanover called,  Windows security groups: To nest or not?  He asks the question because a nested security can be a bear to troubleshoot if you start getting quirky permissions issues.

In the article Rick states, "I would love to say that nesting group membership is prohibited, but there are occasional situations where it makes sense. My professional administration practice has limited nested group membership with a few guiding rules"

nested groups in active directoryAnd this makes sense, there are very valid reasons to nest Active Directory groups but you need to make sure you have controls in place to keep it from getting out of control.  Having the guidelines in place is helpful but if you have mutliple admins or help desk personnel working in ADUC (and many many companies have this situation), these rules can get overlooked.

For GroupID Self Service, we have created a help desk role that gives help desk permissions to manage user and group objects with controls in place as to what they can change, create, expire or delete.  That way you can give them the tools they need to do their job that is more than an end user can do and less than what an Admin can do.

The control that is most pertinent to the nesting issue is our group hijacking workflow.  Basically, if you try to nest a security group or distribution list into another group, the owner of the groug being nested (nestee?) needs to approve it.  That way the group won't start getting unwanted email or suddenly have permissions being applied to it that the group owner doesn't want.

Following smart guidelines like those described in the article AND having the tools in place to help ensure guideline compliance will allow you to have a safely structured nested AD group structure without the troubleshooting nightmare.

Comments

Getting approvals will not solve the problem.  
 
The problem isn't just nesting ... it's also that security groups are used on myriad locations making it difficult to determine who has access to what. 
 
The requirements in an AD design of group membership should be to attain the following: 
1) given a user I can determine every resource that user has access to 
2) given a resource I can determine all users who have access (and what type of access (read/modify/etc) 
3) given a user/resource, I can determine why the user has access 
 
To do this with nesting, follow these rules: 
1) Users go into Role groups 
2) Role Groups may never be used on an ACL 
3) Role Groups are nested into resource groups 
4) resource groups may be used on one and only one resource. 
5) users may be put into resource groups if creation/management of a role group isn't justified 
6) make membership in the role groups automatic based on HR criteria. 
 
This gives visibility to the access, makes audits easier, and does not require additional approval steps for the majority of access given. It also makes it very easy to remove unnecessary access. 
 
The only negatives are that you'll have LOTS of resource groups and creating permissions on new folders takes 2 minutes instead of 1 minute because you create additional groups. 
 
If you have a tool like imanami's, your user management will be easy. For this reason, I'd think that you would highly recommend nested groups. Read the Win2008 Resource kit "Windows Administration" solution collection 1 for the best information on why this is the right approach. 
 
(disclosure, I don't use imanami. We use a home-grown tool that is very similar and we have considered moving to the vendor product)
Posted @ Wednesday, August 25, 2010 1:19 PM by Mark
Mark, 
Thanks for the comment. I'm trying to think of ways that we can make role groups even easier. If you have any ideas that you would like to see, please feel free to email me at edward.killeen@imanami.com . 
 
I will certainly credit you when I blog about this topic!
Posted @ Thursday, August 26, 2010 10:53 AM by Edward Killeen
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics