Remote Desktop client connection

We had a similar issue and found we had to enable access to "digicert.com" for the users subnet in question.

Not sure if it was the exact error, but something that is required it seems

I noticed that here, Azure Certificate Authority details | Microsoft Learn, and included them in the URL list at one point.  But you would think opening up the whole internet to 443 traffic would cover it.

Interesting to me is that I can connect to the web client in Edge from my test box which implies the machine can resolve the proper certificates but the app is rejecting them.

Referring this:

1. Check SSL/TLS Certificates
2. Update Network Security Rules
3. Verify DNS Settings
4. Check Entra ID Configuration
5. Review AVD Network Connectivity Requirements
6. Check Logs for Detailed Errors

Troubleshoot common Azure deployment errors - Azure Resource Manager | Microsoft Learn

Ensure the TLS Certificate is Trusted

The error indicates that the client does not trust the SSL/TLS certificate from the AVD service. This could happen if:

• The server's certificate is not from a trusted certificate authority (CA) that the client recognizes.
• The certificate chain is incomplete (e.g., intermediate certificates are missing).

Solution:

• Make sure that the AVD (Azure Virtual Desktop) endpoint’s SSL certificate is issued by a trusted CA (such as DigiCert, GlobalSign, or Let's Encrypt).
• Ensure that the root and intermediate certificates are properly installed on the client machine or within the environment where your RDP client resides.
  • You can download the necessary intermediate certificates from the issuer’s website if they're missing.
• If you're using private endpoints, verify that the private DNS and SSL certificates used by the private endpoint match the correct certificate.

2. Verify DNS Resolution

If you’re using private endpoints and DNS forwarding was previously set up, this could impact DNS resolution for AVD. Since you’ve removed DNS forwarding, ensure that the client can properly resolve the Azure AD sign-in endpoint and other related services via DNS.

Solution:

• Ensure the client machine has the correct DNS settings that resolve public Azure domains like *.msocdn.net, *.msal.com, and *.windows.net.
• For private endpoint connections, confirm that DNS resolution for these services is correctly handled (you may need a custom DNS server or a DNS forwarding setup that resolves Azure domain names internally).

3. Check for Proxy or Firewall Issues

Since you mentioned that your network is restricted, it’s possible that an internal firewall or proxy is blocking required connections.

Solution:

• Test connectivity: Use ping, telnet, or test-netconnection from the client machine to ensure connectivity to essential AVD endpoints.
• Ensure that port 443 is open for both outbound and inbound traffic to the necessary Azure endpoints.
• If you have a proxy server configured, ensure that the client machine is correctly configured to route traffic through it, and that it allows TLS traffic to pass through.

4. Update AVD Client and RDP Settings

The AVD client itself may need to be updated or reconfigured to resolve issues with connecting over a restricted network.

Solution:

• Update the Remote Desktop Client: Ensure that the Microsoft Remote Desktop Client (or Azure Virtual Desktop Client) is up to date.
• Use the latest RDP settings: Sometimes older RDP clients may have issues with newer security protocols (e.g., TLS 1.2, 1.3). You can update or configure RDP settings to ensure that only secure TLS versions are being used.

5. Allow Traffic to Azure AD and Authentication Services

Since the Entra sign-in is not appearing, it’s important that your network allows traffic to Azure AD authentication endpoints. These are critical for AVD login.

Solution:

• Allow traffic to these endpoints:
  • login.microsoftonline.com (Azure AD authentication)
  • *.msocdn.net, *.windows.net, and other Microsoft service endpoints that are used by the AVD service.
• These endpoints must be accessible to your client machine in order to authenticate and establish a connection.

6. TLS Version Compatibility

Your error mentions TLS, which could suggest a mismatch in the TLS versions or weak encryption settings.

Solution:

• Ensure your client supports the latest TLS 1.2 or TLS 1.3 protocols.
• You can configure your environment (if needed) to enforce the use of newer versions of TLS to avoid issues with older, insecure protocols.
• Ensure that the SSL/TLS settings on your RDP client and server are compatible.

7. Test and Debug with Logs

Enable detailed logging for your Azure Virtual Desktop client to gather more specific information. This can help you pinpoint the exact failure in the connection attempt.

Solution:

• Enable diagnostic logging for the AVD client.
• Check the Event Viewer logs on both the client and server for more detailed error messages related to the failed connection.
• Look for SSL/TLS errors, connectivity issues, or authentication failures.

8. Re-verify Private Endpoint Configuration

If you were using private endpoints for AVD, ensure the endpoints are still configured correctly in your VNet. If DNS forwarding was disabled, the client may no longer be able to reach the private endpoints correctly.

Solution:

• Check the configuration of your private link or private endpoints.
• Verify DNS resolution is working properly for the internal clients.

• Ensure trusted certificates are in place for your AVD service.
• Verify DNS resolution and firewall settings to ensure connectivity to required endpoints.
• Update AVD and RDP clients and ensure they support TLS 1.2/1.3.
• Review and configure your proxy/firewall to ensure necessary traffic is not blocked.
• Enable detailed logs to further troubleshoot connection issues.

We figure it out.  We needed to open port 80 for OCSP.  Once we opened the port in the test rule we were able to identify the type of traffic and reconfigure the application filtering in the proper rule.