Entra Private Access Channels Are Unreachable

Administrators deploying Microsoft Entra Private Access may encounter a scenario in which the Global Secure Access (GSA) agent reports an error. However, the client continues to work without issue, and all internal resources remain reachable via the Entra Private Access connection. This issue occurs only when the Private Access forwarding profile is enabled alone. It does not happen if the Microsoft traffic forwarding profile is also enabled.

GSA Status Error

When this happens, the Private access channel status is Connected, but the Entra access channel is Disconnected. Also, you will see the following error message when clicking on the GSA client in the notification area.

Some channels are unreachable

Global Secure Access has some channels that are unreachable

Health Check

To investigate further, click the Troubleshooting tab, then click Run tool in the Advanced diagnostics tool section. In the Health check section, you will see the following error message.

Diagnostic URLs were not found in forwarding policy

Scrolling down the list also reveals the following error messages.

Magic IP received = False

Tunneling succeeded Entra Authentication = False

Root Cause

Several months ago, Microsoft made changes to the health check probes that required enabling the Microsoft traffic forwarding profile to work. Some essential health-check probes were not accessible via the Private Access channel, resulting in the error messages shown above when only the Private Access forwarding profile is enabled.

Resolution

Microsoft is rolling out changes to address this issue at the time of this writing (late October 2025). If you encounter this error, it will most likely resolve itself soon. Alternatively, administrators can enable the Microsoft traffic forwarding profile, which will also fix this issue.

Additional Information

Microsoft Entra Private Access

Microsoft Entra Global Secure Access (GSA)

Microsoft Security Service Edge (SSE) Now Generally Available

Microsoft Entra Security Service Edge (SSE) on RunAs Radio

Managed Certificates for Remote Desktop Protocol

The Remote Desktop Protocol (RDP) is arguably the most widely used protocol for Windows remote server administration. RDP uses Transport Layer Security (TLS) for server authentication, data encryption, and integrity. However, the default configuration of TLS for RDP in Windows is less than ideal.

RDP Self-Signed Certificate

By default, RDP uses a self-signed certificate for TLS operations. TLS with self-signed certificates is a bad security practice because they are not validated by a trusted certificate authority (CA), making it impossible for clients to verify the authenticity of the server they are connecting to, which can lead to interception attacks.

Certificate Warning

Most administrators have encountered a warning error when connecting to a remote host via RDP using a self-signed RDP certificate.

“The remote computer could not be authenticated due to problems with its security certificate. It may be unsafe to proceed.”

Nmap

You can view the default self-signed certificate with the Nmap utility by running the following command.

nmap.exe -n -p 3389 <hostname> –script ssl-cert

Managed Certificates

A better solution for RDP TLS is to use managed certificates issued by an enterprise Public Key Infrastructure (PKI) such as Microsoft Active Directory Certificate Services (AD CS). AD CS is widely deployed in AD domain environments and can be configured to issue certificates for RDP TLS.

AD CS

To configure AD CS to issue RDP certificates, perform the following steps.

Certificate Template

On an issuing CA or an administrative workstation with the Remote Server Administration Tools (RSAT) installed, open the Certificate Templates management console (certtmpl.msc) and perform the following steps.

