Domain Global groups can only contain user or global group objects from the domain they actually reside within. In other words, if your global group resides within corp.company.com then you can have *only* members that are within the corp.company.com domain. They can be members of local groups in any other domain or universal groups anywhere within the forest though. They also will not allow universal or domain local group memberships.
Thus, if you're going to have a multidomain forest, you will need to make sure that your role-based groups are inside your user domain and that you use those groups to sit in task-based groups (Domain Local groups). If all your DCs are also GCs (which there really is very little reason for them not to be, since you lose a good amount of performance by forcing authentication to go to a DC then to a GC to create a token -- if it can all be done on one machine, save yourself some headache later in life and make all your DCs GCs also).
Universal groups are useful when you have groups that will be utilized to ACL items everywhere in the environment and no matter where the user resides, they will need that membership utilized. All Distribution List groups are automatically Universal, if I recall correctly. Universal groups can only contain users, global groups or universal groups from anywhere in the forest (or outside the forest).
Local groups can have memberships of just about any type of object, no matter where it resides within the forest. However, you can only ACL items in a particular domain with a Domain Local group if that group resides in the same domain as the resource.
There are a few different basic formats for multidomain forests...
User/Exchange domain, resource domain(s). The nice thing about this model is that you only have role-based groups in your User/Exchange domain, so group memberships are relatively low and the Exchange Servers don't have much of a problem with their paged pool memory. You'll usually run into other barriers on your Exchange box before you run out of paged pool memory with this model.
User domain, Exchange domain, Resource domain(s). I'm not really sure why anyone uses this model other than a lack of understanding of how tokens are created. Same as the above example, but you get to buy more DCs and your tokens in Exchange are probably actually larger than they would be in the above example.
Multiple user/resource domains, single Exchange domain. Again, I think that this is another example of people who don't understand token creation.... same reasons as the immediately preceding example. Unless you have a lot of resources being accessed across domains (and cross domain memberships), you're probably just better off with a single forest root/domain structure than wasting money on extra DCs in this model.
Then there is the standard single forest root/domain model that smaller companies go with. This has the wonderful elegance of simplicity. For the mostpart there is little reason to debate between global, universal and local groups other than making sure that you don't create local groups and try to nest them within global groups. For the mostpart, a security group is a security group is a security group in this model. You can ACL items with them and with the exception of nesting, there isn't a whole lot that you can do with one that you can't do with another.
For more information about how a token is created, download the doc at the bottom of the following page:
http://www.microsoft.com/downloads/details.aspx?FamilyID=22dd9251-0781-42e6-9346-89d577a3e74a&DisplayLang=en
For more information on the differences between group types, go to:
http://technet2.microsoft.com/WindowsServer/en/library/79d93e46-ecab-4165-8001-7adc3c9f804e1033.mspx?mfr=true
Going back to the conversations from before though, try and make sure that you actually create a good RBS model and *use* it. There is no reason to create a bunch of global groups for users (a site RBS group set, a job RBS group set, and a hierarchy RBS group set) then not using them and nesting all your users in every other global group you create.
This conversation has gotten probably way more complex than you expected... hehe.
That being said, I also like a combination RBS/ABS model myself. Use role-based groups to create your 'general' access to items and then when people who are outside those basic security groups, add them into ABS security groups for that resource. There are a few problems with this model in that you end up with a *lot* of groups, but the benefit is that your security model is able to adapt to the needs of the environment instead of making the environment adapt to your security model. You don't make your web servers run with IIS turned off because it's a security vulnerability, you just keep them in a DMZ or limit them to not being able to go outside the internal network. Don't make your security model limit your environment either. 10,000 empty groups aren't going to significantly affect your environment and if you have 64-bit DCs, 100,000 (or 1,000,000) empty security groups won't significantly impact your environment, so don't hesitate to have them in place so that if you need them, you can use them instead of running around in circles when you *do* find you need them. Do a little work now and save yourself some work later.... do both, but consider the role-based groups to be the preferred path.
That's what I get for reading my inbox "up"… David: do read my treatise in my earlier email.
But Matt Hargraves response did raise the one technical issue I only alluded to: token size. He's right to raise a 'flag' about Exchange.
Depending on the complexity of your role-based design and whether you use Exchange (2003 or 2000; 2007 seems to be exempt from this issue) and your Exchange architecture, you do have to watch for the number of total groups a user belongs to. A large number of group memberships will reduce the effective 'maximum users per exchange server' level somewhat… but whether that 'somewhat' would be salient depends on several factors.
To "tie together" what Matt discussed and what I proposed, my discussion lays out a design that integrates both RBS and ABS. You definitely want role-based management. Whether you also go to the level I outlined of managing ACLs depends on your environment: more resources; more complex security; and more 'spread out' resources and you'll be better served by the design I described. In a simpler environment (e.g. "we have a departmental share with each department having a subfolder" on the extreme side), you don't necessarily need the ABS layer.
Dan
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Wyatt, David
Sent: Wednesday, July 26, 2006 8:28 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Domain Local Groups vs Global Groups
I'd be interested to hear peoples strategy for permissioning windows based file servers when the server is in a Windows 2003 domain. I have read the best practices about putting users into global groups then put the global groups into local groups then permission the resource with the local group. But:
1. Is it better practice to put the domain local group into a local group on the file server and then use this local group to permission the share/folder? Is this excessive? I have read something about performance or avoiding limits by using the server local group when the access token is created.
2. What shortcomings would there be in putting users into global groups then simply permissioning the global group onto the resource. We only have a single forest/domain.
I am also aware of Universal groups but lets put these to one side.....for the moment..;-)
Thanks
David
****************************************************************************
This message contains confidential information and is intended only
for the individual or entity named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message which arise as a result of e-mail transmission.
If verification is required please request a hard-copy version.
This message is provided for informational purposes and should not
be construed as an invitation or offer to buy or sell any securities or
related financial instruments.
GAM operates in many jurisdictions and is
regulated or licensed in those jurisdictions as required.
****************************************************************************
