You can not add (haven't tried to hack this, probably is hard coded functionality) foreign users to the domain admin group of a domain, they must exist in the same domain - domain admins is a global group, standard rules apply. The best would be administrators group membership which, unlike NT4, is not the same as domain admins in terms of Windows 2000+ Domain objects.
 
The delta in Windows 2000+ is that many AD objects have different permissions set specifically to domain admins and being an administrator on a domain controller does not give access to those objects. Additionally nothing is (actually I have to say "should be" due to some "bugs") permissioned in the forest wide partitions to "administrators" because they don't have domain affinity like domain admins do. I.E. If you have an object in the config container with permissions set to administrators group, it means administrators in any domain. Say you want to give rights in the config container to administrators in Domain 1, by default, those permissions apply to every administrator of every domain in the forest. The SID for administrators has no domain context, it is a well known SID that is the same everywhere - S-1-5-32-544.
 
The general practice for domain controller permissions would be to create your "god" level IDs in your root domain or other main domain, then add those IDs to every administrators group on every domain. Then also create IDs in each domain for the admins and add those to the domain admins groups of the respective domain. You would normally be able to use the one ID to do most work, but if you needed to modify something that required domain admins rights, you would switch to the local domain admin ID. What is example of something a domain admin can do but an administrator can't in AD... How about delete Subtrees. Also no delete of child objects however you tend to pick that back up due to default SDs. Default DC and Default Domain policy objects don't have Administrators in the ACL.
 
An alternative would be to create a new universal group and update AD permissions to match the domain admins group for that universal group. You would still have to populate workstations and servers as well so this isn't buying a whole ton, definitely not worth the skull sweat to do.
 
Of course if the goal isn't full perms over AD Objects, but instead Domain member servers/workstations, the previously mentioned GPO method is the way to go.
 
-------------
http://www.joeware.net   (download joeware)
 
 
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Creamer, Mark
Sent: Tuesday, April 13, 2004 4:05 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] enterprise-wide accounts

We’d like to eventually trim down the number of domains and get to an OU-based administrative model. But in the mean time, we have identified a couple of people that we want to have domain admin rights in all domains. I know that making them an enterprise admin allows them domain admin rights on the DCs in each domain because of membership in the BUILTIN\Administrators group in each domain. But that doesn’t allow logon to all the member servers. How do I best grant “domain admin-level” rights across all domains in the forest with a single logon for each of these persons? Looking for a best practice.

 

Thanks!

 

Mark Creamer

Systems Engineer

Cintas Corporation

Honesty and Integrity in Everything We Do

 

Reply via email to