Our domain is trusting an external domain (not in the same forest) and we need to add a group from the external domain into the Domain Admins group of our domain.

I understand that the Domain Admins group is a global group, so we cannot add groups from other domains into it. But I have seen several workarounds on the internet, but none of these seem to work in our situation.

I tried creating a universal group and a domain local group, but I cannot add either of these to the Domain Admins group and only the domain Local groups lets me add accounts from the external trusted domain.

  • Global security group (e.g. Domain Admins)

    • Can add Domain Local group: No
    • Can add Global group: Yes
    • Can add Universal group: No
    • Can add from trusted domain: No
  • Universal security group (e.g. Enterprise Admins)

    • Can add Domain Local group: No
    • Can add Global group: Yes
    • Can add Universal group: Yes
    • Can add from trusted domain: No
  • Domain Local security group (e.g. Administrators)

    • Can add Domain Local group: Yes
    • Can add Global group: Yes
    • Can add Universal group: Yes
    • Can add from trusted domain: Yes

               |      Group can contain members of type                 |
| Group type   | Global | Universal | Domain local | Trusted Foreigners |
| Global       | Yes    |           |              |                    |
| Universal    | Yes    | Yes       |              |                    |
| Domain local | Yes    | Yes       |              | Yes                |

The Global Domain Admins group can only contain other Global groups.

And Global groups cannot seems to directly (or indirectly) contain principles from foreign domains.


An awful workaround might be:

I have a group that i want added to every local Administrators group on every machine in the domain:

enter image description here

How can I add a group to the Administrators group on every machine in the domain?

Cannot work; a Domain local group cannot contain other Domain local groups.

The only workaround i can see is manually create duplicate accounts for every user in the local domain

Cons: decreased network security, lower user productivity, complicates administration, worse administrative control, inconsistent policies, increased TCO.

Bonus Chatter

From Application Specification for Microsoft Windows Server, Chapter 5. Security Services:

Single Sign-On (SSO) allows enterprise network users to seamlessly access all authorized network resources, on the basis of a single authentication that is performed when they initially access the network. SSO can improve the productivity of network users, reduce the cost of network operations, and improve network security.

  • Better network security. All SSO methods available under Windows provide secure authentication and provide a basis for encrypting the user's session with the network resource. Eliminating multiple passwords also reduces a common source of security breaches - users writing down their passwords.

  • Improved user productivity. Users are no longer required to remember multiple logons, nor are they required to remember multiple passwords in order to access network resources. This is also a benefit to help desk personnel, who need to field fewer requests for forgotten passwords.

  • Simpler administration. SSO-related tasks are performed transparently as part of normal maintenance, using the same tools that are used for other administrative tasks.

  • Better administrative control. All SSO-specific information is stored in a single repository, the Active Directory. Because there is a single, authoritative listing of each user's rights and privileges, the administrator can change a user's privileges and know that the results will propagate network wide.

  • Consolidation of heterogeneous networks. By joining disparate networks, administrative efforts can be consolidated, ensuring that administrative best practices and corporate security policies are being consistently enforced.

Bonus Reading

  • I also tried those internet workarounds, using Universal groups, etc., but none worked. What really worked here was to add the Domain Admins group from the external forest to the Administrators (Built-In group) in our domain. The 'Domain Admins' group from our domain is in the Administrators group too, so I guess both groups get practically the same permissions.
    – esserafael
    Oct 17, 2018 at 18:11
  • @esserafael The problem with adding it only to the local Administrators group, is that it doesn't carry to all machines in the domain - it only applies to the local machine's Administrators group.
    – Ian Boyd
    Oct 17, 2018 at 18:27
  • @IanBoyd, see my reply below. If you're trying to use the domain's "Administrators" group or the domains "Domain Admins" group only to allow these foreign accounts to manage workstations or servers, you're going way overboard with granting access.Running into these roadblocks is a sign from AD's designers that you're doing something that you shouldn't be doing.
    – Semicolon
    Oct 17, 2018 at 18:49

2 Answers 2


It is specifically designed to be this difficult. Not only is it contrary to good practices, but it is generally flat out ill-advised.

You are essentially turning control of your domain over to another entity whose security, policies, auditing, and procedures are outside of your control and outside. Moreover, your environment has at least double (possibly more) the attack surface

There are two proper methods (from my point of view) to "achieve" what you are seeking

  1. I advise against using the Domain Admins group for this purpose, it is rarely absolutely necessary.
  2. (Preferred) Create a global group with the necessary delegated access to Active Directory, create NEW accounts in your domain for these foreign persons to use when performing tasks in your AD structure.
  3. (Less preferred) Create a Domain Local Group with appropriate delegated access to Active Directory, add the foreign accounts to this Domain Local Group. (Domain Local Groups are recommended by Microsoft to secure access to resources [i.e. ACLs / User Rights], actually for all things except Active Directory Permissions [DSACLs] to avoid a situation where a foreign principal has access to the domain).

If NO administrative access to AD is required (i.e. just looking to manage servers/workstations/etc.) then I note that Domain Admins should not be administrators on any computers other than Domain Controllers.

Dedicated accounts should be used to administer workstations, separate dedicated accounts should be used to administer servers.

These accounts should be added to custom Domain Local Groups which (via GPO) can easily be configured to be in the local Administrators groups of appropriate member computers. Domain Admins should specifically be removed (via GPO or other means) from the local Administrators groups on all member servers.

Updated answer to go with the updated question

Use Group Policy Restricted Groups. Through a GPO that does not affect any domain controller, create an entry for "Group that I want added to every local Administrators group," in the entry, in the box that says "Member Of" you will add "Administrators" this will ensure that the "Group that I want added to every local Administrators group," domain local group is added to the local Administrators group of every computer affected by said policy.

When working with Restricted Groups and "Administrators" be extra careful to ensure that Domain Controllers are not included or affected by this policy (through Delegation, security filtering, WMI filtering, or proper GP Linking).

  • In our case we're not turning over control of our domain to an unknown entity. I'm actually creating a separate domain, that i simply want this side domain to use our real domain for everything. Although, the reasons why i want to do it are irrelevant. The end result is that i do not want to create any new users in this domain, and i want everything to come from the real "trusted" domain. This new domain is a wart, a splinter, a hangnail that i cannot get rid of; but i can make it as painless as possible - which means not creating separate user accounts for everyone in two domains.
    – Ian Boyd
    Oct 17, 2018 at 18:49
  • In any event, "domain admins" is not the appropriate method to achieve this. A new domain local group which (via GPO) is granted membership in the local Administrators groups on all machines (save Domain Controllers). This DLG would then be populated with the accounts from the trusted forest. That would be the appropriate way to configure administrative access on computers.
    – Semicolon
    Oct 17, 2018 at 18:53
  • Updated the question to ask how to add a group to every local Administrators group in the domain.
    – Ian Boyd
    Oct 17, 2018 at 20:44

No you cannot using the builtin product. And you usually don't need to do this, because Domain Admins gets nearly all of its permissions from the builtin domain Administrators group. Which can have members from other domains.

You should also have a separate administrative group for granting access to member server/workstations.

There is a product Microsoft Identity Manager which can add accounts from a trusted administrative forest to Domain Admins for time-based group membership, but that is probably more than what you are looking for.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .