Data Centers

Windows security groups: To nest or not?

For administrators who work with Active Directory, there is an opinion on whether or not to nest global security groups. IT pro Rick Vanover explains the cons and limited pros of this practice.

There are few things more important than troubleshooting a permissions issue only to find that a nested global security group is the culprit. The nesting of global security groups can cause so many issues, especially when any deny permissions come into play. Take into account any group policy-based deny permissions, and the tracing effort can be quite cumbersome.

For Active Directory domains, do you allow nested global security groups? The troubleshooting aspect of group membership is made complicated at first glance in most tools. Many tools will report effective rights, but not necessarily that they are there because of a nested group, much less a group membership at all.

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:

  1. Allow no more than one level of nested group membership.
  2. One security group can have no more than one “member of” value.
  3. The nested security group would not contain groups designated for deny permissions.
  4. The nested global security group is not a high-level privilege group.

These are basic situations, but may not address every use case for a valid use case for nesting a global security group. The guiding principle in these parameters is that it is kept to a minimum, does not increase the troubleshooting burden, and reduces the risk of accidental over-permission assignments. Limiting the use of nested groups also will help prevent issues related to token size problems.

One of the best use cases is the occasional situation where you need to add a computer account to a global security group; it becomes awkward if user accounts and computer accounts are intermixed in the same security group. Another use case is when the Built-In groups (from local computer systems) are being combined with domain user accounts as a way to separate them. Nesting can make sense in those situations as well as others that may arise in your specific configuration.

Do you use any level of nested security groups? If so, share how and when you use them below.

About

Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

23 comments
dpeter
dpeter

Confused - yes - I have a top level folder (lets say) Accounting I have a security accounting group that has permission to modify I have another security group call ALL (same as authenticated users) but has read only. If a user is in both security groups which permissions do they actually get? The read only or modify access?

Craig_B
Craig_B

In general, I create a Domain Local Group, assign it the permission to the resource, then create Security Groups based on the resource and/or Organization. These Security groups are then made members of the DLG. For Folder permission we try to keep things at the top layers, that is you don't want some folder changing permission 10 subfolders below the main level. The place I use Deny is in GPOs, sometimes it's easier to Deny some groups there, with certain GPOs.

Lazarus439
Lazarus439

I started networks admin with NetWare 3.11/3.12 and actually got my employer to pay for a couple of real classes (unheard of at the time). The instructor dutifully covered Deny, but also recommended very strongly against ever using because it can give rise to no end of problems that can be nearly impossible to track down. As a result, I've never used Deny and never missed doing so. As soon as we kill off our last W2K DC (Yep, we still have one), we're going to bump the domain level up enough to allow nesting security groups. Nesting security groups is like any other tool: very handy when used in appropriate places.

PhilM
PhilM

eDirectory is easier to manage. Awaiting flack.

jdayman
jdayman

I think I'd have to disagree with your basic premise Rick. Nested groups are very useful and an important part of a well managed enterprise network. We already use nested groups in our Active Directory(single Domain, approximately 10,000 users and 3,000 computers, K-12 school division)and we'll be expanding their use in the future. I'll agree with you that the native tools in Microsoft Windows do not make it easy to manage nested groups - that's where you might have to step up and add some third party tools or do some basic scripting to extend the native tools in Windows Server. As to why nested groups are necessary - I think it's the best way to achieve "Role Based Administration", where everything about a user, a computer or a server is based on it's role within the organization. For us it means that if (for example) a student or teacher transfers from one school to another we can just make a single change to the account's group membership. From that can flow all the necessary permission changes, software deployments, etc. Same if a teacher is promoted to an Administrative position - change the account's membership from "Teachers" to "Principals" and everything else can happen automatically based on nested group memberships. By far the best explanation I've seen for how this can work, and the reasons why Admins in an Enterprise network should consider doing it this way, - Microsoft's "Windows Server 2008 Resource Kit", specifically the book "Windows Administration - Productivity Solutions for IT Professionals". The author is Dan Holme and anybody who manages a large Windows network should really take the time to read this book! (And no - I'm not related to the author nor am I affiliated with Microsoft and plugging the resource kit for that reason. I've always thought the documentation that comes with the Resource Kits is highly useful. With the Server 2008 edition I think Microsoft has produced an absolute gem and I always recommend it as a "must have" resource.)

ylto
ylto

I've been fortunate to be able to deal with relativey uncomplicated security issues over the last couple of decades, but I have one use for the deny right - keeping users from deleting a directory structure where you otherwise want them to have modify rights on everything in the drive or folder. Setting deny on delete and applying it to "this folder only" keeps them from messing things up, especially when a specific directory is required for network scanners to store files in the proper place.

