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:
- Travel: https://travel.adventure-works.com
- Expenses: https://expenses.adventure-works.com
- 3 other applications with a similar format: https://*.adventure-works.com
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.
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 email@example.com
- February 2019 (1)
- September 2018 (1)
- August 2018 (2)
- July 2018 (2)
- June 2018 (3)
- May 2018 (2)
- April 2018 (1)
- March 2018 (2)
- February 2018 (2)
- January 2018 (1)
- December 2017 (1)
- November 2017 (2)
- October 2017 (2)
- September 2017 (2)
- August 2017 (2)
- July 2017 (2)
- June 2017 (1)
- May 2017 (3)
- April 2017 (1)
- March 2017 (3)
- February 2017 (2)
- January 2017 (3)
- December 2016 (2)
- November 2016 (2)
- October 2016 (3)
- September 2016 (1)
- July 2016 (1)
- June 2016 (3)
- May 2016 (2)
- April 2016 (5)
- March 2016 (2)
- February 2016 (1)
- January 2016 (4)
- December 2015 (5)
- November 2015 (5)
- October 2015 (5)
- September 2015 (4)