RDP using FIDO2 - TruU Docs

1. Prerequisites

Target (remote) machine

Microsoft Entra joined, or Microsoft Entra hybrid joined.
Windows 11 with KB5018418 or later; or Windows 10 20H2+ with KB5018410 or later; or Windows Server 2022 with KB5018421 or later; or Windows Server 2025.
Remote Desktop enabled (Settings → System → Remote Desktop).
Signing-in user is a member of the local Remote Desktop Users group (the user who joined the device to Entra ID is granted access implicitly).
A resolvable hostname — see §5 Troubleshooting on IP addresses.

Client (local) machine

Microsoft Entra joined or Microsoft Entra hybrid joined. TruU requires the Windows machine it runs on to be joined.
Same Windows build baseline as the target.
TruU client installed and the user enrolled.

Microsoft Entra ID tenant

The Passkey (FIDO2) authentication method must be enabled and scoped to the target users.

No separate passkey registration. TruU enrolment registers the user’s security key credential as part of the process. There is no additional step for the user or the administrator — once the user is enrolled in TruU, the credential exists on the Entra account and this flow is available to them.

Hybrid-joined targets only

A hybrid-joined machine is trusted by both on-premises AD and Entra ID, so authentication must satisfy both. Entra Kerberos must be configured so Entra ID can issue a partial Kerberos TGT after the passkey authentication — an AzureADKerberos read-only domain controller object in Entra ID. It is an empty placeholder, not backed by a real on-premises DC.

# Run elevated on a server with Microsoft Entra Connect installed.
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"

$domain            = $env:USERDNSDOMAIN
$userPrincipalName = "admin@<your-tenant>.onmicrosoft.com"
$domainCred        = Get-Credential   # on-prem AD credentials

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Confirm in Active Directory Users and Computers that an AzureADKerberos object exists under Domain Controllers. Once it does, the connection procedure is identical to the Entra-joined case.

Hybrid caveat. Do not test with a Domain Admin or other highly privileged AD account. Entra ID will not issue a partial TGT for protected accounts, and the failure looks like a configuration error.

2. Administrator configuration

Grant RDP access to the Entra user on the target

net localgroup "Remote Desktop Users" /add "AzureAD\user@contoso.com"

Verify in Computer Management (compmgmt.msc) → Local Users and Groups → Groups → Remote Desktop Users.

Known limitation. Adding an Entra ID group to Remote Desktop Users is not honoured for RDP sign-in. Add users individually, or plan for the documented workaround of disabling Network Level Authentication — which has a real security cost and should be a deliberate decision.

Confirm the TruU credential before first use

No passkey registration step is needed — TruU enrolment already created the credential. Before attempting RDP, simply have the user confirm it works for an ordinary web sign-in to a Microsoft application. If it fails in a browser, it will fail here, and the problem is enrolment rather than RDP configuration.

Enforce phishing-resistant authentication (recommended)

Without a policy this flow is available but not required — a user can still fall back to a password.

Assignments → Users: the group that requires secured RDP.
Target resources → Cloud apps: Microsoft Remote Desktop, app ID a4a365df-50f1-4397-bc59-1a1564b8bb9c.
Grant → Require authentication strength → Phishing-resistant MFA (satisfied by FIDO2 passkeys).
Save in report-only mode, review sign-in logs, then enable.

Consider pairing with a sign-in frequency control so long-lived sessions are periodically re-verified.

Optional: pre-stage the setting in an .rdp file

full address:s:TARGET-HOSTNAME
enablerdsaadauth:i:1
authentication level:i:2
prompt for credentials:i:0

enablerdsaadauth:i:1 is exactly equivalent to the Use a web account to sign in to the remote computer checkbox. It is the single property that turns this flow on.

3. End-user walkthrough

