|
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)
http://www.cafeshops.com/joewarenet (wear 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
|
- [ActiveDir] enterprise-wide accounts Creamer, Mark
- RE: [ActiveDir] enterprise-wide accounts joe
- RE: [ActiveDir] enterprise-wide accounts Depp, Dennis M.
- RE: [ActiveDir] enterprise-wide accounts Cary, Mark
- RE: [ActiveDir] enterprise-wide accounts Grillenmeier, Guido
- RE: [ActiveDir] enterprise-wide accounts Mike Celone
- RE: [ActiveDir] enterprise-wide accounts Matjaž Ladava
- RE: [ActiveDir] enterprise-wide accounts Grillenmeier, Guido
- RE: [ActiveDir] enterprise-wide accounts Celone, Mike
