Standard users suddenly can't connect to a Windows 11 PC over Remote Desktop, the client reports "The token that was passed to the function is invalid", and administrators connect fine. That combination is a documented Windows known issue tied to Administrator protection, the just-in-time elevation feature that Windows security baselines now turn on. In this post I'll cover what Microsoft has published, which builds fix it, how to find the Intune or Group Policy setting that enabled the feature, and how to use the workaround only where you need it.
Errors this guide fixes
0xC000000DRemote Desktop Connection clientThe token that was passed to the function is invalid.Remote Desktop Connection client
Status (November 2026): Microsoft opened this issue on Windows release health on 13 October 2026 for Windows 11 versions 24H2, 25H2, 26H1 and 26H2 (no server versions). Originating update: the September 2026 non-security preview update (KB5124010; KB5124006 on 26H1) and later updates. It's marked Resolved for 25H2 and 26H2 by KB5127936 and for 26H1 by KB5127653, both released 28 October 2026. The 24H2 entry, last updated 21 October, still shows Mitigated with a workaround; 24H2 no longer gets non-security preview updates, so watch for a later security update. Re-check the release health pages, because statuses change.
Symptoms#
As documented by Microsoft:
- After KB5124010 or a later update is installed on the remote device, users who aren't administrators might be unable to establish a Remote Desktop connection to it.
- The connection fails with error
0xC000000Dand the message:TextThe token that was passed to the function is invalid. - It mainly affects enterprise-managed devices used as Remote Desktop hosts that have Administrator protection enabled, regardless of how the feature was turned on.
In practice the pattern is easy to spot: one host fails for every standard user, works for members of its local Administrators group, and the failures started after the host (not the client) received the late-September preview or the October security update.
Why it happens#
Administrator protection keeps every user, including local administrators, on a deprivileged token and creates a temporary, isolated admin token only when the user approves an elevation. Microsoft hasn't published more detail about the root cause of the Remote Desktop failure than "devices that have Administrator protection enabled". What it has published is why so many fleets suddenly have the feature on: the Windows security baselines for 24H2, 25H2 and 26H2 enable Administrator protection by default, and Microsoft's Administrator protection page says organizations that use those baselines get it with the October 2026 Windows security update unless their policy says otherwise.
The feature is controlled by two settings in the Local Policies Security Options category of the Settings catalog: User Account Control Type Of Admin Approval Mode (turns it on) and User Account Control Behavior Of the Elevation Prompt for Administrator Protection. They map to UserAccountControl_TypeOfAdminApprovalMode and UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection in the LocalPoliciesSecurityOptions CSP, and to User Account Control: Configure type of Admin Approval Mode in Group Policy.
How to fix it#
1. Check the host's build first#
The fix is on the remote device, so check the host, not the user's PC:
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
'{0} {1}.{2}' -f $cv.DisplayVersion, $cv.CurrentBuild, $cv.UBR| Version | Affected from | Fixed in |
|---|---|---|
| 26H2 | KB5124010 (26300.9550) | KB5127936 (26300.9818) or later |
| 25H2 | KB5124010 (26200.9550) | KB5127936 (26200.9818) or later |
| 26H1 | KB5124006 | KB5127653 or later |
| 24H2 | KB5124010 (26100.9550) | No resolving update listed yet: use the workaround |
On 25H2 and 26H2 the cleanest fix is to deploy KB5127936. It's an optional preview, so either approve it for your Remote Desktop hosts or wait for the next monthly security update, which normally carries the preview's fixes. Confirm in the KB for that update before you rely on it.
2. Find out what enabled Administrator protection#
Microsoft's workaround is to turn the feature off with the same management method that turned it on. In the Microsoft Intune admin center, search your Settings catalog profiles for "Type Of Admin Approval Mode", and check custom profiles for the CSP name. This Graph PowerShell sketch lists both:
Connect-MgGraph -Scopes 'DeviceManagementConfiguration.Read.All'
$base = 'https://graph.microsoft.com/beta/deviceManagement'
foreach ($p in (Invoke-MgGraphRequest -Method GET -Uri "$base/configurationPolicies").value) {
$s = (Invoke-MgGraphRequest -Method GET -Uri "$base/configurationPolicies/$($p.id)/settings").value
if (($s | ConvertTo-Json -Depth 20) -match 'typeofadminapprovalmode') { "Settings catalog: $($p.name)" }
}
(Invoke-MgGraphRequest -Method GET -Uri "$base/deviceConfigurations").value |
Where-Object { $_.omaSettings.omaUri -match 'TypeOfAdminApprovalMode' } |
ForEach-Object { "Custom OMA-URI: $($_.displayName)" }Both calls return the first page only; follow @odata.nextLink in large tenants. For domain-joined hosts, run gpresult /h report.html and look for the Security Options policy above: a GPO built from the Security Compliance Toolkit baseline is the most likely source.
3. Apply the workaround only to the hosts that need it#
For hosts that can't take a fixed build yet (all 24H2 hosts today), reset the Admin Approval Mode type to the legacy value:
- Intune: create a device group of affected Remote Desktop hosts, exclude it from the policy that enables Administrator protection, and assign a small Settings catalog profile that sets User Account Control Type Of Admin Approval Mode back to legacy Admin Approval Mode. An explicit setting is easier to track and reverse than a plain unassignment.
- Group Policy: set User Account Control: Configure type of Admin Approval Mode to Legacy Admin Approval Mode (Default) in a GPO linked to those hosts, or adjust the baseline GPO for them.
A restart is required for the change to take effect. Keep the scope tight: on everyday user devices, Administrator protection is doing its job and this bug doesn't touch them.
4. Re-enable once the host is fixed#
When a host reaches a fixed build, remove it from the exclusion group so the original policy applies again, and restart it.
Verify the fix#
- A standard (non-admin) user connects to the host over Remote Desktop without the
0xC000000Derror. - The host's build matches the fixed row in the table, or the workaround profile shows Succeeded for that device in Intune and the device has restarted.
- On fixed hosts, Administrator protection is back on: elevation requests show the Administrator protection prompt again.
- Your exclusion group empties over time; every host left in it is a device still running without the protection.
Key takeaways#
- Read the settings in every new security baseline version before you deploy it. The 2026 baselines switch on Administrator protection, which changes elevation behavior for every user. See Intune security baseline versions and conflicts.
- Microsoft says not to enable Administrator protection on Windows 365 Cloud PCs or Azure Virtual Desktop session hosts; scope it away from them from the start.
- Remote Desktop hosts deserve their own pilot ring for monthly updates and previews.
- If you need managed elevation for standard users, compare this with Endpoint Privilege Management elevation rules.
References#
- Windows 11, version 26H2 known issues and notifications (Remote Desktop connections might fail for non-admin users with error 0xC000000D)
- Windows 11, version 24H2 known issues and notifications
- Administrator protection

