User accessing a remote app via RDS now getting authentication error Error code: 0x3000020

Greg Booth 1,536 Reputation points
2026-06-03T09:42:39.9966667+00:00

User accessing a remote app via RDS now getting an error message when downloading an RDP file and trying to login

RemoteApp Disconnected The remote computer can't connect to your device because of an authentication error. Ask your network administrator for help. Error code: 0x3000020.

The user can use the HTML 5 browser interface without an issue.

They are logging into an RDS farm hosted by a third party.

Could there be any config on their laptops that might be causing this issue ? It possibly started post windows updates.

Windows for business | Windows Server | User experience | Remote desktop services and terminal services
0 comments No comments

Answer accepted by question author
VPHAN 42,490 Reputation points Independent Advisor
2026-06-03T10:27:58.02+00:00

Hello Greg Booth,

It's caused by a breakdown in Network Level Authentication between your local Remote Desktop client and the third-party RDS farm. The HTML5 interface continues to function because it routes credential handling through independent web protocols rather than the native Credential Security Support Provider framework used by the downloaded RDP file. When recent Windows updates enforce stricter security protocols on your local machine, but the remote server remains unpatched, your system intentionally drops the connection to protect your credentials from potential interception.

To resolve, you must first clear any corrupted authentication tokens by navigating to the Windows Control Panel, opening the Credential Manager, selecting Windows Credentials, and deleting any entries associated with the third-party RDS farm. This action forces your system to negotiate a completely fresh, secure connection token during your next login attempt. You can also verify the exact failure reason by reviewing the local connection logs located in the Event Viewer under the path %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-ClientActiveXCore%4Operational.evtx, which records the exact moment the security negotiation fails in an accessible format.

If clearing the credential cache does not resolve the issue, the root cause lies firmly with the server's update compliance. You must contact your third-party hosting provider and require them to apply the latest Microsoft security patches to their RDS infrastructure. We strictly advise against modifying local registry keys to downgrade your Encryption Oracle Remediation policy or disabling Network Level Authentication, as these are insecure workarounds that violate Microsoft security baselines and leave your environment vulnerable.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VPHAN

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

1 additional answer

Sort by: Most helpful
  1. AI answer

    2026-06-03T09:43:02.5566667+00:00

    The error is consistent with an RDP client‑side authentication problem introduced or exposed after Windows updates, while the HTML5 client continues to work because it uses a different path (browser + gateway) and its own credential handling.

    From the provided information, the most relevant client‑side causes and mitigations are:

    1. CredSSP / NLA hardening after updates
      • Recent security updates can enforce stricter CredSSP and Network Level Authentication (NLA) requirements.
      • If the RDS farm or gateway has not yet been updated to the same level, Windows clients may fail with an authentication error while other platforms (like Mac or HTML5) still work.
      • As a temporary workaround (until the RDS provider updates their servers), the Encryption Oracle Remediation policy on the client can be relaxed:
        1. Open Local Group Policy Editor: gpedit.msc.
        2. Go to Computer ConfigurationAdministrative TemplatesSystemCredentials Delegation.
        3. Set Encryption Oracle Remediation to Enabled and choose Vulnerable.
        4. Run gpupdate /force and test again.
      • Alternatively, the RDS provider can adjust their RDP security settings as described below.
    2. RDP security layer and NLA configuration
      • If the RDS deployment is not fully aligned with the client’s security expectations, users can see generic authentication errors.
      • On the RDS side, a known workaround is to:
        • Set Require use of specific security layer for remote (RDP) connections to Enabled and select RDP.
        • Set Require user authentication for remote connections by using Network Level Authentication to Disabled.
      • These changes must be made by the RDS provider in Computer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostSecurity.
      • These settings reduce security and should only be used temporarily until all servers and clients are fully patched and aligned.
    3. Client credential handling and cache
      • Windows limits stored credentials per app; if the Remote Desktop client hits this limit, authentication can fail unexpectedly.
      • To rule this out:
        1. Clear any saved RDS credentials in Credential Manager.
        2. If many credentials are stored and the environment requires more than 20 per app, increase the limit via registry:
          • Run regedit.
          • Set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Vault\MaxPerAppCredentialNumber (DWORD) to a value greater than 20.
          • Restart the computer and test again.
      • Registry changes are administrative operations and should be done carefully, as incorrect edits can destabilize the system.
    4. Time, updates, and client version
      • Ensure the laptops are fully updated with the latest Windows and Remote Desktop client updates.
      • Verify system time and date are correct and in sync with the environment; time skew can cause authentication failures.

    Given that HTML5 access works and the RDS farm is third‑party hosted, the most practical approach is:

    • On the laptops: confirm updates, clear cached credentials, verify time, and (if necessary) temporarily relax Encryption Oracle Remediation as described.
    • With the RDS provider: confirm that their RDS servers and gateways are patched for the CredSSP/NLA hardening updates and review their RDP security layer and NLA policies.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.