Compass Security Blog

Offensive Defense

Domain-Join Computers the Proper Way

When you add a new computer, it must first join the domain. If you use its future main user to do it, they’ll become the owner and be able to hijack the computer to become a local administrator in four easy steps.

During internal assessments in Active Directory environments, we often use BloodHound to find privilege escalation paths and we happen to find users with a GenericAll relationship to their own workstations. This often means the IT joined these computers in a non-recommended way.

GenericAll relationships are an open invitation to become local administrator on the computers once the users are compromised.

Joining Computers to a Domain

By default, any authenticated user can join up to 10 computers to the domain. The GPO configuration Add workstation to domain defines who can join computers (Authenticated Users by default), the maximum computer each user can add being defined by the property ms-DS-MachineAccountQuota (10 by default).

When computers are joined to the domain that way, the account that joined it is granted several privileges on computer object (such as GenericAll).

In order not to give these privileges to normal users, it is recommended to use a dedicated account with the sole purpose of joining computers to the domain. It should have the Create Computer objects right on the corresponding organizational unit (OU). When computers are joined by this account, different privileges are assigned on the computer object (Owns in BloodHound) and the graph look like this:

Although the privileges granted in the one or the other case are not the same, the account that joined the computer to the domain can gain administrative privileges on it.


In order to gain administrative privileges on the computer, the account that joined it to the domain has to use so-called Resource-Based Constrained Delegation. This technique has already been extensively described on the Internet, for additional details, see the references at the end of this post.

Basically, it consists of four steps:

  1. Gain access to an account – let’s call it JOIN – who has GenericAll or Owns privileges on the victim computer – called VICTIM.
  2. Gain access to a computer account – called HELPER – e.g. by creating a new one with any Authenticated User or with JOIN, or by becoming local administrator of another computer.
  3. Use JOIN to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of VICTIM and set it to trust HELPER. This will allow HELPER to impersonate domain users when handling with VICTIM.
  4. Use HELPER to connect to VICTIM and impersonate a user who can be delegated and who is a local administrator on VICTIM, e.g. a domain administrator.

Remediations and Best Practices

In order to prevent this kind of exposure, you’ll have to prevent users from joining computers to the domain and use a dedicated account instead. First, remove the Authenticated Users from the GPO configuration Add workstations to domain (SeMachineAccountPrivilege):

Then, change the ms-DS-MachineAccountQuota attribute from 10 to 0:

Now, you can create a dedicated account with sole purpose and permission of joining computers to the domain by granting it the permission Create Computer objects on the corresponding OU or by using the Delegation of Control Wizard:

This account should have a strong password, that is changed regularly and that should only be known to administrators with regard to the permissions it confers.

Finally, you should protect every account with administrative privileges in general by setting the option Account is sensitive and cannot be delegated. This can break things if you use (un-)constrained delegation with these accounts.

Fix What’s Already Done Wrong

Once this is in place, you might want to find the users with privileges on their computer due to previous practices and remove the permissions on the computer object.

To do so, you can use BloodHound to assess the situation. Once you have loaded the data from your domain in the application, mark the known and trusted join accounts as High Value in order to exclude them from the analysis.

Then, run the following Raw Query to show all the ACLs from users to computers, which would result in a similar graph as the first screenshot in case computers were joined by regular user accounts:

MATCH p = (u:User)-[r]->(c:Computer) WHERE u.highvalue = false AND r.isacl = true RETURN p


Joining computers is not a task that you want to trust everyone with, since the joiner account can obtain administrative privileges on the joined computer. The recommended way to join computers is to have a dedicated account for this task.

In this post, we’ve seen the power of accounts joining computers to the domain and the importance to protect them. We’ve also observed that, as for many other points, it is important to harden the configuration of your Active Directory, since it is not shipped with a restrictive configuration by default.


Microsoft references about joining computers:

Several good explanations about delegation:


  1. DeWayne Weaver

    Join a Computer to the Domain is not an option in the Delegation Wizard of an OU. I have an all 2016 or newer DC forest with corresponding domain and forest functional levels. What are my options other than picking and choosing from a custom task to delegate?

    • Thierry Viaccoz

      Hi, thanks for your question! This is right, the option “Join a computer to the domain” is only available on domain-level, not on the OU. What you can do is grant the permission “Create Computer objects” to a user via the advanced security tab (Properties > Security > Advanced) of the corresponding OU.

  2. Guylaine

    Good explanation,
    In a Real World, you have to remove owner permissions to users who has joined the computers.

    What is the best method ?

    Suppose this:
    – suppose computers1 and 2 have been joined by technician
    – suppose userjoin1 , the new account with create objects right, to join computers to domain

    I propose to remove technician as owner of computers1 and 2, and replace by userjoin1

    • Sylvain Heiniger

      Hi Guylaine,

      That sounds about right, and don’t forget to protect this userjoin1 account well!

  3. Alex

    Great blog. I didn’t realise it was such an issue. Does Bloodhound fix the issue or only show where the issue is?

    If it doesn’t fix it then how can I fix the issue?


    • Sylvain Heiniger

      Hi Alex,
      Bloodhound only serves to show the current permissions on you AD objects.
      To fix the issue, you have to change the ACLs on the computer objects, by hand or using a script.

  4. Mag

    The second link under
    “Several good explanations about delegation:”
    has changed:

    • Sylvain Heiniger

      Thanks for the heads up!

Leave a Reply

Your email address will not be published. Required fields are marked *