Debug logon loop for windows 2025 RDS server on-premise in workgroup, using Azure ARC enabled server and AADLogin extension version 2.2.0

Question

Debug logon loop for windows 2025 RDS server on-premise in workgroup, using Azure ARC enabled server and AADLogin extension version 2.2.0

dummys 45

Hello, I have a strange issue on connecting using AAD login to the RDP server that has a system-assigned managed identity and the AADLogin extension installed successfully. The user has the Virtual Machine Local User Login role, using mstsc.exe and select the "use a web account to sign in to the remote computer" checkbox, the user is also member on the server of the group: Hybrid agent extension applications. I use the logon like this: ******@mydomain.xx and I get the following error and a logon loop that always goes back to the logon page from ms365: Logon failure. Status: 0xC0000022 Correlation ID: an id

Inside azure sign-in audit on the user I get this:

Password Pass-through Authentication; PTA AgentId: ID true User approved

So for me the logon from AzureAD is successfull. I need help to debug further. thanks

0 comments

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Suchitra Suregaunkar 11,150 Microsoft External Staff Moderator

Hello dummys It looks like your Azure AD authentication (PTA) is working but the RDP session is getting stuck in a logon loop with 0xC0000022, which usually means the AADLoginForWindows extension or local validation isn’t authorizing the user on the server side. Let’s walk through some targeted debugging steps:

Verify the AADLoginForWindows extension completed successfully: • On the RDS host, open C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\2.2.0\CommandExecution.log and look for any ERROR or WARNING entries during install or startup. • If you see repeated restarts or failure messages, note the timestamp and full error.
Check the device’s Azure AD join and PRT status: • On the server, run from an elevated prompt: dsregcmd /status • Ensure under “Device State”: – AzureAdJoined : YES – AzureAdPrt : YES • If either is NO, the extension didn’t finish the join – share that output.
Test the local managed-identity endpoints : • In an elevated PowerShell on the server run: curl.exe -H Metadata:true "http://localhost:40342/metadata/identity/info?api-version=2018-02-01" curl.exe -H Metadata:true "http://localhost:40342/metadata/identity/oauth2/token?resource=urn:ms-drs:enterpriseregistration.windows.net&api-version=2018-02-01" • You should get JSON back for the identity info and a valid access token. If not, the hybrid IMDS service isn’t reachable or running.
Validate network connectivity to Azure AD endpoints: • From the server: curl https://login.microsoftonline.com/ -D - curl https://enterpriseregistration.windows.net/ -D - curl https://pas.windows.net/ -D - • All should return at least a 200 or 404 (per docs). If you see DNS or timeout errors, update your DNS or proxy settings.
Confirm required local policy for PKU2U auth : • On both server and client, open secpol.msc → Security Settings → Local Policies → Security Options → “Network security: Allow PKU2U authentication requests to this computer to use online identities” → set to Enabled. • Reboot or gpupdate /force after changing.
Review the AAD operational event log : • On the server look under Event Viewer → Applications and Services Logs → Microsoft → Windows → AAD → Operational. • Find the logon attempt entries—any error codes or messages here can pinpoint why the extension is declining the session.
Check Azure RBAC role assignment: • Verify that the user is assigned the built-in “Virtual Machine User Login” (or “Virtual Machine Administrator Login” if you need admin rights) role under your Arc-enabled server’s Access control (IAM).
• The “Virtual Machine Local User Login” role you mentioned isn’t one of the documented built-in roles for AADLoginForWindows, so please double-check the exact role name.
Try the alternate RDP user format (if client is only registered) : • If your client is Azure AD registered (not joined), you must connect as AzureAD[******@domain.com](******@domain.com) rather than just ******@domain.com.

Follow-up questions/logs to gather next:

• Paste the full dsregcmd /status output from both server and client.

• Share any ERROR-level entries from CommandExecution.log around your last sign-in attempt.
• Capture a screenshot or log of the AAD Operational events for that RDP session.

• Confirm the exact Azure RBAC role name and show its assignment on the server’s IAM blade.

References

Resolve Microsoft Entra login extension issues https://docs.microsoft.com/azure/virtual-machines/extensions/azure-ad-login#resolve-azure-active-directory-login-extension-issues
Sign in to an Azure Arc-enabled server using Microsoft Entra ID and Azure RBAC https://docs.microsoft.com/entra/identity/devices/howto-arc-sign-in-windows#troubleshoot-deployment-problems
Troubleshoot sign-in problems (RDP via Azure AD) https://docs.microsoft.com/entra/identity/devices/howto-arc-sign-in-windows#troubleshoot-sign-in-problems

