unable to login to Entra ID joined machines

Question

unable to login to Entra ID joined machines

M365 0

We have a domain federated with ADFS. we are able to join machine to Entra ID; however, unable to login to azure ad joined machines. its says username or password incorrect.

we can see from dsregcmd/status that the endpoint URI is not the ADFS URL. its the Microsoft endpoint.

Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-06-23T08:01:01.7733333+00:00
Hey! From what you described, this sounds like an authentication/sign-in failure to Microsoft Entra joined (AADJ) VMs where the UI reports “username or password incorrect” even though the device shows it’s using the expected Microsoft authentication endpoints (not the AD FS URL). In these scenarios, the most common thing to validate is whether the device has a working Entra sign-in state (PRT) and whether required connectivity/policy requirements for the VM sign-in flow are satisfied.

What to check on the Entra joined VM

1) Confirm the device sign-in/SSO state (PRT)

On the affected VM, run:

dsregcmd /status

Look for:

Device State

AzureAdJoined: YES

Single Sign-On State

AzureAdPrt: YES

If AzureAdPrt is NO (or not refreshing), sign-in can fail and may present as “credentials didn’t work / incorrect”.

Also check whether the AzureAdPrtUpdateTime is stale (stops refreshing). The PRT typically renews (refreshes) regularly.

2) Verify required Microsoft Entra endpoints are reachable

From the VM, ensure the VM can reach the required endpoints (no proxy/firewall/network rewrite issues). The documentation calls out these checks:

https://login.microsoftonline.com/

https://login.microsoftonline.com/<TenantID>/

https://enterpriseregistration.windows.net/

https://device.login.microsoftonline.com/

If these can’t be reached reliably, the Entra join/sign-in experience can degrade.

3) Check PKU2U policy on both sides (server + client)

The docs note you must ensure the Windows security policy:

“Network security: Allow PKU2U authentication requests to this computer to use online identities”

is enabled on both the server (VM) and the client initiating the sign-in (for RDP scenarios that rely on this).

4) Consider Conditional Access / MFA interactions

The guidance for Entra joined VM sign-in troubleshooting includes an important note:

There is currently no support for single sign-on and external identities

Also, if MFA is enforced for users/groups, make sure the sign-in method is compatible. The docs specifically call out that for successful MFA + Entra VM scenarios you may need to address the legacy per-user MFA sign-in method and Conditional Access exclusions (depending on your CA setup).

Why AD FS federation might not be relevant here

Even if your domain is federated with AD FS for browser-based sign-in, Entra joined VM sign-in relies on device authentication and Entra endpoints/PRT, not AD FS being used as the primary endpoint for VM auth. So the fact you’re seeing the Microsoft endpoint in dsregcmd/status aligns with the expected architecture.

Reference list (relevant documentation)

Authentication - AADJ (Troubleshoot issues signing in to Microsoft Entra joined virtual machines): https://learn.microsoft.com/azure/virtual-desktop/troubleshoot-azure-ad-connections

Sign in to Windows virtual machine in Azure using Microsoft Entra ID and Azure Roles Based Access Control (troubleshoot sign-in problems, dsregcmd goals, PKU2U note): https://learn.microsoft.com/entra/identity/devices/howto-vm-sign-in-azure-ad-windows

Configure Microsoft Entra join and troubleshoot Primary Refresh Token (PRT) issues (PRT checks + dsregcmd guidance): https://learn.microsoft.com/entra/identity/devices/troubleshoot-primary-refresh-token
Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-06-25T01:31:12.4133333+00:00

M365

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

1 answer

Your answer

Shubham Sharma 17,925 Reputation points Microsoft External Staff Moderator

2026-06-25T01:31:12.4133333+00:00

M365

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

Answer 1

For federated tenants, Microsoft Entra sign-in for Azure AD–joined devices still uses Microsoft’s endpoints as the primary authority; WS-Trust/AD FS is used behind the scenes for federated authentication. Seeing a Microsoft endpoint URI in dsregcmd /status is expected and not, by itself, the cause of the “username or password is incorrect” error.

