I’m implementing a tool which secures certain shared resources within AD forest (mostly file shares). By some criteria a list of users from different domains is generated, those users are added to a universal group (because J’ai besoin de to gather users from different domains in a single group) and then that universal group is added to a shared resource ACL.
The forest has roughly 10 000 users, Je pense my universal groups will end up having up to 2000 users in each. And there might be up to several thousand those groups.
Everything looks good and works in test environment.
In “Bonne pratiques for controlling access to shared resources across domains” section
it reads that I should create domain local groups and nest global/universal groups in it.
I understand that tVoici an administrative benefit in it, easier management, visibility, etc
But I’m doing everything automated and my tool will watch for the right security by itself.
Some our IT consultants try to persuade me that not following that bonne pratique may also result in poor performance.
So basically the question is: Can there be a performance (it means time required to logon, to secure a directory, etc) impact if I add universal groups directly on the shared resource instead of nesting universal group in a domain local group?
Merci in advance.
Mise à jour :
TVoici also one restriction regarding nesting groups. (http://support.microsoft.com/kb/328889)
TVoici a limit of 1015 user’s groups. So In case of nesting universal groups into domain local groups I get ~ 500 limit, which seems like a painful restriction.
UPDATE2:
Regarding my forest topology. J’ai 6 domains, grouped into 2 trees. (Tree consists of a root domain, and two child domains)
Voici Microsoft’s statement regarding Universal Groups. Especially the bolded part pertains to you:
Universal groups can be used anywhere in le même Windows
forest. They are only available in a Native-mode enterprise. Universal
groups may be an easier approach for some administrators because there
are no intrinsic limitations on their use. Users can be directly
assigned to Universal groups, they can be nested, and they can be used
directly with access-control lists to denote access permissions in any
domain in the enterprise.
Universal groups are stored in the global catalog (GC); this means
that all changes made to these groups engender replication to all
global catalog servers in the entire enterprise. Changes to universal
groups must therefore be made only after a careful examination of the
benefits of universal groups as compared to the cost of the increased
global catalog replication load. If an organization has but a single,
well-connected LAN, no performance degradation should be experienced,
while widely dispersed sites might experience a significant impact.
Typically, organizations using WANs should use Universal groups only
for relatively static groups in which memberships change rarely.
The performance impact should be rather minimal in a well-connected environment where everyone has access to global catalogs.
The performance impact will be increased time to log in and increased time to evaluate ACLs on resources if a global catalog cannot be reached, or if your Sites & Subnets are misconfigured so that you find yourself communicating with global catalog servers outside of your own site. Also, there will be increased global catalog replication load.
Cependant, I’m obliged to once again inform you that what you’re doing is against commonly-accepted bonne pratiques.
This part of what you said: “… and my tool will watch for the right security by itself.” That also scares me.
So I’m on the side of your IT consultants and Je pense they are doing their jobs by trying to persuade you to follow commonly-accepted bonne pratiques in terms of AD design.
But there’s the answer to your question regardless.