This is the sequence the user sees. Exact wording of the Windows and Microsoft dialogs varies slightly by build. Step 1 — Turn on web-account sign-in. Open Remote Desktop Connection (mstsc.exe) → Show Options → Advanced tab. Under User authentication, tick Use a web account to sign in to the remote computer. Step 2 — Enter the target host and connect. On the General tab, type the NetBIOS name or FQDN of the remote machine. It must match the device’s hostname in Entra ID and resolve to that machine. Select Connect. Do not use an IP address — it is not supported with web-account sign-in and the connection will fail or silently fall back to password authentication. Step 3 — Choose the account. An Entra ID sign-in window opens. Select the account, or select Use another account to force a fresh sign-in rather than reusing an account already connected to Windows — useful when you need to choose the sign-in method explicitly. Step 4 — Pick the passkey sign-in method. Select Sign-in options → Face, fingerprint, PIN or security key. The next screen warns that a security window is about to open; select Next. Step 5 — Select TruU rather than the local platform passkey. Windows raises its own Windows Security dialog and may offer the platform (Windows Hello) passkey already on the machine. If so, select Choose a different passkey, then Security key — this routes the ceremony to TruU. Step 6 — Authenticate with TruU. Windows displays Touch your security key. Instead of a USB key, the TruU client takes the request and presents its own prompt. Enter the TruU PIN, or use Sign-in Option to switch to another TruU verification method. Step 7 — Let the session negotiate. The sign-in window shows Just a moment… and closes. The RDP client reports Securing remote connection… then Configuring remote session…. No credential prompt appears at this stage. Step 8 — Accept the console take-over prompt, if shown. If someone is signed in at the target’s console, RDP warns they will be disconnected. Select Yes. This is standard single-session Windows behaviour, not specific to this authentication method. Step 9 — Session opens. The remote desktop loads with the user already signed in. No password was entered at any point.

4. Verification

Where	What to look for
Entra ID sign-in logs	Interactive sign-in against the application Microsoft Remote Desktop. Under Authentication Details, the method should be recorded as a passkey / FIDO2 credential, not password. If an authentication-strength CA policy is in place, its result should show as satisfied.
Target — Security log	Logon event for the Entra user with a remote interactive logon type, with no NTLM package.
Target — TerminalServices-LocalSessionManager	Session logon events confirming the RDP session was created for the expected account.
TruU client logs	`C:\ProgramData\TruU Inc\logs` on the client machine. Confirm an authenticator request was received and a user-verification result returned. (confirm current path per client version)

5. Troubleshooting

Symptom	Likely cause and fix
No web sign-in window; classic username/password box instead	Web-account option not set. Confirm the Use a web account… checkbox or `enablerdsaadauth:i:1`. mstsc does not always persist the checkbox between sessions.
Connection fails immediately when using an IP address	Not supported. Use the hostname or FQDN matching the Entra ID device record, and make sure it resolves.
TruU never prompts; Windows only offers the Hello PIN	Platform authenticator was selected. Use Choose a different passkey → Security key. If Security key is absent, check that the TruU client is running and registered as a WebAuthn authenticator, and confirm the client machine is Entra joined or hybrid joined — TruU requires it (`dsregcmd /status`).
TruU prompts but Entra ID rejects the assertion	Check the tenant Passkey (FIDO2) policy. An AAGUID allowlist excluding TruU, or Enforce attestation with no matching MDS entry, fails at exactly this point. Test the same credential in a browser to isolate.
Authentication succeeds but the session is refused	Authorisation, not authentication. Confirm the user is in Remote Desktop Users on the target as an individual account — Entra group membership is not honoured.
Hybrid target: sign-in succeeds, on-prem resources inaccessible	Entra Kerberos missing or incomplete. Verify the `AzureADKerberos` object exists. Also confirm you are not testing with a privileged AD account.
Conditional Access blocks the connection	Review the failed sign-in in Entra ID and identify the failing control. A phishing-resistant strength requirement blocks any fallback method — intended behaviour once TruU works.
CredSSP / NLA errors	Some environments need CredSSP negotiation adjusted for this path. Change NLA settings only deliberately and document the decision; disabling NLA weakens pre-authentication protection on the target.

​1. Prerequisites

​Target (remote) machine

​Client (local) machine

​Microsoft Entra ID tenant

​Hybrid-joined targets only

​2. Administrator configuration

​Grant RDP access to the Entra user on the target

​Confirm the TruU credential before first use

​Enforce phishing-resistant authentication (recommended)

​Optional: pre-stage the setting in an .rdp file

​3. End-user walkthrough

​4. Verification

​5. Troubleshooting