In October of 2023, Microsoft released an update that further changed the way machines can be joined to the domain.
Recently, I was asked to find the minimum permissions required to bestow upon an account that will be used to rejoin or prestage a computer to the domain (not a fresh join – this is a whole different kettle of fish!). At first, this may seem like quite a simple task, but as it turns out like everything in life – it depends!
Microsoft have an article published that states that the required permissions to set for a join account on a computer object are:
- Reset Password
- Read and write Account Restrictions
- Validated write to DNS host name
- Validated write to service principal name
At a very base level, you could argue this is true; these rights are required *if* those values needed to be set, and sure; When re-joining a machine, you will need the rejoin account to reset password, and read/write account restrictions.
BUT!!! Does the rejoin account really need Validated write to DNS host name and Validated write to service principal name rights on a computer object?
The answer is: If you prestage an account you may be tempted to do so, but it can be (*AND SHOULD BE*) avoided completely.
Whilst Microsoft has uplifted things somewhat with the netjoin hardening updates, there are vulnerabilities actively trying to exploit these rights, so it is a good idea to try and avoid assigning domain rejoin accounts validated write to DNS and service principal name rights. This update from Microsoft relates to CVE-2022-38042.
What are you talking about?
When rejoining a machine to the domain, certain rights are needed for the account attempting the rejoin. If you are using a dedicated domain rejoin account, you might be tempted to assign the four rights Microsoft mention above.
You do not need to assign all four and for the love of security, please stop doing it.
Regardless of your scenario, you only need to assign the top two rights over your computer objects to your Domain Rejoin Accounts:
- Reset Password
- Read and write Account Restrictions
NOTE: With the new Allow computer account re-use during domain join update from Microsoft, your rejoin account will need to be added either directly or via group within the following policy element:
Given we are talking about rejoining a machine to the domain, if the dNSHostName and the required ServicePrincipalName (restrictedKrbHost) values are present, you do not need those rights set on the computer object – as they are already set when the machine first joined the domain.
The only scenario where there will be an issue is when a computer object is prestaged. If the computer object is prestaged, the dNSHostName and the required ServicePrincipalName values will not be automatically set. These only normally get set when a computer is first joined to a domain.
If a join is attempted on a bare bones prestaged computer object with only reset password and read/write account restrictions permissions set on the rejoin account, it will likely fail because these two extra values have not been set. In fact, with the latest netjoin hardening updates this may end up presenting a misleading message when trying to rejoin the machine in this scenario:
An account with the same name exists in Active Directory. Re-using the account was blocked by security policy.
The C:\Windows\Debug\NetSetup.log contains a couple of confusing entries:
29/02/2024 22:13:35:044 NetpMapGetLdapExtendedError: Parsed [0x2098] from server extended error string: 00002098: SecErr: DSID-031514B3, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
29/02/2024 22:13:35:044 NetpManageMachineAccountWithSid: The computer account already exists in Active Directory.Re-using the account was blocked by security policy.
These messages appear even if the correct GPOs are set allowing the account to re-use (and additionally remote-SAM is allowed in restricted environments). Which can be REALLY confusing to an Administrator – they may be thinking that their GPO may be broken and things aren’t applying, etc.
The actual reason it is failing is because the two values are not set, and the account trying to join the machine is trying to set them (and of course, it does not have the permissions so it fails).
There are two ways to fix this:
- Give in and assign those toxic Validate rights over computer objects to domain rejoin accounts and the join account will set them on the machine when the machine joins the domain.
-OR- - Set the dnsHostName and ServicePrincipalName values accordingly when prestaging the computer account.
Setting the values when prestaging means that when joining the computer, the join account does not need to be given those evil Validate rights and the machine can join freely.
What needs to be set?
The dNSHostName value needs to be set to the fully qualified name of the host.
eg; if the machine name is RandomServer1 and the domain is test.local:
Attribute:
dNSHostName
Value:
RandomServer1.test.local
The servicePrincipalName attribute needs to be loaded with two RestrictedKrbHost values.
eg; if the machine name is RandomServer1 and the domain is test.local:
Attribute:
servicePrincipalName
Values:
RestrictedKrbHost/RANDOMSERVER1
RestrictedKrbHost/RandomServer1.test.local
With these values set, there is no need to provide Validated write to DNS host name and Validated write to service principal name rights to the rejoin account over the computer accounts that need to be rejoined.
Because those values are set above, in this example below, the only permissions needed for the rejoin accounts are:
- Reset password
- Read/write account restrictions
For an example computer prestage script that:
- Creates a computer account
- Sets dNSHostName value
- Sets servicePrincipalName Values
- Grants reset password & read/write account restrictions
Visit: https://github.com/Jigsolving/powershell/blob/main/domainrejoin/prestageComputer.ps1