*My apologies for the list numbering format issues below. Microsoft Word and WordPress can’t seem to agree on the list format. Hopefully, you can figure it out, though. 🙂

  1. Right-click the Workstation Authentication template and choose Duplicate Template.
  2. Select the Compatibility tab.
    1. Select the operating system (OS) version corresponding to the oldest OS hosting the issuing CA role in your environment from the Certification Authority drop-down list.
    1. Select the OS version corresponding to your environment’s oldest supported server or client OS from the Certificate recipient drop-down list.
  3. Select the General tab.
    1. Enter a descriptive name in the Template display name field.
    1. Select an appropriate validity period for your environment. The best practice is to limit the validity period to one year or less.
  4. Select the Cryptography tab.
    1. From the Provider Category drop-down list, choose Key Storage Provider.
    1. From the Algorithm name drop-down list, choose RSA.
    1. In the Minimum key size field, enter 2048.
    1. From the Request hash drop-down list, choose SHA256.
  5. Select the Subject Name tab.
    1. From the Subject name format drop-down list, select DNS name.
    1. Ensure that DNS name is also checked in the subject alternate name section.
  6. Select the Extensions tab.
    1. Click on Application Policies.
    1. Click Edit.
    1. Select Client Authentication.
    1. Click Remove.
    1. Click Add.
    1. Click New.
    1. Enter Remote Desktop Authentication in the Name field.
    1. Enter 1.3.6.1.4.1.311.54.1.2 in the Object identifier field.
    1. Click Ok.
    1. Select Remote Desktop Authentication.
    1. Click Ok.
  7. Select the Security tab.
    1. Click Domain Computers.
    1. Grant the Read and Enroll permissions.
  8. Click Ok.

Next, open the Certification Authority management console (certsrv.msc) and follow the steps below to publish the certificate.

  1. Expand the CA.
  2. Right-click Certificate Templates and choose New > Certificate Template to Issue.
  3. Select the Remote Desktop Authentication certificate template.
  4. Click Ok.

Group Policy

Next, on a domain controller or a workstation with the RSAT tools installed, open the Group Policy Management console (gmpc.msc) and perform the following steps to create a new GPO to enroll domain computers for the Remote Desktop Authentication certificate

  1. Right-click Group Policy Objects and choose New.
  2. Enter a descriptive name for the GPO in the Name field.
  3. Click Ok.
  4. Right-click the GPO and choose Edit.
  5. Navigate to Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.
  6. Double-click Server authentication certificate template.
  7. Select Enabled.
  8. Enter the name of the Remote Desktop Authentication certificate template in the Certificate Template Name field. Note: Be sure to enter the template name, not the template display name!
  9. Click Ok.

Once complete, link the GPO to the domain or OU to target the servers and workstations to which you wish to deploy the RDP certificate.

Validate Certificate

After updating group policy on a target resource, you’ll find that Nmap now shows the enterprise PKI-issued certificate used for RDP connections.

Additional Information

Understanding the Remote Desktop Protocol (RDP)

Always On VPN and SQL Target Principal Name Incorrect

Microsoft Always On VPN provides seamless and transparent remote access to corporate applications and data. In most cases, accessing resources over the VPN works the same as on-premises. However, a few folks have asked recently about an issue they found when using the SQL Server Management Studio (SMSS) to connect to a remote SQL server over Always On VPN.

Principal Name Incorrect

Administrators may encounter the following error message when using SMSS to connect to Microsoft SQL servers over an Always On VPN connection.

“The target principal name is incorrect. Cannot generate SSPI context. (Microsoft SQL Server)”

Resolution

There are a few different ways to resolve this issue. Choose the option that works best in your environment.

VPN Configuration

For Always On VPN deployments with Windows 11 24H2 and later clients, add the following setting to your XML configuration file.

<UseRasCredentials>false</UseRasCredentials>

For clients older than Windows 11 24H2, you must edit the rasphone.pbk file setting as follows.

UseRasCredentials=0

Group Policy

Optionally, a Group Policy Object (GPO) can be created and applied to target endpoints. For testing, you can enable this setting using the local group policy editor (gpedit.msc). Using either method, enable the following group policy setting.

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication = Enabled

Registry Editor

This method can be used for local testing. Open the Windows Registry Editor (regedit.exe) on a test client and create the following entry.

Key = HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Name = DisableDomainCreds
Type = DWORD
Value = 1

PowerShell

The following PowerShell command will also create the required registry entry. Administrators can run the command interactively or deploy it via automation.

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Lsa’ -Name DisableDomainCreds -Value 1

Additional Information

Always On VPN Short Name Access Failure