Forum Discussion

TimDyck's avatar
TimDyck
Copper Contributor
Nov 06, 2024

Remote Desktop client connection

I'm trying to expand access to our AVD pools into our internal network and I'm getting the following error after I hit subscribe.   I never get the initial Entra sign in when you click subscrib...
AVD
client
kyazaferr's avatar
kyazaferr
MCT
Nov 13, 2024

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.

Resources