I need to set up a plan for organizing permissions for sysadmins in a 200-server Windows 2003/2008 network. The servers exist in 5 separate forests that are connected via 2-way trusts.
At the moment, I'm mostly focused on how best to organize the groups. All sysadmins have a single admin account in one of the forests (forest A) and I wish for them to use this account to manage everything.
As I understand it, the usual best practice is to:
Give access to resources to domain local groups in the local forest where they exist. I've done this by creating groups like ForestB\MemberServerAdmins, ForestB\DCDNSAdmins, ForestC\ExchangeReadOnlyAdmins, etc and I've delegated access to these groups from the various applications.
Organize users by role into global groups in forest A and then place those global groups into the domain local groups as necessary. I guess this might be done, for instance, by department where you have a group like ForestA\Operations and they get access to some but not all of the resource groups and another group like ForestA\Admins and they get access to all of the resources groups. That's just an example.
The problem is, we really need to assign these permissions to resources on an individual basis. We're a smaller company and I don't have batches of users that necessarily need all of the same permissions. This makes step #2 above seem not to work for us. The solution I'm left with is to create global groups in ForestA that have basically the same names as the various resource groups like this:
ForestA\ForestB MemberServer Admins
ForestA\ForestB DCDNSAdmins
ForestA\ForestC ExchangeReadOnlyAdmins
and then place individual admin accounts into those groups.
I get the flexibility this two-group solution has for assigning resources but does it make sense to set things up this way? I like it because then I can manage all permissions in ForestA and easily look at any admin account to see which groups they are in to determine what they have access to. Still, I'm not sure this is the best route?
One benefit from doing things that way comes when you have personnel changes. Since everything is set up with groups, you create your new account, populate the global groups in Domain A, and you're set.
I'm not sure what you were thinking as alternatives, but if you were thinking just directly putting the user objects from Domain A into the domain local groups in the other domains, you lose some visibility doing that. If you look at a user object in Domain A that is directly in a domain local group in, say, domain B, you won't necessarily see that domain local group in the "Member Of" tab for the user. So, to know what access the user has, you have to go crawling around the various domain local groups looking for the user object. If you use the Global/Local style you mention here, you can just look at the user's global group membership for a quick read on what access they have.
In addition, using the group structure makes it easier to grow. If you don't set the groups up from the start, eventually growth may drive you to want them, and going back in to do the groups later can be painful. (Doesn't have to be, but can...)
Just a couple of thoughts, hope it helps.