Use the following checks and tools from the referenced guidance to narrow down the issue:

Verify the device is actually Azure AD joined and healthy
On the problem device, run:
```
   dsregcmd /status
```
Confirm:
- AzureAdJoined : YES
- DomainJoined / WorkplaceJoined values match the intended state (for pure Azure AD joined, DomainJoined should be NO).
  If AzureAdJoined : NO, the join is incomplete; follow the “Troubleshoot join failures” flow to find the error phase and code.
If join is failing or incomplete, locate the error phase and code
From the hybrid join troubleshooting flow (also applicable for Azure AD join diagnostics):
- On Windows 10/11 1803 or later, in dsregcmd /status look under Diagnostic Data → Previous Registration for:
  - Error Phase
  - Client ErrorCode
- On earlier builds, check Event Viewer:
  - Applications and Services Logs → Microsoft → Windows → User Device Registration → Admin
  - Look for events 304, 305, 307.
Check for network / WS-Trust / AD FS–related errors
For federated auth, failures often surface as STATUS or HTTP errors:
- In Microsoft Entra operational logs and analytics logs on the client, look for:
  - STATUS_NETWORK_UNREACHABLE, STATUS_BAD_NETWORK_PATH, or STATUS_UNEXPECTED_NETWORK_ERROR
    These indicate HTTP > 400 from Microsoft Entra auth service or WS-Trust endpoint, or network connectivity issues to required endpoints.
  - Event 1081 and 1088 (operational) for server error codes and WS-Trust error descriptions.
  - Event 1022 (analytics) for the URL being accessed.
  - Event 1084 (operational) for suberror codes from the network stack.
- If the user realm discovery fails with STATUS_NO_SUCH_LOGON_SESSION, verify:
  - The user’s UPN domain is added as a custom domain in Microsoft Entra ID.
  - If on-prem domain is nonroutable (for example, user@contoso.local), configure Alternate Login ID (AltID) as per the referenced prerequisites.
Confirm correct username format at the Windows sign-in screen
For cloud sign-in to Azure AD–joined devices, the username must be the full UPN, not domain\user or short name. For example:
- ******@contoso.com
  Using user or contoso\user will fail in the same way as described for PowerShell sign-in: the format must be <user_name>@<domain>.
Validate that the user can authenticate to Microsoft Entra ID directly
Since the tenant is federated, confirm that the same user can:
- Sign in to a cloud app (for example, Microsoft 365) using the same UPN and password.
- If cloud sign-in works but device sign-in fails, focus on device registration/join and WS-Trust/AD FS logs as above.
If using hybrid join, ensure the device is also domain joined
For hybrid-joined scenarios, DomainJoined must be YES in dsregcmd /status. If it is NO, hybrid join cannot complete, and Azure AD sign-in will not function as expected.
Review AD FS and WS-Trust configuration
Because the tenant is federated:
- Ensure the WS-Trust endpoints used for device authentication are reachable from the device.
- Use the error codes from events 1081/1088 and the STATUS codes in the table to map to specific server/network issues and remediate accordingly (for example, fixing AD FS endpoint availability, certificates, or proxy/firewall rules).

Once the device shows AzureAdJoined : YES, the UPN domain is correctly configured in Entra ID, and WS-Trust/AD FS endpoints are reachable (no STATUS/HTTP > 400 errors in the logs), Azure AD sign-in to the joined machine should succeed using the user’s full UPN and password.

References:

unable to login to Entra ID joined machines

What to check on the Entra joined VM

1) Confirm the device sign-in/SSO state (PRT)

2) Verify required Microsoft Entra endpoints are reachable

3) Check PKU2U policy on both sides (server + client)

4) Consider Conditional Access / MFA interactions

Why AD FS federation might not be relevant here

Reference list (relevant documentation)

1 answer

Your answer