Microsoft Entra application proxy frequently asked questions

No, the following configuration items are being used by app proxy and shouldn't 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.

Using a port scan utility on application proxy public endpoints (msappproxy.net or custom) may show that TCP ports 10200 and 10201 are open, in addition to ports 80 and/or 443. These ports are used for internal service health monitoring purposes. No customer data is accessible over these ports, and the services behind them do not process any information; they simply respond with "OK".

Yes, Microsoft Entra private network connector is used by both application proxy and Microsoft Entra Private Access. To learn more about the connector, see Microsoft Entra private network connector. To troubleshoot connector configuration, see troubleshoot connectors.

The ConnectorTroubleshooterLauncher.exe is deprecated and no longer functional. Currently, there is no replacement available.

Changing the logon user of the connector or updater service is not supported.

Correct Configuration:

Microsoft Entra Private Network Connector: Network Service Microsoft Entra Private Network Connector Updater: NT Authority\System

Although these suffixes appear in the suffix list, you shouldn't use them. These domain suffixes aren't 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 doesn't 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 always.

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 doesn't 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's 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 isn't possible at all, if the internal URL contains a nonstandard 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 sign in identities mentioned above.

In this case there's 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 authenticated users in Microsoft Entra ID. Passthrough preauthentication doesn’t trigger Microsoft Entra authentication, so Conditional Access Policies can't be enforced. With passthrough preauthentication, MFA policies must be implemented on the on-premises server, if possible, or by enabling Microsoft Entra ID 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) can't 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 doesn't 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 isn't 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's no SSO applied to the WebSocket request.
• Features (Eventlogs, PowerShell, and Remote Desktop Services) in the Windows Admin Center (WAC) don't 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