Thanks,

Suchitra.

dummys 45 Reputation points

2026-03-18T14:01:29.74+00:00

I checked everything the Q&A AI agent told me. Just to add that my user workstation were I try to login from using mstsc is AzureAD joined only, but the user is synced from Active Directory on-prem to the AzureAD. My goal is to get rid of the on-prem active directory for everything, but we still need to keep RDS server on-prem using workgroup because of the application on it can't be in cloud.

dummys 45

Dear Suchitra,

1.

The path: C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\2.2.0\CommandExecution.log doesn't exist on the server. Even the C:\Windows\Azure folder doesn't exist. I found the following folder: C:\Packages\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\2.2.0.0 and C:\ProgramData\GuestConfig\extension_logs\Microsoft.Azure.ActiveDirectory.AADLoginForWindows

AzureADPRT:NO here is the full output:

PS C:\Users\Administrator> dsregcmd /status
+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+
             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : NO
           Virtual Desktop : NOT SET
               Device Name : SRV
+----------------------------------------------------------------------+
| Device Details                                                       |
+----------------------------------------------------------------------+
                  DeviceId :
                Thumbprint :
 DeviceCertificateValidity : [ 2026-03-05 15:08:44.000 UTC -- 2036-03-05 15:38:44.000 UTC ]
            KeyContainerId :
               KeyProvider : Microsoft Software Key Storage Provider
              TpmProtected : NO
          DeviceAuthStatus : SUCCESS
+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+
                    NgcSet : NO
           WorkplaceJoined : NO
             WamDefaultSet : NO
+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+
                AzureAdPrt : NO
       AzureAdPrtAuthority :
     AcquirePrtDiagnostics : PRESENT
      Previous Prt Attempt : 2026-03-18 15:20:12.600 UTC
            Attempt Status : 0xc004844c
             User Identity : administrator
           Credential Type : Password
            Correlation ID : 5bbf61c2-ff45-4f2e-abc6-3a2959e4edaf
             EnterprisePrt : NO
    EnterprisePrtAuthority :
+----------------------------------------------------------------------+
| Diagnostic Data                                                      |
+----------------------------------------------------------------------+
        AadRecoveryEnabled : NO
    Executing Account Name : SRV\Administrator
               KeySignTest : PASSED
        DisplayNameUpdated : YES
          OsVersionUpdated : YES
           HostNameUpdated : YES
      Last HostName Update : NONE
+----------------------------------------------------------------------+
| IE Proxy Config for Current User                                     |
+----------------------------------------------------------------------+
      Auto Detect Settings : YES
    Auto-Configuration URL :
         Proxy Server List :
         Proxy Bypass List :
+----------------------------------------------------------------------+
| WinHttp Default Proxy Config                                         |
+----------------------------------------------------------------------+
               Access Type : DIRECT
+----------------------------------------------------------------------+
| Ngc Prerequisite Check                                               |
+----------------------------------------------------------------------+
            IsDeviceJoined : YES
             IsUserAzureAD : NO
             PolicyEnabled : YES
          PostLogonEnabled : YES
            DeviceEligible : NO
        SessionIsNotRemote : NO
            CertEnrollment : none
              PreReqResult : WillNotProvision
For more information, please visit https://www.microsoft.com/aadjerrors
PS C:\Users\Administrator>

The first curl command give me my tenant id and the second one didnt work:

PS C:\Users\Administrator> curl.exe -H Metadata:true "http://localhost:40342/metadata/identity/oauth2/token?resource=urn:ms-drs:enterpriseregistration.windows.net&api-version=2018-02-01"
{"error":"invalid_request","error_description":"The api-version '2018-02-01' could not be found. Supported are 2021-02-01 2020-06-01 2019-11-01 2019-08-15","error_codes":[404],"timestamp":"2026-03-19 19:14:50.1209985 +0100 CET m=+105352.656678501","trace_id":"","correlation_id":"0740714a-5517-4090-b55b-591731bd79b1"}
PS C:\Users\Administrator> curl.exe -H Metadata:true "http://localhost:40342/metadata/identity/oauth2/token?resource=urn:ms-drs:enterpriseregistration.windows.net&api-version=2021-02-01"
{"error":"unauthorized_client","error_description":"Missing Basic Authorization header","error_codes":[401],"timestamp":"2026-03-19 19:15:07.8122278 +0100 CET m=+105370.347399201","trace_id":"","correlation_id":"81b59850-4d5c-4e27-9246-3da3c48f1f67"}

