RDP / Entra / The local security authority cannot be contacted

Hello,

Based on your description, you can try the following solutions:

1. Check network connectivity: Ensure that the remote computer has access to the following necessary Microsoft Entra ID endpoints:

https://enterpriseregistration.windows.net

https://login.microsoftonline.com

https://pas.windows.net

If there are firewalls or proxy servers in your network, make sure that access to these endpoints is not restricted.

2. Are you using the IP or FQDN of the target machine when making the remote connection? Will trying another way to connect get the same error? Make sure the user enters their credentials in the correct format, such as AzureAD\******@domain.com.
3. If you have configured a Conditional Access policy, such as MFA, make sure that the remote desktop connection complies with the policy requirements. If MFA is required by policy, but the client doesn't have a strong authentication method enabled, such as Windows Hello, it can cause the connection to fail.
4. Make sure that the OS version of the local device supports remote desktop connection using Entra ID. Check if there are local policy or domain policy restrictions that prevent the use of the Entra ID.

5.Open Event Viewer and check whether there are any remote desktop error records in TerminalServices-LocalSessionManager-Operational and Remote Desktop Services-RdpCoreTS-Operational.

6. Run the diagnostic tool: Run dsregcmd /status on the remote machine and confirm that the device status shows as AzureAdJoined: YES. Run the dsregcmd /status command to display details such as the device's join status, tenant information, user status, SSO status, and more, which can help diagnose whether the device is properly joined to the Microsoft Entra ID and the user's authentication status.

I hope this information helps.

Best regards,

Jingjing Wu

Thank you for the feedback!

1. Connectivity verified to all of these endpoints from both source and destination systems. No proxy is in use, and no firewalls are blocking traffic.
2. Using an IP with Entra credentials isn't supported ("Using an IP address is no supported when using a web account to sign in."). As I understand it, you have to use the hostname of the system that matches what is in Entra for the device. We use a 'hosts' file entry to map the hostname to the IP. We are using the format AzureAD\******@domain.com.
3. We don't have any conditional access policies in play, and we are properly prompted for MFA during the connection attempt, prior to the error message.
4. We are using a licensed Windows 11 Pro operating system, which supports Entra ID. I have been reviewing policies for any potential issues, but have not found anything so far. We have other systems with the same policies applied that we are able to connect remotely with no issue. Remote Desktop with the local admin works, so it would need to be a policy related speifically to Entra ID. Do you have any specifc policies in mind to check?
5. No activity is logged in the TerminalServices-LocalSessionManager-Operational log on a connection attempt. I enabled the Debug and Operational logs, and it only logs one event with almost no data: Event ID 0, no Source, no Message
   • Remote Desktop Services-RdpCoreTS-Operational has some events on a connection attempt. No errors but two warnings:
   • Event ID 142: TCP socket READ operation failed, error 64
   • Event ID 226: RDP_TCP: An error was encountered when transitioning from StateUnknown in response to Event_Disconnect (error code 0x80070040).
   These seem like maybe events triggered from the disconnect issued when authenticaton fails? Enabling the Debug log does yield one error event, but it also has Event ID 0 with a 'The description for Event ID 0 from source Microsoft-Windows-RemoteDesktopServices-RdpCoreTS cannot be found.' message. Detail view on that log shows error code 15003.
6. Output from dsregcmd /status does yield "AzureAdJoined : YES" and the "Device Name" matches the hostname we're using to connect. The tenant information looks correct and matches the information we see on one of the successful hosts.

Looking forward to additional thoughts!

Believe I finally found a solution to this issue. Turns out the TPM 2.0 sub-version 1.16 or less has an issue with the rsa_pss_rsae_sha256 cipher which is getting negotiated during a Remote Desktop connection with an Entra account. Disabling the RSAE-PSS ciphers in the registry allows the client to negotiate a rsa_pkcs1_sha256 connection successfully instead. Updating the TPM firmware on the system should also work, but is much more impactful and requires BitLocker suspension and clearing the TPM, etc...

For anyone running into this issue, you can remove these:

• RSAE-PSS/SHA256
• RSAE-PSS/SHA384
• RSAE-PSS/SHA512

from the registry key:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003

and reboot.

Finally found a useful log entry pointing to this issue in the Microsft-Windows-Crypt-NCrypt-Operational event log.

• 0x40290423 (The requested salt size for signing with RSAPSS does not match what the TPM uses)

Hi,

I have the same issues with one out of 3 PCs.
Unfortunatly removing these ciphers did not changed the issue for me.
I see the 0x40290423 in my logs was well.

One difference between working und not working PCs are the TMPs:
Working: INTC with version 600.18.30.2264 and TPM 2.0

NOT working: IFX with version 7.63.6400.0 and TPM 2.0 (Lenovo P330)

I am still looking for a solution ...