Domain Join as a Security Risk

One process that exposes many potential attack vectors is adding a new computer to the domain. As part of general account hygiene, you will want to remove the permission for adding up to 10 computers to the domain, which is assigned to each user by default. This action will at least prevent a potential attacker from creating new computer objects very early on in their attack chain and adding machines of their choice to your AD.

The domain join process is far more serious for servers. If a domain admin initiates this process manually on the new machine, the owner of the resulting computer object is the Domain Admins group, which is a good and secure choice. However, if you want to automate the process, you need to be aware that the credentials of the account intended for the domain join are effectively available in the clear, because these credentials need to be transmitted to a freshly installed computer that does not have a trust relationship. Therefore, you must strive to limit the rights of the join user to the necessary minimum – with the result that the join user will own the computer object in AD. If you are not careful and the new server becomes a Tier 0 system, perhaps even a DC, you'll have created a highly privileged system whose computer object belongs to a user whose credentials are effectively exposed in plain text. To get out of this dilemma, several methods can secure (even enterprise-specific) join processes:

• Pre-provisioning the computer object so that the join user requires even fewer permissions and is not automatically added as the owner of the new machine account.
• Pre-provisioning the computer object with an offline join (the DJOIN command [5]; Figure 3). In this case, you are not transferring credentials from a join account, but rather an offline join file, to the new computer. If you can find a secure and robust process, it is a very good approach.

Figure 3: The DJOIN command can be used to limit somewhat the effect of domain joining.

• The use of a temporary domain admin account that you create for each new computer and delete again after deployment. This method should not be your preferred option, but it does work if all else fails.

Pre-provisioned computer objects have the added benefit that you can add them to the correct OU and group before installing the computer. Remember that Microsoft hardened the join process with an existing computer object in 2022 and again in 2023 [6], which limits your design options to some extent.

Another measure you should integrate into the deployment or domain join process is to remove the Domain Admins group from the Local Admins group of the newly minted AD members (Figure 4). In the default AD permissions configuration, you can easily use Group Policy Preferences or, less conveniently, the Restricted Groups group policy; however, the computer account must at least be able to see the Domain Admins group.

Figure 4: Adding local administrator customizations to a policy.

The same applies to the groups or users to which you want to grant Local Admins rights instead of the Domain Admins – the computer must see these objects to process the policy. One possible solution would be to add the pre-provisioned computer object temporarily to a group that can see the required privileged groups and then remove it from this group again after completing the deployment.

If your AD is already hybrid, and all users have a synchronized Entra ID account in addition to their AD account, you might want to consider not adding your client machines to AD at all, but joining them directly to Entra ID. Access to local resources can still be authenticated with Kerberos, provided you have a network connection to the DCs; however, access to services and systems that require NTLM would be ruled out. Of course, group policies are no longer available for the configuration, so you would have to use Intune or another tool, which is a small price to pay for the security gains.

The Art of Transition

Secure AD design techniques are relatively easy to implement if you are building a new AD forest on a greenfield deployment. Even in a brownfield infrastructure, you can implement all the individual technical measures, but admins typically shy away from doing so because the side effects of the hardening and reorganization measures are unclear. Simply doing nothing in these troubled times is no longer an option, though, and rebuilding and migrating your AD can be the only escape route.

If you know what you are doing, nothing is wrong with migration, and a new forest is particularly advisable in the following situations:

• The current AD structure contains many domains in a forest, which you want to simplify to create a flat, single-domain topology; migration is inevitable in this case.
• The handling of DC system state backups has been too slack, meaning you have to assume that a potential attacker owns your DPAPI backup keys.

Even in forests where you have already made major changes to the authorization and delegation structures, it might be easier to migrate than embark on a painstaking clean-up with unpredictable consequences at each step. If you go down this route, you should try to migrate without adding SID History. If the planned coexistence of the old and new ADs in conjunction with existing applications makes SID History indispensable, you must at least have a clear roadmap for resolving the coexistence and removing SID History.

Conclusions

AD can be operated in a secure way, but you must have a general plan in place that is geared toward security and be willing to deviate massively from the default values delivered with AD and the machines involved. In this article, I could only scratch the surface and provide a rough direction toward account hygiene, including service accounts, cryptography and PKI, authorizations, and seemingly innocuous processes like joining new computers to AD. On a closing note, it's well worth investing time and effort in AD security, because AD will be with us for quite some time.