All 200 5.Sure its on on both client/server and rebooted

Error: 0x4AA50081 An application specific account is loading in cloud joined session.
Logged at ClientCache.cpp, line: 407, method: ClientCache::LoadPrimaryAccount.

AAD Cloud AP plugin call GenericCallPkg returned error: 0xC0048512

DoGetToken Diagnostic Event:
Result: 0xC0000022
User Identity: redacted
Credential Type: 8
Correlation ID: 10d924d1-c1ea-4c0e-be22-a665841c5d83
Endpoint Uri: https://pas.windows.net/CheckMyAccess?api-version=2018-01-01
HTTP Status: 
HTTP Method: The operation completed successfully.
ErrorCode: 200
Error Description: 

Logon failure. Status: 0xC0000022 Correlation ID: 10d924d1-c1ea-4c0e-be22-a665841c5d83

PRT session key needs to be rolled.
Reason: VSM key rollover

On-prem tgt error: On-prem configuration is missing

dummys 45 Reputation points

2026-03-19T18:36:37.41+00:00
sorry I have to continue on another post, as my browser is crashing when I want to edit my old post.

7.

are you talking about using: AzureAD\******@mydomain.com or something else ?
dummys 45 Reputation points

2026-03-24T09:19:37.6966667+00:00

@Suchitra Suregaunkar any ideas ?
Suchitra Suregaunkar 11,150 Reputation points Microsoft External Staff Moderator

2026-03-25T02:23:52.0433333+00:00
Thanks for sharing the logs.

From your logs Azure sign‑in (PTA) succeeds.

Azure sign‑in logs show Password Pass‑through Authentication – User approved

Arc agent + AADLoginForWindows extension is installed and Machine is Azure AD joined.

AzureAdJoined : YES and DomainJoined : NO

Hybrid IMDS endpoint is reachable, Tenant metadata query works, Client PKU2U policy is enabled and Network access to login.microsoftonline.com / pas.windows.net is OK

So authentication to Entra ID is not the problem.

Below are the blockers which is not working:

AzureAdPrt = NO (this is fatal for RDP Entra login)

From dsregcmd /status on the server:

AzureAdPrt : NO Attempt Status : 0xc004844c PRT session key needs to be rolled. Reason: VSM key rollover On-prem tgt error: On-prem configuration is missing

AADLoginForWindows requires a valid Primary Refresh Token (PRT) on the target machine. If PRT cannot be issued → logon succeeds in Entra → local authorization fails → RDP loop → 0xC0000022.

PRT is mandatory for Entra ID–based RDP on Arc-enabled Windows servers.

The PRT failure is expected in your configuration

Key facts from your environment:

Server is workgroup

User is synced from on‑prem AD

Authentication method is PTA

No on‑prem AD trust / Kerberos path available

No Entra Kerberos server / cloud trust configured

The error confirms this:

On-prem tgt error: On-prem configuration is missing which means the CloudAP plug‑in tried to acquire a Kerberos‑backed PRT, but there is no on‑prem TGT / Kerberos trust available, so the PRT cannot be completed.

This is a limitation, not a misconfiguration.

Why Azure sign‑in succeeds but RDP fails

This distinction is critical: AADLoginForWindows does not use raw OAuth tokens for Windows logon. It requires PRT → CloudAP → LSASS authorization.

Without PRT → Windows refuses logon after web sign‑in completes.

Your IMDS token test failed:

You ran:

curl http://localhost:40342/metadata/identity/oauth2/token

Result: "unauthorized_client" "Missing Basic Authorization header"

This is normal because the Arc hybrid IMDS endpoint is not equivalent to Azure VM IMDS. AADLoginForWindows does not use managed identity OAuth tokens for RDP logon.

RDP relies on CloudAP + PRT, not MSI tokens.

Windows Server 2025 + Arc does NOT remove AD in your scenario:

Your stated goal which is to get rid of the on‑prem AD entirely, but keep an on‑prem RDS server in a workgroup. This is not currently supported for synced users using PTA.

AADLoginForWindows on Arc requires one of the following:

Cloud‑only Entra ID users

Hybrid users with Kerberos path available

Azure VM (not Arc) with Entra join

