Delegating control in Active Directory gives control of the _object_ in
active directory only. For example, if you have control of a computer
object, you can do things with it in AD like change the description or
disable the machine account. However it does not make you an administrator
of the actual server (as distinct from the server object in AD), so you
can't for example install software on the server or shut it down. You might
want someone to administer user accounts and group, without managing
servers.
Conversely you can be an administrator of the server, but have no rights to
the server object in Active Directory, so not be able to make the server a
member of a group, or apply a group policy.
There is an overlap because some operations require rights on the server as
well as rights in Active Directory. For example if you create a DFS share,
you need to be an administrator of the server to create the share, and have
the rights in AD to create the dfs object.
Domain Administrators is a special case, because it is a built-in group
created to automatically have full control of everything. It has full rights
in AD, and is automatically a member of the Local Administrators group on
servers and PC's. It gets round the need to know exactly what rights are
required. However it is a bad idea to use the Domain Administrators group to
get round knowing what rights are required. For example, you might want to
give some people Full Control of an OU, and make them members of the local
administrator group on PC's and servers in it. They could then do nearly
everything in the domain, but not quite everything. You would still retain
ultimate control of the domain, including control of who has these rights.
The Builtin groups in Active Directory, including Administrators, are a
special case because you need to be able to give some rights to work on the
domain controllers, without having ultimate control of the domain.
All in all, unlike Windows NT, W2K gives much more precise control of who
can do what.
Anthony
to
