Posted May 4, 2020 by Ronny de Jong .

Remote anything: Publish complex ‘full-path’ web applications with Azure AD Application Proxy

These days where households are rapidly turning into remote offices the need to make business applications available as if they were available from the office is on the rise. Azure AD Application Proxy lends perfectly to secure unlock on-premise web applications in an ease and safe manner.

In this post I’ll explain how successfully publish on-premise SAP instance with a complex home page URL, which seem challenging at first sight. After reading this post not anymore!

Applications today

In general we can make a distinction of application types such as SaaS- and Line of Business (LOB) applications. SaaS applications characteristics by Cloud- or Server Hosted applications where LOB applications usually lives on-premises.

There is a variety of on-premise LOB applications which can be published via Azure AD Application Proxy or with 3rd party integration (e.g. F5, ZScaler, Akamai or NetScaler) in order to support a full range of authentication methods.

Publish SAP with complex home page URL

In this scenario a customer wanted to publish an on-premise SAP instance which is normally only reachable when physically at an office location of by using VPN. This SAP instance which is hosted on a Linux instance doesn’t require single sign-on nor provisioning, just publishing in a controlled and secure way.

Challenge

The challenge we’d to overcome is to publish the application with it’s full-path internal URL including special characters and query string. By default Azure AD Application Proxy wizard enforces you to respect prerequisites the internal URL should meet.

A workaround here is to publish the application with the root-path URL and reconstruct the full-path URL using shortcuts at your endpoints. Although it is working, it feels like cheating and doesn’t give you always the predicted result your users expecting.

The solution

The trick here is to adjust the corresponding App registration of the Enterprise Application and changing the Home Page URL.

Browse in Azure AD to App registrations and find the corresponding application (SAP) we created before during the Enterprise Application wizard.
Edit the Home page URL and append the root-path URL https://sapnfd-yourdomain.msapproxy.net with the full-path URL part including the special characters and save your new configuration.

When going back to our Enterprise Application and review it’s properties, it has been updated with the full-path home page URL including special characters.

Of course we can change the home page URL using PowerShell.

With this we succeeded publishing SAP to our end-users via the new experience MyApps portal https://myapplications.microsoft.com/ using ‘Collections’ to organize our line of business applications.

Proof is in the eating! Now end-user can easily access on-premise SAP in an easy and secure way, taking benefit of what Azure AD offer. This includes e.g. pre-authentication, Azure MFA or other context aware conditions by Conditional Access.

In the ideal world we would use SAP as a SaaS- or hosted application, however these are complex and lengthy transitions. This scenario is a simple example of addressing current needs in world of remote anything!

Modernize your apps!

The above example is just a simple but impactful step to ‘modernize’ your applications. Where to start as there are so many apps out there!? Start to discover and categorize your current SaaS applications, which can be a manual task but most preferable (semi) automatic process using for example Microsoft Cloud App Security or Usage & Insights in Azure AD.

Start with 3rd party SaaS apps in Azure AD Gallery as they are by far the easiest category to integrate.
Next step will be 3rd party SaaS apps which are not listed in the Azure AD Gallery but can be integrate using SAML or other options. Commonly this can be found on the supplier’s website.
Applications which are federated by ADFS can be easily migrated using the Usage & Insights of Azure AD. You have to install Azure AD Connect Health agent for ADFS which can be downloaded here.
Last hurdle are legacy apps. These might in some cases hard to migrate but might be critical for your business. Azure AD Application proxy or Application Delivery Controllers such as Akamai, Citrix Netscaler, F5 or ZScaler.

A good starting point is Resources for migrating applications to Azure Active Directory website and forms a good guidance of your journey modernizing your application landscape.

Sources

By writing up my experience I came a cross the below article of Microsoft which perfectly describes this scenario. Let’s put it this way: the power is in the repetition!