Using Wildcard in AD App Proxy

Do you know how many cloud applications are being accessed by your employees?
Are your employees sharing valuable information via emails and attachments?
Is Your Help Desk Inundated with Password Reset Requests Over and Over?
Get Started With A FREE Trial Get Started With A FREE Trial Request a Consultation Request a Consultation Download FREE MOBILE DEVICE SECURITY REPORT

Howdy folks. We wanted to let you know about a cool new capability that improves the management experience for Azure AD Application Proxy. Drum roll…


You can now use wildcards(*) to publish many applications at once. Wildcards will also let you apply the same settings such as authentication method and user assignment for each of those applications.

This capability, which is now in public preview in Azure AD Application Proxy does the following: reduces your administrative work, reduces opportunities for error, and helps make your users more efficient.

How to Use The Wildcard

In order to use this new capability, you simply must configure the URL for the Application Proxy application to include a wildcard (*). All other steps are the same as publishing any other application with Application Proxy. Then, all applications that are in scope of the wildcard can be accessed using Azure AD application proxy.

Example, let’s say your company, Ocean View MotorCycles, has five applications on-premises that you want to publish for external access by your users:

Now because of  this new capability, you don’t need to publish and manage five individual applications. Now you can use a wildcard to publish and manage these as a single application, https://*.adventure-works.com. Publish the wildcard application the same way you publish any Application Proxy application, with the wildcard (*) in the internal and external URLs.

wildcard

Figure 1. Application Settings Including a Wildcard in the URLs

All applications in scope of the wildcard can be accessed by the same set of users and groups that are assigned to the application. Applications published through a wildcard need the same type of single sign-on method. Each of the published applications can be accessed by the users and groups that are assigned to the wildcarded application.

If the application uses Windows Integrated Windows Authentication, you will also need a wildcard in the Single Sign-On settings if the SPN is not the same across applications.

Figure 2. Wildcard in Single Sign on settings for an application with Windows Integrated Authentication


Exceptions: what are the right settings for every app

You can still use wildcards even if you have some applications whose requirements (ex: users, single sign-on method) differ from the others but match the wildcard pattern. For example, say you have an application https://finance.adventure-works.com that has different access requirements than your other applications on https://*. In this case, you can publish another application, https://finance.adventure-works.com and assign different users or configure different settings for it.

The settings and access for the most specific URL always take precedence over wildcards. To learn more about how to exclude applications from a wildcard publishing, see the documentation.

Microsoft believes wildcards will help you use Azure AD Application Proxy to give your users access to more of the resources they need. Wildcards can also help you ensure consistent access and settings for applications that share common requirements.

To learn more about wildcards and Azure AD Application Proxy, see the documentation. To begin publishing an application, sign in to the Azure AD Admin Center.

For more information on this or any EMS solution visit mobility.messageops.com or email info@messageops.com

(Visited 21 times, 1 visits today)