Domain Join VM To Entra Domain Services fails with the user name or password is incorrect
When trying to join a vm to entra domain services I get 'The user name or password is incorrect'.
I have set up as follows
- User is a member of AAD DC Administrators
- NTLM password synchronization is enabled
- I have reset the password of two account to test and waited for the sync
Microsoft Security | Microsoft Entra | Microsoft Entra External ID
-
VEMULA SRISAI • 3,500 Reputation points • Microsoft External Staff • Moderator
2025-12-11T16:11:26.5433333+00:00 Hello GerryNicol ,
The error “The user name or password is incorrect” when joining a VM to Entra Domain Services is almost always caused by password‑hashes not yet being synchronized to AAD DS or the VM not using the correct DNS settings.
Please try the following:
Make sure Password Hash Synchronization to Azure Active Directory Domain Services is enabled After enabling it, wait about 20 minutes for NTLM/Kerberos hashes to sync. Many domain‑join failures immediately start working once the sync completes.
Use the correct username format Use either:
******@domain.com(recommended) orDOMAIN\usernameFor guidance:
https://dori-uw-1.kuma-moon.com/en-us/entra/identity/domain-services/tutorial-create-instance
-
GerryNicol • 6 Reputation points
2025-12-11T16:16:02.3866667+00:00 I have done all those
-
VEMULA SRISAI • 3,500 Reputation points • Microsoft External Staff • Moderator
2025-12-11T16:26:16.43+00:00 GerryNicol The error “The user name or password is incorrect” during Entra Domain Services domain join usually indicates that the account being used does not have NTLM/Kerberos password hashes available in AAD DS, even if it is in AAD DC Administrators and password hash sync is enabled.
In your case, the likely issue is the source of the user accounts. Accounts with a source of “Microsoft account” or “External Azure Active Directory (Guest)” cannot generate the required NTLM/Kerberos password hashes for AAD DS, so domain join will always fail with a credentials error. This is a known limitation of Azure AD Domain Services.
To resolve this:
- Create a native Entra ID (Azure Active Directory) user
- Reset the password (this triggers hash generation)
- Wait 15–20 minutes for password hash synchronization to AAD DS
- Add the user to AAD DC Administrators
- Use this account to join the VM
Once you use a native AAD account (source = Azure Active Directory), domain join succeeds because only these accounts fully synchronize the required password hashes to Entra Domain Services Ensure that you are using credentials for a user account that is part of the managed domain. If you are using a cloud-only account, the user must change their password to generate the necessary password hashes for Kerberos and NTLM authentication.
-
GerryNicol • 6 Reputation points
2025-12-11T16:30:14.36+00:00 My accounts being used are cloud only
-
GerryNicol • 6 Reputation points
2025-12-11T16:45:04.17+00:00 I just tested created a brand new cloud only account and that has worked. The existing cloud only accounts which I followed the same process for don't work
-
VEMULA SRISAI • 3,500 Reputation points • Microsoft External Staff • Moderator
2025-12-11T17:04:52.4766667+00:00 This behavior is expected in some cases with Azure AD Domain Services (AAD DS). A newly created cloud‑only user works because its NTLM/Kerberos password hashes are generated immediately when you set the initial password after AAD DS is already enabled.
For older cloud‑only users, even if they appear similar, their password hashes may not regenerate correctly unless a full password change (not reset) is performed after AAD DS is provisioned. AAD DS can only synchronize hashes created after its deployment.
To fix the older accounts:
What you need to do
- Have the affected user perform an actual password change themselves (not an admin reset).
- Password change = works
- Password reset = may not regenerate classic hashes
- Wait 20–30 minutes for AAD DS to sync the updated NTLM/Kerberos credentials.
- Try the domain join again using
******@domain.com.
- Password change = works
This forces Entra ID to generate the required legacy authentication hashes and synchronize them to your managed domain.
Why a new user worked
New cloud‑only users created after AAD DS was enabled always generate the correct password hashes on first-time password setup that’s why they join successfully immediately.
- Have the affected user perform an actual password change themselves (not an admin reset).
-
GerryNicol • 6 Reputation points
2025-12-11T17:07:41.4066667+00:00 That wasnt the issue. The issue appears to be that the two previous cloud only accounts i was using (even though they have beed added to the AAD DC Admin group) were not synced? I can see that now that I have access to ADUC
-
VEMULA SRISAI • 3,500 Reputation points • Microsoft External Staff • Moderator
2025-12-11T17:40:38.66+00:00 GerryNicol Even though the two older cloud‑only accounts were added to AAD DC Administrators, they were never synchronized into Azure AD Domain Services (AAD DS). Because AAD DS uses its own managed domain with a one‑way object sync, an account must fully synchronize into the AAD DS directory before it can authenticate during a VM domain join.
If the users weren’t synced into AAD DS, they simply do not exist in the managed domain so AAD DS treats the login as invalid and returns “The user name or password is incorrect.”
By checking ADUC and not seeing those accounts present, you confirmed the root cause.
Why the new cloud‑only user worked
A brand‑new cloud‑only user automatically:
- Generates fresh password hashes
- Syncs into the managed domain (AAD DS)
- Appears in ADUC
- Can authenticate successfully
This is why the domain join succeeded for that account but not for the older ones.
How to fix older cloud‑only accounts
To force these older users to sync into AAD DS:
- Have the user perform a full password change (not an admin reset).
- Wait 20–30 minutes for AAD DS to pull the updated credentials into the managed domain.
- Verify the account appears under AAD DC Users in ADUC.
- Retry the domain join.
Once the accounts exist inside the managed domain, VM join succeeds as expected.
-
GerryNicol • 6 Reputation points
2025-12-11T19:37:50.1066667+00:00 The above was done - I already confimred that. A password reset was done on two seperate accounts on multiple occassions.
-
VEMULA SRISAI • 3,500 Reputation points • Microsoft External Staff • Moderator
2025-12-12T11:12:10.05+00:00 GerryNicol Thanks for confirming. If you already reset the passwords multiple times and the users were still not appearing in Azure AD Domain Services, then the root cause is that those cloud-only accounts were never synchronized into the managed domain at all, despite the password resets.
This happens when the accounts were created before AAD DS was enabled and never had a valid legacy password hash generated for AAD DS. Even after resetting the password, AAD DS sometimes won’t sync the account until:
Password hash sync is re-triggered for the user (another password reset from the Entra portal normally forces it)
AAD DS completes its internal replication cycle (which can take 20–40 minutes after the hash is ready)
The user object is re-evaluated for inclusion in the managed domain
This is why you could finally see the accounts in ADUC, and once they appeared there, domain join immediately started working.
GerryNicol could you please refer to this document https://dori-uw-1.kuma-moon.com/en-us/troubleshoot/entra/entra-id/mfa/user-name-pwd-incorrect
Sign in to comment