> ## Documentation Index > Fetch the complete documentation index at: https://docs.truu.ai/llms.txt > Use this file to discover all available pages before exploring further. # RDP using FIDO2 ## 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. ```powershell theme={null} # 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@.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 ```text theme={null} 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. 1. **Assignments → Users:** the group that requires secured RDP. 2. **Target resources → Cloud apps:** **Microsoft Remote Desktop**, app ID `a4a365df-50f1-4397-bc59-1a1564b8bb9c`. 3. **Grant → Require authentication strength → Phishing-resistant MFA** (satisfied by FIDO2 passkeys). 4. 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 ```text theme={null} 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. |