rhino777
rhino777

Not trying to argue but how exactly is eDirectory easier to manage? I can manage AD in my sleep...can't imagine anything being easier than that.

Lazarus439
Lazarus439

Not everyone shares your particular brand of Kool-Aid nor do they recognize you as the source of all (or even any) knowledge about anything, let alone directory systems. You are fully welcome to use the products of your choice; however, your evaluation and selection criteria are not required for use by anyone but you.

paul.willy
paul.willy

Hi J, Everyone I have seen that "Nests" has 3 or 4 times as many groups as they need. Do you use resource groups? My wish would be OUs as security principles, but it will never happen. Just an old DOS guy, Paul

Lazarus439
Lazarus439

Thank you! I've never thought of that use for it but I will now. I appreciate the tip!

b4real
b4real

Let's be realistic, a directory service is to manage user identities and systems. And for most environments, that is a Windows environment. I side with Rhino777

PhilM
PhilM

Abolutely agree with you. But I'm happy using what one considers the best and wanted to share the love.

jdayman
jdayman

Hey old DOS guy! I'm a little bit old school myself! (First online experience was at a DOS command line, accessing my Compuserve account. Good times. Good times.) You've nailed it - we end up with a TON of groups. But I don't see that as a bad thing necessarily. Take a look at Dan Holme's book which I referenced in my original post if you get a chance. Note how he extends the native Windows management tools so that all those groups become a benefit, not a liability. Think in terms of automatically being able to audit resource access and rights - who can do what to which AD objects. That sort of thing. Jayson

DosMaster
DosMaster

Sounds like 2 guys who have never used eDirectory . . . Well, have you? and.. "for most environments, that is a Windows environment" - this is called "herd mentality"

rhino777
rhino777

What's wrong with assigning rights to an OU?

rhino777
rhino777

Security is obviously an important concern but how many times have you actually heard of someone stealing a physical server and using it to hack someone's NOS? Also, if you're that concerned about security then you'd want to invest in physical security so the server couldn't be stolen.

paul.willy
paul.willy

Hi Chug, Microsoft is getting there. A Read Only Domain Controller does have a limited set of passwords, and if it is stolen, when you delete the AD object, it prompts you to let it reset all the user and computer passwords it stored. Did you like Wan Traffic Manager? AD Sites is soooooo much easier, AD doesn't need partitions. Just and old DOS guy, Paul

tsadowski
tsadowski

So if you desire to, or are required to, use Outlook/Exchange, you have no choice but to use the inferior Active Directory. It is either that or maintain two separate directories, one for E-mail and the other for everything else.

Craig_B
Craig_B

I have to agree Novell eDirictory was and still is better than Microsoft Active Directory, of course AD has become the standard. One big feature concerning rights was that they could be assigned to the OU. Chug already mentioned the better replication options. The better technology does not always win, especially when non-technical people make the decisions.

Chug
Chug

Totally agree, eDirectory was WAY better. I can't tell you how many times I would be in some Microsoft seminar talking about the new version of Windows Server (back to Win 2000, then 2003, then 2008) where the MS guy would announce some new feature of Active Directory. Everybody in the room would ooohh and aaahhh over the announcement and I'm thinking "You people know nothing. Novell has had that feature for years already." It still floors me that Active Directory doesn't allow partition replicas the way eDirectory does. Server 2008 FINALLY introduced some sort of feature (I forget exactly what it is) where you could pick and choose what ended up on replica, but it's still no where near as easy to use or flexible as the partition replicas are in eDirectory. Our Corporate security people won't allow AD replicas in our remote sites because of the fact that each replica contains the ENTIRE AD tree and they don't want to risk that somebody could break into that remote server, or steal the entire physical server, and get access to our AD database. With eDirectory, each server contained ONLY the part of the eDirectory tree that pertained to that site. Unfortunately our company dumped Novell about 4 years ago. Yes, I'm still bitter about it. :)

ghopkins
ghopkins

I have used both for 15 years, and by far Edirectory is the best. Perhaps MS could adapt theirs to N. The best of both worlds. Play together! Thats the Key

Juanita Marquez
Juanita Marquez

is being able to keep things organized. If you are able to do so without major mishap, fantastic. If not, then the simpler the better, I suppose. I think it is interesting that an organization I worked at with 800 users had a very detailed nesting structure and it worked well; the organization that I'm currently at has 2x the number of users and it is relatively bare-bones. Obviously that works for them as well. My preference was the more detailed nesting, but I'm also quite in favor of automation wherever possible when it comes to specific user groups and rights. As far as DOS, I've spent my time there, back when 128k was really something. I couldn't tell you many commands though, I gleefully accepted GUI whenever it manifested itself.

Editor's Picks