Your setup is none of the above.

Please have a look into below limitations:

Synced users without Kerberos trust cannot obtain PRT

PTA alone is insufficient for Windows logon

Workgroup Arc servers still require Entra‑Kerberos backing for hybrid users

As a workaround please have a look into below provided supported resolution paths:

Use cloud‑only Entra ID users

Create Entra‑native users (not synced)

Assign Virtual Machine User Login

Log in as: AzureAD[******@tenant.onmicrosoft.com](******@tenant.onmicrosoft.com)

This works today with Arc + workgroup.

Keep AD but enable Entra Kerberos (Cloud Trust)

Requires:

On‑prem AD retained

Kerberos trust enabled

Allows hybrid users to obtain PRT Supported, but does not meet your “no AD” goal

PTA + synced users + workgroup Arc server which is Not supported and Results exactly in:

AzureAdPrt = NO

On-prem tgt error

RDP logon loop.

Thanks,
Suchitra.
Suchitra Suregaunkar 11,150 Reputation points Microsoft External Staff Moderator

2026-03-25T02:25:27.33+00:00

Hello dummys

Could you please let us know if the comment above resolved your issue? If you need any further assistance, feel free to reach out—we're always here to support you.

If you found the comment helpful, please consider clicking "Upvote it."

Thanks,
Suchitra.
dummys 45 Reputation points

2026-03-25T08:41:54.49+00:00
dear Suchitra,

My goal is to migrate totally to the cloud-only users. The problem is that I have to do it smoothly.

What is the best solution to migrate smoothly ?

I also read about Cloud Sync: https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/connect-to-cloud-sync-decision-guide Maybe it's better to migrate to this before ? Is it better than Cloud trust ?

In first I just Keep AD but enable Entra Kerberos (Cloud Trust)

And then when I'm ready to remove active directory on-prem, I do the migration, remove the Adconnect and move all my users to the cloud ?

Now to enable entra kerberos, what is the easiest way to do it, as we know in our case it will be temporary for 1 month until we fully migrate everything to the cloud.

Just to do a simple test, I created a user cloud-only and tried to logon from an other ARC-Enabled server using mstsc:

My user when I'm trying to log: AzureAD\******@domain.xx But the microsoft sign-in popup seems to not find this user in my tenant. so I'm not sure if we must use AzureAD\ or I mislead something. and also we are ok that we need to tick this box:

Here is the log I get:

An account failed to log on. Subject: Security ID: NETWORK SERVICE Account Name: SRV-TS-1$ Account Domain: WORKGROUP Logon ID: 0x3E4 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: - Account Domain: - Failure Information: Failure Reason: An Error occured during Logon. Status: 0xC000006D Sub Status: 0xC0000022 Process Information: Caller Process ID: 0x4e4 Caller Process Name: C:\Windows\System32\svchost.exe

Edit: Tried with cloud only user from AADJoined workstation with Windows 11 latest patch -> bootloop
dummys 45 Reputation points

2026-03-25T10:45:52.45+00:00

EDIT: I found the problem. You have to not use the role: Virtual Machine Local User Login but the one called "Virtual Machine User Login" and it works, with cloud-only user and Hybrid joined user.

My next question is: Can I now remove the Active Directory to migrate to a full-cloud infrastructure, or do I need first migrating the Azure Ad connect to the Cloud Sync, and then finally removing all the remaining AD infrastructure ?
Suchitra Suregaunkar 11,150 Reputation points Microsoft External Staff Moderator

2026-03-25T17:47:21.63+00:00
Hello dummys

Microsoft Entra Cloud Sync (like Entra Connect Sync) is only required while you still rely on on‑prem AD identities. If your end goal is a cloud‑only identity model, Cloud Sync is not a prerequisite and doesn’t provide additional value once AD is no longer needed.

Please have a look into below provided recommended smooth migration approach:

Keep AD temporarily as a bridge, using your existing sync (no need to switch to Cloud Sync mid‑migration).

Start creating and piloting cloud‑only Entra ID users and validate they can:

Sign in to Azure Arc–enabled servers using Entra ID

Access required applications and services

Gradually migrate users and workloads away from hybrid dependencies (Kerberos/LDAP/NTLM, GPO‑only settings).

Once no synced users remain, disable Entra Connect / Cloud Sync.

Finally, decommission on‑prem AD when nothing depends on it.

This sequencing avoids unnecessary changes while you’re still stabilizing access and keeps rollback simple.

