Microsoft Entra application proxy frequently asked questions

No, the following configuration items are being used by app proxy and should not be altered or deleted:

• Enable/Disable “Allow public clients flows”.
• CWAP_AuthSecret (Client secrets).
• API Permissions. Modifying any of the above configuration items on the App registration page breaks preauthentication for Microsoft Entra application proxy.

No. You should delete an application proxy app from the Enterprise applications area of the Microsoft Entra admin center. If you delete the application proxy app from the App registrations area of the Microsoft Entra admin center, then you could experience issues.

To use Microsoft Entra application proxy, you must have a Microsoft Entra ID P1 or P2 license. For more information about licensing, see Microsoft Entra pricing

If your license expires, application proxy is automatically disabled. Your application information is saved for up to one year.

Make sure you have at least a Microsoft Entra ID P1 or P2 license and a Microsoft Entra private network connector installed. After you successfully install your first connector, the Microsoft Entra application proxy service is enabled automatically.

This may be due to either the updater service not working correctly or if there are no new updates available that the service can install.

The updater service is healthy if it’s running and there are no errors recorded in the event log (Applications and Services logs -> Microsoft -> Microsoft Entra private network -> Updater -> Admin).

To manually upgrade a connector:

• Download the latest version of the connector. (You can find it under application proxy on the Microsoft Entra admin center. You can also find the link at Microsoft Entra application proxy: Version release history.
• The installer restarts the Microsoft Entra private network connector services. In some cases, a reboot of the server might be required if the installer cannot replace all files. Therefore we recommend closing all applications (i.e. Event Viewer) before you start the upgrade.
• Run the installer. The upgrade process is quick and does not require providing any credentials and the connector is not re-registered.

No, this scenario isn't supported. The default settings are:

• Microsoft Entra private network connector - WAPCSvc - Network Service
• Microsoft Entra private network connector Updater - WAPCUpdaterSvc - NT Authority\System

No, currently, this isn't possible. The registration attempt is always made on the user's home tenant.

For recommendations, see High availability and load balancing of your private network connectors and applications.

The private network connector performs certificate-based authentication to Azure. TLS Termination (TLS/HTTPS inspection or acceleration) breaks this authentication method and isn't supported. Traffic from the connector to Azure must bypass any devices that are performing TLS Termination.

Yes. To provide the best-in-class encryption to our customers, the application proxy service limits access to only TLS 1.2 protocols. These changes were gradually rolled out and effective since August 31, 2019. Make sure that all your client-server and browser-server combinations are updated to use TLS 1.2 to maintain connection to application proxy service. These include clients your users are using to access applications published through application proxy. See Preparing for TLS 1.2 in Office 365 for useful references and resources.

Yes, this scenario is supported starting from the connector version 1.5.1526.0. See Work with existing on-premises proxy servers.

There's no reason to. Any Global Administrator or application administrator account works. The credentials entered during installation aren't used after the registration process. Instead, a certificate is issued to the connector, which is used for authentication from that point on.

There are Performance Monitor counters that are installed along with the connector. To view them:

1. Select Start, type "Perfmon", and press ENTER.
2. Select Performance Monitor and click the green + icon.
3. Add the Microsoft Entra private network connector counters you want to monitor.

The connector isn't required to be on the same subnet. However, it needs name resolution (DNS, hosts file) to the resource and the necessary network connectivity (routing to the resource, ports open on the resource, etc.). For recommendations, see Network topology considerations when using Microsoft Entra application proxy.

Application proxy requires Windows Server 2012 R2 or later. There is currently a limitation on HTTP2 for Windows Server 2019. In order to successfully use the connector on Windows Server 2019, you need to add the registry key and restart the server:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\EnableDefaultHttp2 (DWORD) Value: 0 

When a connector is running, it remains active as it connects to the service. Uninstalled /Unused connectors are tagged as inactive and are removed after 10 days of inactivity from the portal. There is no way to remove the Inactive connector manually from the Microsoft Entra admin center.

Although these suffixes appear in the suffix list, you should not use them. These domain suffixes are not meant to be used with Microsoft Entra application proxy. If you use these domain suffixes, the created Microsoft Entra application proxy application won't work. You can use either the standard domain suffix msappproxy.net or a custom domain.

Microsoft Entra ID has an application proxy service that enables users to access on-premises applications by signing in with their Microsoft Entra account. If you have installed connectors in different regions, you can optimize traffic by selecting the closest application proxy cloud service region to use with each connector group, see Optimize traffic flow with Microsoft Entra application proxy.

After you uploaded the SSL certificate, you receive the message "Invalid certificate, possible wrong password" on the portal.

Here are some tips for troubleshooting this error:

• Check for problems with the certificate. Install it on your local computer. If you don't experience any issues then the certificate is good.
• Ensure that the password does not contain any special characters. The password should only contain the characters 0-9, A-Z, and a-z.
• If the certificate was created with Microsoft Software Key Storage Provider, the RSA algorithm must be used.

The default length is 85 seconds. The "long" setting is 180 seconds. The timeout limit can't be extended.

No, this is currently not supported.

The client secret, also called CWAP_AuthSecret, is automatically added to the application object (app registration) when the Microsoft Entra application proxy app is created.

The client secret is valid for one year. A new one-year client secret is automatically created before the current valid client secret expires. Three CWAP_AuthSecret client secrets are kept in the application object at all times.

No. You must use the original fallback domain.

Article mentioned in question: Add and replace your onmicrosoft.com fallback domain in Microsoft 365

From the Application Registrations page, you can change the homepage URL to the desired external URL of the landing page. The specified page is loaded when the application is launched from My Apps or the Office 365 Portal. For configuration steps, see Set a custom home page for published apps by using Microsoft Entra application proxy

If Microsoft Entra preauthentication is configured, and the application URL contains a “#” character when you try to access the application for the first time, you get redirected to Microsoft Entra ID (login.microsoftonline.com) for the authentication. Once you complete the authentication you get redirected to the URL part prior to the ”#” character and everything that comes after the “#“ seems to be ignored/ removed. For example if the URL is https://www.contoso.com/#/home/index.html, once the Microsoft Entra authentication is done the user is redirected to https://www.contoso.com/. This behavior is by design due to how the “#” character is handled by the browser.

Possible solutions/ alternatives:

• Set up a redirection from https://www.contoso.com to https://contoso.com/#/home/index.html. The user must first access https://www.contoso.com.
• The URL used for the first access attempt must include the “#” character in encoded form (%23). The published server might not accept this.
• Configure passthrough preauthentication type (not recommended).

No, there's no IIS requirement for applications that are published. You can publish web applications running on servers other than Windows Server. However, you might not be able to use preauthentication with a non-Windows Server, depending on if the web server supports Negotiate (Kerberos authentication). IIS isn't required on the server where the connector is installed.

Application proxy does not automatically add the HTTP Strict-Transport-Security header to HTTPS responses, but it maintains the header if it is in the original response sent by the published application. Proving a setting to enable this functionality is on the roadmap.

No, if the protocol http is configured in the external URL then the Microsoft Entra application proxy endpoint accepts incoming request on the port TCP 80, if the protocol https then on the port TCP 443.

Yes, some examples for internal URLs including ports: http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/.

Some responses sent by the published web applications might contain hard-coded URLs. In this case it must be ensured by using a link translation solution that the client always uses the correct URL. Link translation solutions might be complex and might not work in all the scenarios. You can find here our documented solutions for link translation.

As best practice it is advised to use identical external and internal URLs. External and internal URLs are considered to be identical, if the protocol://hostname:port/path/ in both URLs are identical.

This can be achieved by using the Custom Domains feature.

Examples:

Identical:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Not identical:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

Making the external and internal URLs identical is not possible at all, if the internal URL contains a non-standard port (other than TCP 80 / 443).

In some scenarios changes must be done in the configuration of the web app.

The PrincipalsAllowedToDelegateToAccount method is used when connector servers are in a different domain from the web application service account. It requires the use of Resource-based Constrained Delegation. If the connector servers and the web application service account are in the same domain, you can use Active Directory Users and Computers to configure the delegation settings on each of the connector machine accounts, allowing them to delegate to the target SPN.

If the connector servers and the web application service account are in different domains, Resource-based delegation is used. The delegation permissions are configured on the target web server and web application service account. This method of Constrained Delegation is relatively new. The method was introduced in Windows Server 2012, which supports cross-domain delegation by allowing the resource (web service) owner to control which machine and service accounts can delegate to it. There's no UI to assist with this configuration, so you need to use PowerShell. For more information, see the whitepaper Understanding Kerberos Constrained Delegation with application proxy.

NTLM authentication can’t be used as a preauthentication or single sign-on method. NTLM authentication can be used only when it can be negotiated directly between the client and the published web application. Using NTLM authentication usually causes a sign-in prompt to appear in the browser.

No, this won’t work, because a guest user in Microsoft Entra ID doesn't have the attribute that is required by any of the logon identities mentioned above.

In this case there is a fallback to “User principal name”. For more details on the B2B scenario please read Grant B2B users in Microsoft Entra ID access to your on-premises applications.

Conditional Access Policies are only enforced for successfully pre-authenticated users in Microsoft Entra ID. Pass-through authentication doesn’t trigger Microsoft Entra authentication, so Conditional Access Policies can't be enforced. With pass-through authentication, MFA policies must be implemented on the on-premises server, if possible, or by enabling preauthentication with Microsoft Entra application proxy.

No, this scenario isn't supported because application proxy terminates TLS traffic.

Refer to Publish Remote Desktop with Microsoft Entra application proxy.

No, this scenario isn't supported.

Yes, it’s expected. The preauthentication scenario requires an ActiveX control, which isn't supported in third-party browsers.

Yes, this scenario is currently in public preview. Refer to Publish Remote Desktop with Microsoft Entra application proxy.

Yes, it's expected. If the user’s computer is Microsoft Entra joined, the user signs in to Microsoft Entra ID automatically. The user needs to provide their credentials only on the RDWeb sign-in form.

This option enables the user to download the rdp file and use it by another RDP client (outside of the Remote Desktop Web Client). Typically, another RDP clients (like the Microsoft Remote Desktop Client) cannot handle the preauthentication natively. That's why the scenario doesn't work.

Refer to Enable remote access to SharePoint with Microsoft Entra application proxy.

The SharePoint mobile app does not support Microsoft Entra preauthentication currently.

No. Microsoft Entra application proxy is designed to work with Microsoft Entra ID and doesn’t fulfill the requirements to act as an AD FS proxy.

No, this is not supported.

Applications that use the WebSocket protocol, for example QlikSense and Remote Desktop Web Client (HTML5), are now supported. The following are known limitations:

• Application proxy discards the cookie that is set on the server response while opening the WebSocket connection.
• There is no SSO applied to the WebSocket request.
• Features (Eventlogs, PowerShell and Remote Desktop Services) in the Windows Admin Center (WAC) do not work through Microsoft Entra application proxy.

The WebSocket application doesn't have any unique publishing requirements, and can be published the same way as all your other application proxy applications.

Yes. Link translation affects performance. The application proxy service scans the application for hardcoded links and replaces them with their respective, published external URLs before presenting them to the user.

For best performance, we recommend using identical internal and external URLs by configuring custom domains. If using custom domains isn't possible, you can improve link translation performance by using the My Apps Secure Sign in Extension or Microsoft Edge Browser on mobile. See Redirect hardcoded links for apps published with Microsoft Entra application proxy.

This scenario isn't supported directly. Your options for this scenario are:

1. Publish both the HTTP and HTTPS URLs as separate applications with a wildcard, but give each of them a different custom domain. This configuration works since they have different external URLS.

2. Publish the HTTPS URL through a wildcard application. Publish the HTTP applications separately using these application proxy PowerShell cmdlets:

   • Application proxy application management
   • private network connector management