Delegating AD site in Forest

Hey guys,

We have a forest of about 15 sites. Now for 1 site, i'd like to give them access only to that domain/AD as an admin.

How can i do that?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

First things first, remember forests and sites are not equivalent types, nor is the latter a subtype of the former; they serve different purposes, and hence your question as written does not parse.

Refer to the formal definitions at TechNet; the definitions below are colloquial descriptions and not intended to match the formal documented definitions for each term.

"Domains" in Active Directory typically represent distinct organisation / management units. There can be multiple domains within a forest, which typically mutually trust each other (for some definition of "trust"). Each domain has a notion of a "Domain Admin" and similar, which is responsible for objects within that domain. The forest has a "forest root" domain, in which an "Enterprise Admin" can be found with privileges over the whole forest.
Additionally, you might have multiple forests, with explicit trusts between them. This is the "logical" view of the environment, intended to capture organisational structure, management hierarchies, etc.

You would know if you have multiple domains, one for each location. If not, you can always bring up Active Directory Domains and Trusts to find out.

Sites refers a separate concept regarding the connectivity between the DCs in your environment -- the "physical" topology of the forest. This provides hints to Active Directory which assist in the generation of schedules and connectors for replication of data between Domain Controllers; typically, you would split into sites where multiple locations are connected by slow links, and group objects interconnected by fast links within a single site.
Each site is identified by one or more subnet objects; workstations and member servers match their IP address with the site configuration to determine which site they are in. Domain Controllers must be manually assigned to sites.
Properly configured resource location will subsequently use this information to prefer DCs local (rather than crossing a VPN link to another country, say), while replication might run on a reduced schedule between poorly connected sites.

We have a forest of about 15 sites. Now for 1 site, i'd like to give them access only to that domain/AD as an admin.
So -- do you have multiple "sites", multiple "domains" in a single forest, or both?

Multiple sites

If you have multiple sites within a single domain, then your request is somewhat difficult because there is no notion of permissions or delegation of control at the physical level; you have a single domain, and therefore a single container replicated among multiple sites representing a single administrative domain. The separation into sites merely advises Active Directory of the topology over which the DCs are deployed, without intending to provide the facility to logically identify which objects (users, computers, groups, etc.) belong to each location and delegate control for that location.

In this instance, you will typically want local techs to manage machines and user accounts local to them. In smaller cases, you might split each site into separate Organizational Units (OUs) and use Delegation of Control to grant the tech(s) for each site the relevant permissions to manage objects in their site's OU. The techs should not have Domain Admin, Enterprise Admin or any other specialist groups granted, since this gives them control over the entire domain / forest.

It would be most unusual for a company to deploy multiple domains for each location; the above solution is normally satisfactory, and is strongly recommended unless there is a valid overriding reason why the complexity of multiple domains is required.

Multiple domains

In the case of multiple domains, hopefully this represents one domain per site. This was a popular configuration on NT4 systems (due to its differing AD implementation imposing limitations), but has gone away now that AD is better able to run a single domain across multiple sites efficiently and reliably.

For multiple domains, local techs are simply granted Domain Admin rights (or whatever rights you wish to provide) in the domain for their site. They are granted NO PERMISSIONS in the forest root domain, in particular NOT "Enterprise Admin".

However, do remember that the forest is the security boundary, not the domain. Quoting from that link:
Active Directory domains in a forest should never be deployed with the objective of isolating business units that do not trust each other.


If you have a mixture, you have the necessary substrate to simply follow the "multiple domains" approach and configure permissions accordingly. The sites configuration is a non-starter because it cannot be used for logical delegation of control.
Cobra25Author Commented:
Ok i would prob just need DHCP/DNS/AD delegated to one location.
Ok i would prob just need DHCP/DNS/AD delegated to one location.
Unfortunately, given the wealth of different options available in Active Directory, it is still not clear what you want to achieve.

Perhaps you could explain your organisation setup a little better, and precisely where the staff are situated, how each site is configured (do they each have a DC, etc?) and what the staff in each site should be able to modify?

If you want to "delegate Active Directory" and allow ANY changes to be made, then the staff need to be Domain Admins for that to work. I doubt this is what you want, however, since they have full control over the enterprise at that point.
Cobra25Author Commented:
OK theres 1 flat forest. OU's and different subnets for each.

For that location, i need someone else to manage AD, DNS, DHCP for that OU/Site
OK theres 1 flat forest. OU's and different subnets for each.

For that location, i need someone else to manage AD, DNS, DHCP for that OU/Site
Thanks, that's helpful.

Sounds like a single-domain forest with separate OUs representing computers and users for each location.
Remember, subnets and anything you enter in AD Sites & Services is irrelevant for delegating control of objects in AD Users & Computers; the former is the physical view of the environment, the latter the logical view which maps onto your management structure.

Managing the OU where objects relevant to the remote site are located is not difficult: create a group for admins in that site, add the relevant users to it, then right-click the OU and use Delegation of Control to grant permissions to that group on that OU. The wizard will ask what actions you wish members of the group to be able to take, and on what types of object (e.g. computer, user, printer...) they can make those actions. Typical examples include resetting passwords, joining computers, etc.

The users should be removed from any groups such as Domain or Enterprise Admins which they are members of, as these will override any delegated control.

Control of DNS and DHCP is harder. The DNS database, particularly if AD-integrated, is global for the entire domain, so you cannot trivially delegate control over particular records. DNS has no idea which records refer to machines in which site.

You can grant read rights to non-admins by adding the appropriate permissions in the DNS console: see this article for details.
You can follow a similar process to grant the ability to make changes (add/remove/modify records, etc.) but remember this will be on a global basis across the entire zone / subzone you choose to add the permissions for. You can also add permissions to individual records, but for dynamically registered computer records these permissions are unlikely to stay, and it will add a huge management overhead.

For DHCP, the process is simpler because this is a server-by-server role. You can add relevant users to the DHCP Administrators group (as per this article), but this gives them the ability to manage all DHCP servers in the enterprise.
You can also follow a similar technique to the DNS example above; on the relevant DHCP server in the site local to the techs, add the relevant security permissions to the zones contained in that server.

Remember: if any of these roles run on a DC, you cannot (easily) delegate the ability to log-in to that DC at a terminal or via remote desktop to anybody who is not a Domain or Enterprise Admin. I would strongly recommend you don't attempt to do so; if the users are not trusted to have that level of privilege granted to them, then login access (or, indeed, physical access) to a DC represents a security risk.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.