Cloud Kerberos trust is designed as a temporary bridge for hybrid users who still depend on AD‑backed Kerberos. Since you’ve confirmed that cloud‑only users now work with the correct Azure role, you don’t need Cloud Kerberos trust once you complete the migration to cloud‑only identities.

Now that Entra ID RDP works with the correct role, the best path is to migrate users to cloud‑only first, then turn off sync, and remove AD last. Cloud Sync isn’t required if AD is going away.

Thanks,
Suchitra.
dummys 45 Reputation points

2026-03-26T09:02:00.1033333+00:00

excellent thanks for information. May I ask you why every tutorial on microsoft told about "Virtual Machine Local User Login" but it's only the "Virtual Machine User Login" that worked in my case ?

Also can you explain how to migrate existing user from hybrid-synced to cloud-only user ?
Suchitra Suregaunkar 11,150 Reputation points Microsoft External Staff Moderator

2026-03-26T15:36:54.43+00:00
Hello dummys

Thanks for responding back.

The key reason is that these two roles serve different authentication paths, and only one of them is actually supported for Microsoft Entra ID–based sign‑in.

Virtual Machine User Login and Virtual Machine Administrator Login are the only supported Azure RBAC roles for signing in to Azure VMs and Azure Arc–enabled servers using Microsoft Entra ID.

These roles integrate with the AADLoginForWindows / Entra sign‑in extension, which performs Entra authentication and then authorizes the user locally.

By contrast:

Virtual Machine Local User Login is intended for local OS accounts, not Entra ID identities.

It does not correctly authorize Entra ID users and can lead to access‑denied errors or logon loops, even when authentication itself succeeds.

This is why switching to Virtual Machine User Login immediately resolved the issue for both cloud‑only and hybrid users in your case.

How to migrate existing users from hybrid‑synced to cloud‑only?

There is no in‑place “convert” button, but Microsoft supports a gradual, low‑risk migration approach.

Keep AD and sync temporarily (bridge phase) Continue running Entra Connect Sync (or Cloud Sync if already in use) while you prepare users. There’s no requirement to move to Cloud Sync if your end goal is full cloud‑only.

Create cloud‑only users in Microsoft Entra ID

Create new users directly in Entra ID (not synced from AD).

Assign the required Azure roles (for example, Virtual Machine User Login for Arc servers).

Migrate user workloads

Move mailboxes to Exchange Online (if not already).

Ensure Teams, OneDrive, SharePoint, and application access works with the cloud‑only account.

Validate RDP access to Azure Arc–enabled servers using Entra ID.

Gradually stop using hybrid identities

As users successfully move to cloud‑only accounts, they no longer depend on on‑prem AD authentication.

Hybrid users can coexist with cloud‑only users during this phase.

Disable synchronization

Once no users or groups need to be synced, disable Entra Connect Sync or Cloud Sync.

At this point, all identities are cloud‑only and Entra ID becomes the sole authority.

Decommission Active Directory

Only after confirming no applications, servers, or authentication flows depend on AD.

Azure Arc–enabled servers can remain Entra‑joined without AD.

Cloud Sync and Entra Connect are only needed while AD is still authoritative. They are not required and not useful, once you move to a pure cloud‑only identity model.

Reference: https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync

Entra Kerberos (cloud trust) is designed as a temporary bridge for hybrid identities that still rely on Kerberos. Since you’ve confirmed that cloud‑only users work correctly with Azure Arc, cloud trust is not required once you complete the migration away from hybrid users.

Reference: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune

Thanks,

Suchitra.
Suchitra Suregaunkar 11,150 Reputation points Microsoft External Staff Moderator

2026-03-26T15:37:39.8433333+00:00

Hello @dummys

If the answer is helpful, could you please click "upvote" and "ACCEPT ANSWER" it and this helps other community members who may encounter a similar issue in the future.

If you’re still experiencing the problem or need further clarification, please feel free to share additional information so we can continue investigating and assist you further.

Thanks,

Suchitra.

Answer 2

Mike James 0

I also experienced this issue and it was resolved by the recent KB5085516 released on 21st March.

dummys 45 Reputation points

2026-03-25T09:16:26.35+00:00

tried the patch, but already installed unfortunately

Share via

Debug logon loop for windows 2025 RDS server on-premise in workgroup, using Azure ARC enabled server and AADLogin extension version 2.2.0

1 additional answer

Your answer