Hello folks,

Today I want to talk about how your published applications show up to end users. And how you can configure your app to ensure that users land on the appropriate page when accessing it. Based on the feedback we’ve received this is a topic of great interest for many of you.  

As you are aware, when you grant users the ability to access published applications, those applications show up in the Azure AD Access panel and the Office365 App Launcher. By default, when users launch these applications they are taken to the home page url of the published application. The home page url is, by default, set to the front-end url of the published application.

For example, consider a backend application http://ExpenseApp that is published as https://expenseApp-contoso.msappproxy.net. By default, the home page url is set to https://expenseApp-contoso.msappproxy.net and users clicking the app will be taken to that URL.  

However, in some cases, we’ve heard that customers want users to land on a specific page within the application, for example https://expenseApp-contoso.msappproxy.net/login/login.aspx. This is a very common request and one that makes perfect sense in multi-page applications that have a specific logical starting point.

Today, I’m very pleased to announce that you can now do this by configuring the ‘home page url’ of the published application.  The process requires you to use a PowerShell module. Don’t worry though, we are working to provide this as a UI option to make it easier :). However, rather than hold the feature until we get the UI completed we wanted to share this with you so you could use the steps below to configure your applications right away. 

Ross, a Senior Program Manager in the team, has been focusing on getting this capability into your hands as soon as possible. Let me have him introduce it to you. 

Go on, give this a try! And as always, if you have any feedback on this please send us a note at aadfeedback@microsoft.com. We look forward to hearing from you.

Thanks,

I’m Ross Adams and I’m a Senior Program Manager in the Azure Active Directory team, focusing on Application Proxy and other Hybrid Identity technologies.

Alright, let’s walkthrough how to setup a custom home page url for your published application. 

Before we begin

There are a couple of items to note when you set the homepage url:

1.    You must make sure that the path you specify is a sub path of the frontend url. 

For example, if the intranet application is published with a front-end url of https://intranet-contoso.msappproxy.net/ then the homepage url that you configure must start with https://intranet-contoso.msappproxy.net/. Similarly, if the front-end url is https://apps.contoso.com/app1/ then the home page url must start with https://apps.contoso.com/app1/

2.     If you make a change to the published application, it may reset the value of the home page url. So if you do update the application you may need to recheck/update the homepage url. 

Using Azure AD Powershell module

To set the home page url using powershell, you need to get the Azure AD PowerShell module installed.  This isn’t the standard Azure AD PowerShell module but a package from the PowerShell Gallery that uses the GRAPH API end point.  More information about the package can be found here (https://www.powershellgallery.com/packages/AzureAD/1.1.23.0) including instructions, which are relatively simple as follows:

1.      Open PowerShell.

2.      Run the following command

Install-Module -Name AzureAD -RequiredVersion 1.1.23.0

NOTE: if you are running this as a non Admin you will need to use the additional option of “-scope currentuser”.

3.      During the install it will install two packages from Nuget.org, please select “Y” to install these as they are needed to use the package. 

Setting a Home Page URL Value

Now that you have the Powershell Module installed we’re ready to set the home page url using two simple steps:

1.      Find the application you want to update.

2.      Update the homepage URL for the application.

Step 1 – Finding the ObjectID of the application

To obtain the ObjectID of the application I’m going to search for the application by the homepage. 

1.      Open PowerShell.

2.      Import the AzureAD module

Import-Module AzureAD

3.      We now need to login.  Use the cmdlet below and follow the instructions on the screen. Make sure you login as the tenant administrator.

Connect-AzureAD

4.      The cmdlet below will find the applications based on the homepage containing “sharepoint-iddemo”. The app I’m looking to edit. Just replace this with the value that works for your application.  Note I filtered the return result for easier reading.

Get-AzureADApplications | where { $_.Homepage -like “*sharepoint-iddemo*” } | fl DisplayName, Homepage, ObjectID

5.      You should see something similar to the following. The GUID (in bold below) is the value we are looking for:

DisplayName : SharePoint

Homepage    : https://sharepoint-iddemo.msappproxy.net/

ObjectId    : 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4

6.      Copy the GUID value you see to the clipboard. We’ll need that in step 2.

Step 2 – Updating the Homepage URL

We are going to use the same tool to update the homepage URL as we did to find the application.  In my case the application ID I want to update is “8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4”. 

I’m assuming you are still logged into PowerShell, if not then repeat steps 1 to 3 above, then follow the steps below:

1.      Confirm you have the right application, just replacing “8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4” with the value of your application that you copied above.

Get-AzureADApplication -AppObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4

2.      Now that we have confirmed the application we are ready to update the homepage as follows.

a.      Create a blank application object to hold the changes we want to make; this doesn’t create anything; it is just a variable of the right type to hold the values we want to update.

$appnew = New-Object “Microsoft.Open.AzureAD.Model.Application”

b.      Set the homepage to the value you want it to be, keep in mind that it must be a sub path of the published application.  In my case I’m going to change my homepage from https://sharepoint-iddemo.msappproxy.net/ to https://sharepoint-iddemo.msappproxy.net/hybrid/ so uses go straight to the hybrid site.

$appnew.Homepage = “https://sharepoint-iddemo.msappproxy.net/hybrid/”

c.      Now we just need to make the update, remember to use the GUID you copied from above.

Set-AzureADApplication -AppObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4 -Application $appnew

3.      You’re all done, and we can confirm by getting the application again and making sure the change worked.

Get-AzureADApplication -AppObjectId 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4

Keep in mind that certain changes to the application in the UX will reset the HomePage URL so you might have to do this again.

Hope you find this useful and as always we appreciate your feedback.

Hello folks,

Azure AD App proxy is a simple secure way to facilitate remote access to on-prem applications. SharePoint sites continue to be the top applications that customers integrate with Azure AD application proxy. And given SharePoint’s native Kerberos support, users accessing internal sites remotely through the Azure AD application proxy, can get a seamless single sign-on experience.

Given the popularity of this setup and considering how many of you can benefit from doing this, I decided to dedicate this blog post to a step-by-step guide on how to integrate SharePoint server on-premises to Azure AD application proxy—so more numbers of you could get all the phenomenal value that comes with it.

A lot of other customers have already done this successfully to great benefit. With this guide, hopefully, you can do so quickly as well.

Ross Adams, a Senior Program Manager in the team, decided to put together a setup on this against which we based the write-up below.

Go on, give this a try! And as always, if you have any feedback on this please send us a note at aadapfeedback@microsoft.com. We look forward to hearing from you.

Thanks,

Girish Chander.

@chander_girish

Alright, let’s walkthrough how to setup an existing SharePoint 2013 server with Azure AD Application proxy.

Before we begin

I’m going to assume that you have SharePoint 2013 already setup and running just like you want in your corporate environment, so I’m not going to walk through the actual setup of SharePoint.

On the SharePoint server, there are a few configuration changes we’re going to have to make. So if you have a staging environment, follow this guide on the staging server, to understand any impacts before you go to production.

I’m also going to assume that you have setup SSL for SharePoint as we require SSL on the published url. You will need to have SSL enabled on the internal site, to ensure links are sent/mapped correctly. If you haven’t configured SSL, then take a look at this blog that has instructions for setting it up. Make sure that the connector machine trusts the cert you issue, but it need not be a publicly issued certificate.

Now that we have the disclaimers and pre-requisites out of the way, let’s get into the details.

To the fun part…

At a high level, these are 6 steps that we need to perform:

Part A: Configure Single Sign-on

1. Ensure SharePoint server is running as a service account
2. Configure SharePoint for Kerberos
3. Set an SPN for the account that SharePoint is running under
4. Ensure the Connector is trusted to delegate to SharePoint

Part B: Enable secure remote access:

5.  Publish the SharePoint farm to Azure AD App proxy

Part C: Ensure SharePoint knows about the External URL:

6.  Set Alternate Access Mappings in SharePoint

Part A: Setting up Single Sign-on to SharePoint

We are targeting getting the best single sign-on experience to the back-end application, SharePoint server in this case. In this scenario, the user authenticates once in Azure AD and is not prompted for authentication again.

For on-premises applications that require or use Windows authentication, this can be achieved using the Kerberos authentication protocol and a feature called Kerberos constrained delegation or KCD for short. KCD, when configured, allows the application proxy connector to obtain a windows ticket/token for a given user, even if the user hasn’t logged into Windows directly. You can learn more about Kerberos Constrained delegation here.

Let’s see how we can set this up for our SharePoint server

Step 1: Ensure SharePoint is running under a service account, not local system, local service or network service

The first thing we need to do is to make sure that SharePoint is running under a defined service account. We need this so we can attach SPNs (service principal names) to a valid account. Service principal names are how the Kerberos protocol identifies different services. And we’ll use it later to configure KCD.

To ensure your sites are running under a defined service account do the following:

1. Open the SharePoint 2013 Central Administration site.
2. Under Security select Configure service accounts
3. Select Web Application Pool – SharePoint – 80, it may be slightly different based on the name of your Web pool and if it uses SSL by default.
5. If the Select an account for this component is local service or Network Service then you need to create an account, if not your all done and can move to the next step.
   1. Click on Register new managed account.
   2. You will need to have a pre-created AD account for the service and the best suggestion is to allow for automatic password change. You can find out more details about the full set of steps and troubleshooting issue here. In my case, I created an account called Demo\sp_svc.
   3. Once created you should set the Web Application Pool to use it.

Step 2: Configure SharePoint for Kerberos

As I said before, we use KCD to perform single sign-on to the SharePoint server and this only works with Kerberos. So let’s make sure that the site is configured for Kerberos authentication.

1. Open the SharePoint 2013 Central Administration site.
2. Under Application Management click on Manage web applications and select your SharePoint site “SharePoint – 80” in my case
4. Next click on Authentication Providers in the tool bar above
5. In the dialog box titled Authentication Providers click on the Default zone to view the settings.
6. In the dialog box Edit Authentication, scroll down to you see Claims Authentication Types and ensure that both Enable Windows Authentication and Integrated Windows Authentication are both checked and the drop down box is configured to Negotiate (Kerberos).
8. Scroll to the very bottom and click on Save.

Step 3: Setting an SPN for the SharePoint Service Account

Before we can configure Kerberos Constrained delegation we need to be able to identify the SharePoint service running as the service account we configured above. We do this by setting a service principal name (SPN). You can read more about SPNs here if you like,

The SPN format:

The typical format for an SPN is: <service class>/<host>:<port>

Where:

<server class> is a unique name for the service. For SharePoint we will use ‘HTTP’

<host> is the fully qualified domain name or Netbios name of the host the service is running on. In the case of a SharePoint site, this may need to be the URL of the site as well depending on the version of IIS that is being used.

<port> is an optional

If the FQDN of the SharePoint server is: sharepoint.demo.o365identity.us, the SPN would be: HTTP/ sharepoint.demo.o365identity.us demo. However, in addition to this, you may also need to set SPNs for specific sites in your server. For more details, see this article here, paying special attention to the section called “Create Service Principal Names for your Web applications using Kerberos authentication”

The easiest way to do all this may be to follow the SPN formats that may already be present for your site. And copy those SPNs to register against the service account. To do this:

1. Browse to the site from another machine. <When you do, the relevant set of Kerberos tickets are cached on the machine. These tickets contain the SPN of the target site that you browsed to. We can pull the SPN for that site using a tool called Klist>.
2. In a command window running in the same context as the user who accessed the site in the browser run the following command: Klist
3. It will return the set of target service SPNs. In my case, the highlighted value is the SPN I need:
5. Now that we have the SPN we need to make sure that it is configured correctly on the service account we set for the Web Application earlier. Follow the steps below:

Setting the SPN:

1. To set the SPN, just run the command below from the command prompt as an Administrator of the domain:

setspn -S http/sharepoint.demo.o365identity.us demo\sp_svc

This command sets the SPN for the SharePoint service account running as demo\sp_svc.

Remember to replace ‘http/sharepoint.demo.o365identity.us’ with the SPN for your server and ‘demo\sp_svc’ with the service account in your environment. The setspn command will search for the SPN before it adds it so you may see a “Duplicate SPN Value” error. If you see this make sure that the value is associated with the service account.

You can read more about the setspn tool here.

1. You can verify the SPN was added by running the setspn command with the -l option, as described in the link earlier.

Step 4: Ensure the Connectors are trusted to delegate to SharePoint

In this step we are configuring Kerberos Constrained delegation, referenced earlier.

Essentially, we’re going to enable the Application Proxy Connector machine to be able to retrieve a Kerberos ticket for a user who was authenticated in Azure AD, then pass that context to the target application, SharePoint in our case. In other words, we’re going to make sure that the connector machine is capable of delegating user identities to the SharePoint service.

Since in my environment I only have one connector machine I’ll show you how to do that one server, but you need to repeat this for each connector machine.

1. Login as a domain administrator to a DC and open Active Directory Users and Computers.
2. Find the computer that the connector is running on, in my case it is the same server SharePoint.
3. Double Click on the computer and then click on the Delegation tab.
4. Ensure the delegations settings are set to Trust this computer for delegation to the specified services only and the select option User any authentication protocol is selected similar to the following.
6. Now we are going to add the SPN that we created earlier for the service account by clicking on the Add button, then Users or Computers and finding the account we created earlier, sp_svc in my case.
7. This should give you a list of SPNs to use. We only need to add the one that we set above so select that item and click on OK.
9. Click on OK again to save the change.

Part B: Enabling Remote access to SharePoint

Now that we’ve enabled SharePoint for Kerberos and configured Kerberos Constrained Delegation so we can single sign on to SharePoint from the connector, we can publish SharePoint for remote access through the Azure AD Application Proxy.

Step 5: Publish SharePoint with Azure AD App Proxy

To perform the steps below, you need to be part of the Global administrator role within your organization’s Azure Active Directory.

1. Log in to the Azure Management portal https://manage.windowsazure.com and find your Azure AD Tenant.
2. Click on Applications and click Add at the bottom.
3. Select Publish and application that will be accessible from outside your network. If you don’t see this option, make sure you have Azure AD Basic or Premium in the tenant.
4. In the resulting dialog box complete each of the 3 options as follows then click on the tick:
   1. Name – Any value you want for example SharePoint.
   2. Internal URL – This is the URL of the SharePoint site internally https://SharePoint/ in my case, make sure to use https.
   3. Pre-Authentication Method – Select Azure Active Directory.
5. Once the app is published, click on Configure tab.
6. Scroll down to the option that reads: Translate URL in Headers. The default value is ‘yes’, change this to No.To ensure that SharePoint accepts this url, we need to complete one more configuration on the SharePoint server. We’ll do that next, but let’s finish publishing the site first.
7. SharePoint will use the value specified in the ‘Host Header’ to lookup the site and will also generates links based on this value. But the net effect is that doing this makes sure that any link SharePoint generates is under the published url is correctly set to use the external url.
8. When the default value of ‘yes’ is used, the connector will translate the published url to the internal url and use that in the ‘Host Header’, amongst other items, and forward the request to the backend application. However, setting this to ‘no’ means that the connector will not send the internal host name, but will send the host header as the published url to the backend application, in my case, “SharePoint-iddemo.msappproxy.net”.
9. Change the Internal Authentication Method to Windows Integrated. If your Azure AD tenant uses a different UPN in the cloud to the one on-premises, then remember to update the Delegated Login Identity.
10. Set the Internal Application SPN to the value we set above – http/sharepoint.demo.o365identity.us
11. Your application should look similar to the following.
13. At this stage you can assign the application to target users.

Part C: Ensure SharePoint knows about the External URL

The last thing we need to do is to ensure that SharePoint can find the site based on the external URL and renders links based on the external url. We do this by configuring alternate access mappings for SharePoint.

Step 6: Configure an alternative name for the SharePoint site

1. Open the SharePoint 2013 Central Administration site.
2. Under System Settings select Configure alternate access mappings
4. In the drop down beside Alternative Access Mapping Collections: select Change Alternative Access Mapping Collection and in the dialog box select your site, in my case SharePoint – 80
6. You can choose to add the published URL as either an internal URL or a public URL. In my case I’m going to use a public URL as the extranet.
7. Click on Edit Public URLs in the Extranet path enter the path that you publish the application as in the previous step. In my case https://sharepoint-iddemo.msappproxy.net
9. Click Save.

Your now ready to access the SharePoint site externally via Azure AD Application proxy, happy surfing.

Hello folks,

In this forum, you typically hear from us in the product team as we cover different aspects of Azure AD App proxy value and feature set. For today’s post I thought it would be good for you folks to hear about the App proxy as seen through the eyes of someone outside of the product team.

Wes Kroesbergen is an EMS (Enterprise Mobility Suite) Blackbelt. His job entails working with customers to help them understand and adopt different features across our Enterprise Mobility Suite offering. I met Wes recently on a trip to Toronto where we were meeting customers together. And while there Wes couldn’t stop talking about how excited he was about the App proxy. So I decided to have him put together a guest blog post here, so you could hear from him directly.

Enjoy!

Girish Chander.

@chander_girish

Increasing Security Posture and Operational Efficiency with Azure AD App Proxy

Hello! As part of the Americas EMS Blackbelt team, I visit with many enterprise customers, helping our customers understand the immense value in our Enterprise Mobility Suite. One of the things I’ve observed is a lack of awareness around some of the powerful capabilities of our identity services, and how our cloud-first development is also geared toward accruing value for on-premises applications. The Azure AD team has granted me the privilege today to guest post on one of the most untapped features of Azure AD: Azure AD App Proxy.

Azure AD App Proxy delivers three very key business values for organizations leveraging the Enterprise Mobility Suite:

• Improve Security Posture
• Improve Operational Efficiency
• Reduce VPN Overhead

Let’s dig into each of these in more detail.

Improve Security Posture

Reduce Ingress Points

Azure AD App Proxy enables customers to begin paring down the services they expose through their on-premises perimeter. App Proxy works by setting up an outbound connection to Azure datacenters, with no inbound ports required on the perimeter. Azure’s datacenters then act as the proxy front-end, transparently mitigating attacks like Denial of Service against the endpoint. Authenticated, authorized users are proxied back through the established connection with your network, and seamlessly sign your users into their applications via secure Kerberos delegation. Below is a high-level diagram describing how this feature works.

Mitigate Out of Date Appliances

Updating firewall appliance firmware can be disruptive. Unfortunately, it is also necessary as attackers leverage known vulnerabilities with ever increasing speed. By shifting the ingress point to Azure’s datacenter, the risks of compromise via out-of-date firmware on a current or deprecated firewall appliance is reduced.

Protect Identities with Machine Learning

We recently introduced Azure AD Identity Protection in public preview. Identity Protection combines machine-Learning driven security intelligence with data feeds from Microsoft’s Digital Crimes Unit and Microsoft Security Response Center to proactively identify compromised accounts and offers real-time protection from risky sign-ins.

With Azure AD App Proxy, we are able to extend the powerful protection that comes with Azure AD Identity Protection to even a 15-year old legacy application sitting on-premises and created well before the cloud-first, mobile-first world was on the horizon! Wow, just imagine!

Below is a sample screenshot of Identity Protection.

Remove Password Exposure with Windows 10

With Windows 10, we introduced Microsoft Passport, an incredibly powerful, password-less authentication method for Azure AD Joined machines. When Windows 10 is joined to Azure AD via strong authentication (MFA), a secure key pair is generated, with the private key being stuffed into the TPM chip, and the public key is registered with Azure AD. When the user authenticates to an Azure AD resource like an App Proxy app, the private key from the TPM chip is used to authenticate the user to Azure AD. The powerful combination of Microsoft Passport and Azure AD App Proxy delivers incredible, anywhere access to on-premises resources without the overhead of a traditional VPN or DirectAccess infrastructure.

Improve Operational Efficiency

Increase Agility

One of the things I’ve noticed as I work with customers is the timelines for exposing services through the perimeter. Rigorous change controls often drag timelines out to multiple weeks. One organization I talked to said it takes up to 6 weeks to get network changes made! Once Azure AD App Proxy is in place, access to resources becomes just a part of the Identity and Access Management tasks, without the overhead of network infrastructure.

Achieve High Availability Easily

Exposing services in a highly-resilient fashion through the perimeter is often expensive and complicated. Achieving resiliency with App Proxy is as simple as installing the connector on another on-premises server! Each connector sets up its own out-bound tunnel to the Azure datacenters, and the App Proxy service takes care of all the complexities distributing traffic as it flows back to access the on-premises applications!

Reduce VPN Overhead

Improve Mobile Experiences

VPN over mobile networks is often unreliable. VPN protocols generally involve some level of overhead to keep the tunnel alive, and on bandwidth constrained mobile connections, or devices in a poor coverage range, the VPN tunnels are often unreliable. Leveraging App Proxy can enable better application experiences, due to the removal of VPN tunnel overhead.

Summary

Azure AD App Proxy is an incredibly powerful business enabler. App Proxy can enable your business to improve its security posture, improve operational efficiency, and reduce VPN overhead. Every customer I’ve talked to about this feature is immediately excited and eager to try it out. I encourage you to investigate leveraging this powerful capability within your environment.

Hi folks,

Over the past few weeks we’ve had a number of customers ask us about network considerations to take into account when deploying the Azure AD app proxy. Where should the connectors be deployed? What usage characteristics determine the best option?

This has come up often enough that I decided it was time to write this down in a post.

First some basics:

Traffic flow:

When an application is published through Azure AD app proxy, all traffic from the users to the target backend applications flows through 3 hops.

1. Hop 1: User to Azure AD App Proxy service’s public endpoint on Azure
2. Hop 2: App proxy service to the connector
3. Hop 3: Connector to target application

Tenant location and App proxy service location:

When you sign up for an Azure AD tenant, the region of your tenant (US, EMEA, APAC etc) is determined based on the country you specify. When you enable App proxy, the App proxy service instances for your tenant are lit up in the same region as your Azure AD tenant (or the closest region to it).

Note: currently, as of this post date, the app proxy instances are available in EMEA, Australia and US.

E.g – If your Azure AD Tenant’s region is EU, all your Azure AD Application Proxy connectors will be connected to the App proxy service instances in Azure data centers in EU. This also means that all your users will go through the app proxy service instances in this location, when trying to access published applications.

Before you ask J, there currently isn’t any way to change your AAD tenant’s region or App Proxy server instance region, once it has been established

Considerations for reducing latency

First off, remember that any proxy solution introduces latency into the connection.

No matter which proxy or VPN offering you may choose as your remote access solution, it will always include a set of servers enabling the connection to inside your corporate network. Traditionally these have been server endpoints in your DMZ, but of course, in the case of the Azure AD App proxy, no DMZ is needed. When using the Azure AD App proxy, as covered above, traffic flows thru the proxy service in the cloud and the connector in the corporate network.

Connector Placement:

While the App proxy service instances’ location is chosen for you (based on your tenant location), you get to decide where to install the Connector. And that can have a great influence on the end-to-end latency characteristics of the traffic.

As you evaluate the options, here are some of the questions to ask:

1. Where is the app located?
2. Where are the majority of the users accessing the app from?
3. Where is the app proxy instance located? <remember this follows your tenant>
4. Do you already have a dedicated network connection to Azure Data Centers (like Express Route or similar VPN set up)?

The placement of the connector will determine the latency of hop #2 and hop #3. When evaluating the placement of the Connector you should consider the following:

• The connector will need line of sight to a DC to perform KCD operations, when u want SSO to backend applications.
• The connector is typically installed closer to the app to reduce time from the connector to the application.

General approach:

You can try and minimize the latency of the end to end traffic, by optimizing each of the network hops that the traffic flows over.

Each hop can be optimized by:

1. Reducing the ‘distance’ that between the two ends of the hop
2. Choosing the right ‘network’ to traverse. For example, traversing a private network <when available> rather than the public internet may be faster due to dedicated links.

   For example, if you have a dedicated VPN/Express Route link between Azure and your corporate network, you may want to leverage that.

Focusing your optimizing strategy

Since your users are accessing the app remotely over the internet anyways, it makes sense to focus on optimizing hops 2 and 3. Below are some of the common patterns to follow.

Pattern #1: Prioritize optimizing hop #3:

In this pattern, the connector is placed close to the target application in the customer network. The advantage with doing this, as called out above, is that the connector is likely to need line of sight to the Domain Controller anyways. This approach optimizes hop #3 and is usually enough for most customers and scenarios. Most of our customers follow this pattern.

Optimizing hop #2 and #3:

There are some scenarios where you will need to optimize both hop #2 and hop #3 to get the latency characteristics you want. If you have a VPN or ExpressRoute setup between your network and the Azure datacenter, that allows you to optimize hop #2 in addition to hop #3.

Pattern #2: Taking advantage ExpressRoute with public peering

If you have an ExpressRoute setup with public peering, then we will leverage the faster ExpressRoute connection for hop#2. Hop #3 is already optimized by placing the connector close to the app in the customer network.

Pattern #3: Taking advantage ExpressRoute with private peering

If you have a dedicated VPN or Express Route setup with private peering between Azure and your corporate network where the app is installed, you have another option. In this configuration, the virtual network in Azure is typically considered as extension of the corporate network. So you can install the connector in the Azure datacenter and still satisfy the low latency requirements of the connector-to-app connection for Hop #3. Latency is not compromised because traffic is flowing over a dedicated connection. However, you get the added benefit of improving the latency characteristics of hop #2. This is because the Proxy service-to-connector connection (hop #2) is a shorter hop, as the connector is installed in an Azure datacenter close to your AAD tenant (and therefore App proxy) location

Other approaches:

While the focus above has been on the placement of the connector, I should point out that, if moving the application is an option (for example: to Azure or another hosted environment), then the application’s placement can be changed to get better latency characteristics. Increasingly, organizations do have their networks stretch into a hosted environment. If so, this allows the app to be placed in the hosted environment that is part of the corporate network and still be ‘within the domain’. In that case, the above patterns can be applied to this new application location.

If you’re considering this option, do take a look at Azure AD Domain Services—which offers a ready AD like environment in the cloud, into which you can move apps that rely on LDAP.

Also, consider using connector groups to target apps that are in different locations/networks.

Common Scenarios:

In the section below I walk through a few use cases to make this clearer. For all the cases below, let’s assume the Azure AD tenant (and therefore proxy service endpoint) is in the US. You can extrapolate to other regions and the same considerations will apply.

Use Case 1: App is in a customers’ network in the US. And most users are in the same region. No express route or VPN between and Azure DC and the corporate network.

Recommendation: Follow pattern #1 above. For improved latency, consider leveraging ExpressRoute, if needed <see use case #3 and #4>

This is the simple case. The most common pattern is to optimize hop#3. The connector is placed near the app. This is also a natural choice, because the connector typically is installed with line of sight to the app and to the DC to perform KCD operations.

The picture below follows pattern #1 above.

Use Case 2: App is in a customers’ network in the US. And users are spread globally. No express route or VPN between and Azure DC and the corporate network.

Recommendation: Follow pattern #1 above. For improved latency, consider leveraging ExpressRoute, if needed <see use case #3 and #4>

As covered above, the common pattern is to optimize hop#3. The connector is placed near the app for reasons covered above. Hop #3 is not too expensive as it is all within the same region. However, hop #1 can be expensive depending on where the user is, because all users will hit the app proxy instance in the US. <It’s worth noting that any proxy solution will have similar characteristics here with respect to users being spread out globally>

Again this matches pattern #1 above.

Use Case 3: App is in a customers’ network in the US. ExpressRoute with public peering exists between Azure and the corporate network.

Recommendation: Place the connector closest to the app. The system will automatically use ExpressRoute for hop #2. This follows pattern #2 described above.

If the ExpressRoute link is using public peering, then the traffic between the proxy and the Connector will flow over that link and hop#2 will have optimized latency.

Use Case 4: App is in a customers’ network in the US. ExpressRoute with private peering exists between Azure and the corporate network.

Recommendation: Place the connector in the Azure DC that is connected to the corp network through ExpressRoute private peering. This follows pattern #3 described above.

The Connector can be placed in the Azure DC. Since it still has line of sight to the application and the DC through the private network hop #3 remains optimized. However, this setup additionally optimizes hop #2 further.

Use Case 5: App is in a customers’ network in the EU. And most users are in the US.

Place the connector near the app. For the reasons covered above, this is the natural choice. Since the US users are hitting an app proxy instance that happens to be in the same region, Hop#1 is not too expensive. Hop #3 is optimized. However, Hop #2 is expensive in this story.

Consider leveraging ExpressRoute as called out in patterns #2 and #3 above. Below I show pattern #2 applied.

One other variant to this use-case that you can consider employing is below:

If most users in the organization are in the US, then chances are that your network ‘extends’ to the US as well. If that is the case, the connector can be placed in the US and can leverage the dedicated internal corporate network line to the application in the EU. This way hop #2 and hop#3 are optimized.

Future improvements:

We are looking into making proxy instances available in more datacenters around the globe and making the proxy instances more geo aware. This could help reduce the latency on hop #1 and hop #2 across many of the cases above.

As always, we’d love your feedback. Contact us at aadapfeedback@microsoft.com with any comments/questions that you might have.

Girish Chander

Principal PM Manger, Identity Division, Microsoft

@chander_girish

Hi folks,

I often get security-related questions from customers evaluating the Azure AD App proxy for the first time. And I’ve noticed that lot of these questions betray a more traditional outlook towards providing remote application access. These traditional mechanisms to offer remote access have typically involved installation of costly servers on-prem. And because there was unauthenticated traffic arriving at the customer network, these approaches have required careful analysis of access patterns and the deployment of additional security infrastructure like WAF servers, with the added cost of installing, maintaining, monitoring and patching them.

Azure AD app proxy, on the other hand, offers ‘remote access as a service’ and takes a different approach. In this context, therefore, the evaluation process of the solution warrants a rethink. And I’d assert that a lot of the pain associated with the traditional approaches can be side-stepped.

In today’s post, Ross Adams (a Senior PM on the team) and I decided to tackle the topic of security in the context of remote application access. The goal here is to provide you and your security teams enough context to understand how Azure AD app proxy provides a secure service for publishing and accessing your applications. And how different capabilities of Azure AD come together to offer a very secure remote access solution.

A different approach—with great security benefits

When evaluating the security of the remote access solution offered by Azure AD app proxy, it is useful to keep the following in mind:

• Authenticated access: Only authenticated connections hit your network
  • Azure AD app proxy is best suited to publish applications with pre-authentication. Azure AD app proxy relies on the Azure AD STS for all authentication. For applications published with pre-authentication, no traffic is allowed to pass through the app proxy service to your environment, without a valid STS token
  • Pre-authentication, by its very nature, blocks a significant number of anonymous attacks, as only authenticated identities are allowed to access the backend application.
• Conditional Access: Richer policy controls can be applied before connections to your network are established
  
  • With conditional access, it is also possible to further define restrictions on what traffic is allowed to hit your backend application. With conditional access, you can define restrictions based on location, strength of authentication and user risk profile.
  • This offers further stumbling blocks for attackers. You can read more about conditional access here.
• Traffic termination: All traffic is terminated in the cloud
  • Since the Azure AD application proxy is a reverse-proxy. All traffic to the backend application is terminated at the service. And the session is re-established with the backend server. This means that your backend servers are not exposed to direct HTTP traffic and targeted attacks like Heartbleed can be mitigated.
• All access is outbound: No inbound connections need be opened to the corporate network
  
  • The connectors maintain outbound connections to the Azure AD App proxy service. This means there is no need to open firewall ports for incoming connections.
    
  • On the other hand, traditional approaches required a DMZ and opening access to unauthenticated connections at the network edge. This resulted in the need for lot of additional investment in WAF products to analyze traffic and offer addition protections to the environment.
    
  • With app-proxy you can avoid this and even do away with your DMZ as all connections are outbound and over a secure channel.
    
• Security Analytics and ML based intelligence: New-age security protection
  • Azure AD Identity Protection combines Machine-Learning driven security intelligence with data feeds from Microsoft’s Digital Crimes Unit and Microsoft Security Response Center to proactively identify compromised accounts and offers real-time protection from risky sign-ins. This takes into account factors like accesses from infected devices, or through anonymizing networks, or from atypical and unlikely locations to increase the risk profile of a session, which in turn is used for real-time protection.
  • Many of these reports and events are already available through an API for integration with your SIEM systems.
  • You can read more about Azure AD Identity Protection here.
• Remote access as a service: You don’t have to worry about maintaining and patching on-prem servers
  
  • The Azure AD app proxy is an internet scale service that we own ensuring is always patched with the latest security patches and upgrades, so you don’t have to worry about it.
  • Unpatched software still accounts for a large number of attacks. With the service model, you don’t have to carry the heavy burden of managing these edge servers anymore and scramble to patch them as needed.

Additionally, as part of any evaluation of a cloud service there’re the obvious questions around how data is handled and secured in our data centers and operational environments. AAD AP, as part of the Azure set of cloud services, operates in accordance with the guidelines and standards that are outlined in the Azure Trust Center.

Evaluating the security of the app proxy solution:

A lot of security teams desire a deeper look at how the solution works.
The information below is provided to help you and your security teams understand how the AAD AP service provides a secure mechanism for publishing your applications.

Components of the solution:

Azure AD Application proxy can be logically broken into two parts:

1. The cloud based service (AAD AP) where most of the work is performed and to which external client/user connections are made.
2. An on-premises component called the AAD App Proxy connector, or ‘connector’ for short.  This connector listens for requests from the AAD AP service and handles connections to the internal applications, including taking care of items such as KCD (Kerberos Constrained Delegation) for SSO.

Different traffic flows—and how each is secured

There are a number of flows between the connector and the AAD AP service, each of which is detailed further below with a description of how these flows are secured.

1. When a connector is first setup
2. The connector periodically pulls configuration information from the AAD AP service. (Eg: the connector group the connector is part of)
3. When users access a published application

It is important to note that all communications occur over SSL, and always originate at connector to the AAD AP service, i.e. are outbound only.  The connector uses a client certificate to authenticate to the AAD AP service for all calls. The only exception to this is the initial setup step where the client certificate is established.

Installation of the connector

1. During install (connector registration to the service, happens as part of the install) of the connector, the user is prompted to enter their AAD admin credentials.  The token acquired is presented to the Azure AD App Proxy service (AAD AP).
2. AAD AP then evaluates the token to ensure that the user is a member of the company admin role within the tenant the token was issued for.  [If not, the process is terminated.]
3. The connector then generates a client certificate request and passes this with the token to the AAD AP service that in turn verifies the token and signs the client certificate request. The connector then uses this client certificate for future communication with the AAD AP service.
4. The connector then performs an initial pull of the system configuration data from the AAD AP Service using its client certificate and is ready to take requests.

Regular updates of configuration

1. The connector connects to the configuration end point within the AAD AP service using its client certificate.
2. Once the client certificate has been validated, the AAD AP service returns configuration data to the connector such as the connector group that the connector should be part of.
3. The connector will generate a new certificate request if the current certificate is more than 30 days old, effectively rolling the client certificate every 30 days.

Accessing a published application

1. When a user accesses a published application, the AAD AP service checks the configuration of the application.  If the application is configured to use Pre-Authentication with AAD the user will be redirected to the AAD STS to authenticate.  This is skipped in case the application is published using pass through.
   1. During authentication with AAD, AAD will check for any conditional access policy requirements for the specific application and ensures the user has been assigned to the application. (for example, if MFA is required the authentication sequence will prompt the user for a second factor authentication)
   2. Once all checks have passed, the AAD STS will issue a signed token for the application and redirect the user back to the AAD AP service.
   3. AAD AP will then validate the token to ensure that it was issued to the application that the user was requesting access to, along with other checks, such as ensuring the token was signed by AAD, is still within the valid window etc.
   4. AAD AP then sets an encrypted authentication cookie (i.e. a non-persisted cookie) to indicate that authentication to the application has occurred.  This cookie includes expiration timestamp based on the token from AAD and other data such as the user that the authentication is based on.  This cookie is encrypted using a private key known only to the AAD AP service.
      
   5. AAD AP then redirects the user back to the originally requested URL.
      

   NOTE: If any part of pre-authentication steps fails, the user’s request is denied and the user is shown a message indicating the source of the problem.

2. AAD AP upon receiving the request from the client validates that the pre-authentication condition has been meet and that the cookie is still valid (as required) and puts a request on the appropriate queue for an on-premises connector to handle.  (Remember, all requests from the connector are outbound to the AAD AP service. Connectors keeps an outbound connection open to AAD AP. When a request comes in, the app proxy queues up the request on one of these open connections for the connector to pick up)
   

   This request includes such items as the application, the headers of the request and data from the encrypted cookie such as the user making the request and a request id.  The encrypted authentication cookie is not sent to the connector.

3. The connector picks up the request from the queue, based on a long lived outbound connection and will do one of the following based on the request.
   1. The connector confirms it knows the application, if not, the connector will establish a connection to the AAD AP service to gather the details of the application and cache this locally.
   2. If the request is a simple operation where there is no data within the body such as a “get”, the connector will make a connection to the target internal resource and await the response.
   3. If the request has data associated with it in the body, for example a “post” operation, the connector will make an outbound connection using the client certificate to the AAD AP instance to request the data and open a connection to internal resource.  Upon receipt of the request from the connector, the AAD AP service begins accepting content from the user and forwards this on to the connector.  The connector, in turn, then forwards this data to the internal resource.
4. Once the request/transmission of all content to the backend is complete the connector waits for a response.
5. Once a response is received the connector then makes an outbound connection to the AAD AP service to return the header details and begins streaming the return data.
6. AAD AP then “streams” the data to the user.  (Some processing of the headers may occur here as needed and defined by the application).

We hope this level of detail helps your organization evaluate the Azure AD app proxy more efficiently and effectively. As always if you have any questions, comments or feedback, please feel free to reach us at aadapfeedback@microsoft.com

Girish Chander

Identity, Microsoft.

@chander_girish

Hey folks,

Am super excited today! The larger team here in Azure AD has been working hard on getting our artifacts into the new Azure portal. And today we just released a preview of that functionality.

Read more about it in Alex’s blog here. And you can try out the new portal experience here.

Within the Azure AD app proxy team, we’ve also been working to light up the App proxy functionality in the new portal. Today’s post is really a quick call out to try this functionality in the new portal.

Playing with the app proxy options in the new experience:

I recommend reading Alex’s post and seeing the videos included within to familiarize yourselves with the layout in the new portal first.

When you click on enterprise apps, you’ll see a node called ‘Application proxy’—this is where you can manage your connectors and connector groups and download the latest connector. <as shown below>

If you want to manage the properties of an app proxy application, you can click on the ‘All applications’ node, and select (or search) for the specific application. On the app specific blade, you will see various nodes on the left to manage the application and see the app specific activity. One of these nodes is the ‘Application proxy’ node that allows you to manage/edit the various app proxy specific properties of the application, as shown below.

Do note that we do not have the experience to create new applications in the new portal lit up yet. That will come as part of the next phase of the preview of the new experience. Stay tuned for that.

Go on, give it a try and let us know what you think! As always we look forward to your feedback at aadapfeedback@microsoft.com

Thanks,

Girish Chander

Identity Division, Microsoft

@chander_girish

Hey folks,

Absolutely thrilled today to talk about the partnership that we just announced this morning between Ping Identity and Microsoft. You can read all about it in our EMS blog here.

As Alex mentions in his blog post, the big motivation here is to enable customers to bring even more numbers of on-premises applications into the Azure AD control plane. A lot of you have told me that you have applications that use HTTP header based authentication. And that you would like to integrate these apps with Azure AD app proxy. And I also know that a lot of you have traditional WAM products like SiteMinder that you’re considering moving away from. With the partnership that we announced today, you can now offer your users a simple, secure remote access solution, to all these applications. This partnership just amplifies the value of the Azure AD app proxy.

This continues to solidify our goal to make any on-prem application accessible through Azure AD app proxy. And really helps bolster the productivity of your workforce by enabling them to access any on-prem app, from any place, on any device. And your IT teams can still maintain the necessary security controls through the power of the control plane in Azure AD.

We truly believe that with this partnership we’ve covered a broad swath of on-premises applications that most customers have. If you haven’t taken the next steps to explore and adopt app proxy, now is the time!

As always, if you have any questions or feedback, contact us as aadapfeedback@microsoft.com

Thanks,

Girish Chander

Identity, Microsoft

@chander_girish

Hello folks,

A lot of you ask us about the process we follow when updating connectors and releasing it to you. So, I figured I’d use today’s post to clarify what we do in this regard. I’d also like to cover the improvements we’ve made to make the process more stable and predictable for you.

As you know, we support automatic updates for any connector that you deploy and have had this capability for some time now. This was a key focus for us because we did not want you to have the burden of watching out for updates and keeping the connectors updated with the latest changes. With automatic updates, we offer you a simple way to keep up-to-date and get the advantage of all the feature, security and performance enhancements we make.

We’re constantly looking for ways to make our offering even better and we have made some improvements in this regard to better serve your needs. I’ll let Harshini, a Program Manager on the team, share more information about this new update process.

As always, if you have any feedback on this please send us a note at aadapfeedback@microsoft.com. We look forward to hearing from you.

Thanks,

Girish Chander.

@chander_girish

Hello everyone,

I’m Harshini Jayaram and I’m a Program Manager in the Azure Active Directory team, focusing on Application Proxy. We’ve recently released the next update for your connectors, and wanted to give some transparency into that process.

Connector Updater Service

When you installed your application proxy, you may have noticed that two services were added to your server – Microsoft AAD Application Proxy Connector (the core connector service), and Microsoft AAD Application Proxy Connector Updater (the updater service). As long as the second service is running, your connectors will update automatically with no downtime and no manual steps required.

If you don’t see the connector updater service on your server, you will need to reinstall your connector in order to get any updates. You can learn more about installing connectors in our setup documentation.

Update Rollout Process

Our updates happen using a gradual rollout process, intended to minimize any impact to you. Any rollout we make is first tested out in our test environments. Once successful there, we roll it out into our production environments. In our production environments, we first release it to our own test tenants to ensure there are no surprises. Again, the goal here is to prove out the stability of the update to ensure there is no downtime to your environment.

Next, we target customer tenants; starting with customers that have multiple connectors in their connector groups. In each of those groups, one connector is selected at random for an update. This way, in the unlikely event of a connector going down as a result of the update, there will be other connectors in the connector group that could take the load. This ensures that your users don’t see any impact to their application access.

Finally, we update the remaining connectors – those in connector groups with just one connector, and the remaining connectors in multiple-connector groups.

In each phase of the rollout we proceed gradually across our customer segment in that phase and ensuring that the rollout is successful, before proceeding. And we move between these phases only after the successful rollout of the preceding phase.

Update Impact

Tenants with One Connector: If you only have one connector, that connector will be updated as part of the last group. Because there is no other connector to reroute traffic through, the service will be down during the update. To avoid this downtime and more broadly ensure high availability, we recommend installing a second connector and creating a connector group. For details on how to do so, please see our documentation on connector groups.

Other Tenants: During the connector update, traffic will be rerouted to your other connectors for minimal disruption. However, any transactions in progress when the update starts may be dropped. Your browser should automatically retry the operation, making this potential drop transparent to you. Otherwise you may need to refresh your page to work around this.

We know it can be painful to have even the minute of downtime, but these updates allow us to give you an even better connector with numerous improvements that we think are worth it.

If you’d like more details on the changes in our recent Connector update, you can look at this page with the details on our latest update. We will update that page along with each update.

Hello Folks,

Sorry for the long gap between posts here, but we’re back and with tons of updates to share with you as we move forward. I’m Harshini and I’ll be taking over from Girish posting here. As mentioned in our last blog, I’m a Program Manager in the Azure Active Directory team, focusing on Application Proxy.

To kick it off, check out our integration with the Intune Managed Browser and the scenarios it enables. We know a lot of you using Application Proxy are also using Managed Browser, and this integration will make the story even easier for your end users. You can find the details in this Microsoft EMS Blog, or can follow the steps in our documentation to start trying it out today!

Thanks,

Harshini Jayaram

Program Manager II

Hello Folks,

One of the most popular Azure AD Application Proxy requests we get is for a link/URL translation  feature – and it’s now available for you!

Many applications that customers want to publish through Application Proxy have hardcoded internal links embedded in the HTML body of the application. When the app is remotely accessed through the Application Proxy, clicking on these links would fail. To address this issue and allow for even more apps to be published, we built this link translation feature. Link translation allows us to translate, or map, internal URLs in the HTML body of your applications to their corresponding Application Proxy external URLs, so users can access these applications remotely and they work as expected.

Learn more about this feature and how to configure it through our documentation.

We hope that you enjoy using link translation! As always, we’d love to hear your feedback on this feature so let us what you think in the comments.

Best,

Harshini Jayaram

Program Manager II

Hello Everyone,

To make application deployment easier and reduce your administrative overhead, we now support the ability to publish applications using wildcards!

To publish a wildcard application you can follow the standard application publishing flow, but use a wildcard in the internal and external URLs. To learn more, including how to create exceptions to a wildcard application, see the more detailed Azure EMS blog post and documentation. Also look out for another blog coming here in the next week that walks through an example wildcard application in more depth.

As always, we'd love to hear your feedback on this feature so let us what you think in the comments.

Best,

Harshini Jayaram

Program Manager II

Hello Everyone,

Many of you have been looking for a way to automate your Application Proxy deployments, and now you can with Powershell support! Using the new cmdlets will also help you build and maintain a standardized and predictable process for deploying Application Proxy applications in your environment.    

You can get the new module here. The commands in this new module include:

• Creating a new application
• Changing SSO settings for an application 
• Assigning certificates to applications to enable custom domains 
• Assigning a different Connector to an application 
• Getting all the Connectors in a specific group 
• Most other administrative controls for Azure AD Application Proxy 

You can also learn more in the documentation. We also have a blog about this release on the Azure EMS blog.

As always, we'd love to hear your feedback on this feature so let us what you think in the comments.

Best,

Harshini Jayaram

Program Manager II

Hi Everyone,

Earlier this month we announced support for wildcard (*) application publishing. In this blog, we’ll take a moment to go over this in more depth. As a reminder, you can use wildcards(*) to publish many applications at once. Wildcards also let you apply the same settings such as authentication method and user assignment for each of those applications. This capability reduces your administrative work, reduces opportunities for error, and helps make your users more efficient.

The documentation has two example scenarios. Below, we build on those to walk through two sample deployments which highlight two different ways to exclude specific applications from the publishing. Note that excluding applications may not be needed for your deployments.

Assume I have already added the custom domain adventure-works.com to my tenant. While custom domains are optional for other types of applications, they are required for wildcard applications.

Deployment 1: Block Wildcard Exceptions

Phase #1: General Wildcard Application Publishing

I have three different applications that I want to publish for all my users, and they are all configured for Integrated Windows Authentication.

• http://expenses.adventure-works.com
• http://hr.adventure-works.com
• http://travel.adventure-works.com

Because my three applications have the same properties (users, protocol, backend authentication), I can publish these using a wildcard.

First, I will create a CNAME entry in my DNS to point *.adventure-works.com to 000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net, where 000aa000-11b1-2ccc-d333-4444eee4444e is my tenantId. This ensures correct routing for my application. By using a wildcard DNS entry, I will be covering all the applications that match the wildcard application.

Next, I will create a new Application Proxy application in my tenant, following the same steps outlined in the documentation. Note the wildcards in the Internal URL, External URL, and Internal Application SPN fields.

By publishing this one wildcard application, my users can now access any of the three applications by going to the URLs they are familiar with (ex: travel.adventure-works.com). My application structure now looks like the following, where blue boxes are the applications explicitly published and visible in the Azure Portal, and gray applications are accessible through the parent application.

Phase #2: Creating an Exception

I’m very excited about this access for my users, but I have another application, finance.adventure-works.com, which should only be accessible by my Finance division. With the current application structure the finance application would be accessible through the wildcard application, and thus by all employees. To prevent this, I will publish Finance as a separate application with more restrictive permissions. This process is no different than publishing any other application.

I also need to make sure my DNS is pointing finance.adventure-works.com to the application specific endpoint. You can find the instructions at the bottom of the Application Proxy settings for the Finance application. In this case, I will be pointing finance.adventure-works.com to https://finance-awcycles.msappproxy.net/.

Now my application structure looks like the following:

Because finance.adventure-works.com is a more specific URL than *.adventure-works.com, it will take precedence. Thus only my finance department has access to this application, and it has successfully been excluded from the wildcard publishing.

Note: If I had multiple applications published for finance and also had finance.adventure-works.com as a verified domain, I could also publish another wildcard application *.finance.adventure-works.com. Because this is still more specific than the generic *.adventure-works.com, it will also still take precedence if a user accesses an application in the finance domain.

Deployment #2: Limiting applications covered by the wildcard application

Let’s assume I still want to publish my Expenses, Travel, and HR applications. However, I don’t want anyone to have access to the Finance application. I could still do this using Deployment #1, by assigning the Finance application to no users (instead of the finance department). Anyone trying to access the application through Application Proxy will then get a user unauthorized error. However, I could also do this in the following way:

Configure the wildcard application in the Azure Portal the same way as I did in Deployment #1, Phase #1. However, I will now create specific DNS entries for the applications I want to enable. I will need a CNAME entry pointing each of the following:

• https://expenses.adventure-works.com
• https://travel.adventure-works.com
• https://hr.adventure-works.com

to 000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net (where 000aa000-11b1-2ccc-d333-4444eee4444e is my tenantId).

For each wildcard application using this approach I will also need to create a CNAME entry mapping <ApplicationId>.domain to the same endpoint, 000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net. As a reminder, the ApplicationId can be found in the application properties page.

The DNS routing rules make sure that only the applications you’ve specifically listed with CNAME entries will be routed through Application Proxy, thus blocking/excluding all other applications even if they would have matched the wildcard pattern.

Please note that we recommend using the pattern in Deployment #1 if possible. This is easier to manage, and allows you to be more flexible with changes that may be needed for the excluded applications.

Are there any other scenarios you’d like to see more details on? Do you have any further questions? Please let us know by either leaving a comment here, or by emailing us at aadapfeedback@microsoft.com.

Regards,
Harshini Jayaram
Program Manager II

Hi All,

Last month we announced two features in public preview. I’m excited to share that both of those features, wildcard application publishing and Powershell cmdlets, are now Generally Available.

Many of you already joined us for the preview, but below is a reminder on how you can start using those features today.

App Proxy cmdlets in the GA Powershell Module

With Powershell, it’s easy to build and maintain a standardized process for deploying Application Proxy applications. To use the new Application Proxy cmdlets, you can download the GA module, or learn more. The cmdlets include:

• Creating an application
• Viewing all Connectors in a specific Connector Group
• Configuring SSO settings for an application
• Most other administrative controls for Azure AD Application Proxy

Wildcard Application Publishing in GA

Publishing many applications as one, by using a wildcard (*), reduces your administrative work, reduces opportunities for error, and helps make your users more efficient. This capability is now Generally Available.

Publish wildcard applications the same way you publish any other application. The only difference is that you should have a wildcard (*) in both the internal and external URLs. All applications in the scope of that wildcard can now be accessed by the assigned users.
To use wildcard publishing, sign into the Azure AD Admin Center or learn more in the documentation.

Let us know if you have any feedback or requests – comment here, post in the Application Proxy section of our feedback forum, or email aadapfeedback@microsoft.com.

Regards,
Harshini Jayaram
Program Manager II

Hi Folks,

Many of you have been asking for websocket support, and I'm excited to share that we now have limited support available in a public preview!

To join this public preview, there are just two steps:

1. Publish an application. There are no unique publishing requirements for websocket applications, so publish this application the same way as all your other Application Proxy apps.
2. Ensure you're using websocket-supported connectors. Check that your Connectors are version 1.5.612.0 or above, or download it here. Also make sure the websocket application uses a Connector Group that only includes these Connectors.

QlikSense was the most requested application, and is currently the only application supported in this public preview. We will expand support to other applications soon. We have also worked with the Qlik team to create this walkthrough to help you deploy the QlikSense + Application Proxy.

Please note - we had several private preview customers use this solution with other applications as well. While you're welcome to test out other applications, until we formally support them, we cannot guarantee they will work or offer complete support. If you do try this solution with a different application, we'd love to hear whether it worked or if you encounter any issues - let us know at aadapfeedback@microsoft.com .

Meanwhile, if you have any other applications you'd like us to support, let us know. For example, we know many people are testing Project Honolulu and Confluence with this solution, and are considering them for formal support.

Best,

Harshini Jayaram

Program Manager II

Hi Everyone,

Many of you are trying the websocket support we announced recently in Public Preview. As we look towards GA, we would love to get more of your feedback on how the preview is going and what apps you'd like to see us support next.

If you have tried the new websocket support, or if you would use it if our support was expanded to other applications, please take a few minutes to fill out our short 7 question survey:

https://aka.ms/appproxywebsocketsurvey

Thanks,

Harshini Jayaram

Program Manager II

CORS can sometimes present challenges to the Applications/Apis published via the Azure AD Application Proxy. There are many options to resolve these issues with ease, and in this blog we share those options as well as provide another look at understanding CORS.

What is CORS?

Cross Origin Resource Sharing (CORS) is a W3C standard that allows a server to relax the same-origin policy. Using CORS, a server can explicitly allow some cross-origin requests while rejecting others.

Browser security prevents a web page from making AJAX requests to another domain. This restriction is called the same-origin policy and prevents a malicious site from reading sensitive data from another site. However, sometimes you might want to let other sites call your web API.

What is Same Origin?

Two URLs have the same origin if they have identical schemes, hosts and ports. (RFC 6454)

These two URLs have the same origin:

• http://contoso.com/foo.html
• http://contoso.com/bar.html

These URLs have different origins than the previous two:

• http://consoto.net - Different domain
• http://contoso.com:9000/foo.html - Different port
• https://contoso.com/foo.html - Different scheme
• http://www.contoso.com/foo.html - Different subdomain

Consider the below example we have a "Webservice", which hosts a Web API controller, and the other called “WebClient”, which calls Webservice. There is an AJAX request from WebClient to WebService

CORS Challenges with Application Proxy

The App seems to work when hosted on premises but either fails to load or errors out when published via the Azure AD Application Proxy.

Both the applications were published as different applications through Application Proxy, so since the two applications are hosted at different domains, an AJAX request from WebClient to WebService is a cross-origin request and it fails.

Identifying CORS Issue

You can identify CORS issues by using the browser debug tools:

1. Launch the browser and browse to the Web App
2. Hit F12 to bring up the debug console
3. Try and reproduce the transaction and review the console

The console will give an error about the origin if you are seeing a CORS violation.

Note: In the below example the call is made when you hit the “Try It” Button, the expected response is a Test Message, instead you see an error.

Note: In the above example https://corwebclient-allmylab.msappproxy.net is missing from Access-Control-Allow-Origin header

Solution

Below are some possible solutions

Option 1: Custom Domains

Use the Custom Domain feature of the Azure AD Application Proxy, so you can use the same domain name and no changes to applications or headers are required. Thus the origin will continue to stay the same.

Option 2: Publish Parent Directory

Publish the parent directory of both applications. This works particularly well if you only have two applications on the web servers. Instead of publishing each application separately, you could publish the parent directory, that would result in the same origin.

App Published Individually

Instead publish the parent directory

The resulting URLs would be as below, effectively resolving your CORS issues.

https://corswebclient-allmylab.msappproxy.net/CORSWebService
https://corswebclient-allmylab.msappproxy.net/CORSWebClient

Option 3: Update HTTP Headers

Add the HTTP Response Header on the Web Service to match the Origin request. For example, below is how you could set it up for the websites running on the IIS.

This would also not require any change to the Code. You can also verify this in the Fiddler traces.

Post the Header Addition
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/plain; charset=utf-8
Expires: -1
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5 Microsoft-HTTPAPI/2.0
Access-Control-Allow-Origin: https://corswebclient-allmylab.msappproxy.net
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Content-Length: 17

Option 4: App Modification

Modify your application to add support for the CORS by adding the Access-Control-Allow-Origin header with appropriate values. The way to do this will depend on the language in which you wrote the application. This is the least recommended option since it requires more effort.

Best,

Jeevan Bisht

Program Manager - GTP

Hi Everyone,

We have a very exciting release today – the Access Panel extension for Application Proxy. This enables your users to access applications directly through internal URLs, even when outside your corporate network. The extension can now recognize requests to URLs that match the published internal URL for an application assigned to the user. It will then do a redirect to the corresponding external URL.

How to Use It

To use this feature, you need to have completed four steps:
1) Configured Application Proxy
2) Published an application using Application Proxy
3) Download the Access Panel extension (supported on Edge, Chrome, Firefox)
4) Log-in to the extension

To learn more or see an example, view our Azure EMS blog. To compare this solution to other options such as Custom Domains, Link Translation/Body URL Rewrites, and our Managed Browser partnership, keep an eye on our documentation. We'll be updating that page in the next few business days to provide a comparison.

As always, send us any questions/comments/feedback.

Best,
Harshini Jayaram
Program Manager II

Hi Everyone,

Throughout our documentation, we emphasize that we recommend using custom domains - bringing your own domain for the external URL rather than using the msappproxy.net domain we provide. To help make the value and configuration of custom domains clearer, below is a deep dive – starting with some FAQs and then moving into details on custom domains configurations for different scenarios.

FAQs

Why should I use custom domains?
We recommend using this solution so you can ensure your internal and external URLs are the same.

• Your users will have an easier experience. They don’t need to learn different internal and external URLs and track where they are – the same URL will work for them no matter where they are.
• The links contained in applications will work without additional configurations. If you have hard coded internal links within your applications, these may break when clicked if the internal link is not published within the Application Proxy application, and the link is not externally resolvable. When your URLs are the same, you avoid this problem. To learn more about options for this problem if you are not able to use custom domains, see the documentation on translating inline links.
• Some configurations will only work if you have custom domains. For example, you will need custom domains for applications that use SAML, such as when you’re using ADFS but are unable to use WS-Fed. See the documentation on claims-aware applications for more detail.
• Build user confidence. Seeing and using an “msappproxy.net” domain may be less familiar for your users – a custom domain can help build their confidence when accessing these applications.

If you are unable to make the internal and external URLs match, the recommendation is not as strong though there may still be benefits.

If I use custom domains, will my internal users be routed externally?
This is a configuration you can choose. You can use a split-brain DNS to ensure that internal users are never routed externally and stay within the network, while external users are directed through Application Proxy. See the deployment section for more information on configuring a split-brain DNS.

Why do you need a certificate?
We use the certificate to create the secure SSL connection for the domain you provided.

What types of certificates do you accept?
For complete details, please see our custom domains documentation. Please note that we only support PFX certificates to ensure that we also have any required intermediate certificates.

Can I use a wildcard certificate?
Yes, we are able to handle wildcard certificates. Those are explicitly required if you are using wildcard applications.

How do the certificates work with wildcard publishing?
When publishing a wildcard application, you must use a wildcard certificate with a subject name that matches the domain you are publishing externally.
If you'd like to use this application to also access subdomains, you should add these subdomain wildcards as subject alternative names in the same certificate.

Can I use one certificate with multiple applications?
Yes, you will be able to upload a certificate once for use with multiple applications. If an uploaded certificate works with another application, we will automatically apply it. You will not be prompted to upload it again.

Does my certificate also work for subdomains of the listed domain?
You need to make sure that subdomains are listed as subject alternative names in the same certificate. Otherwise a given certificate doesn’t work for subdomains. So, for example, a certificate for *.adventure-works.com will not work for *.apps.adventure-work.com.

Can I use a private root CA?
We strongly discourage you from using this. If you use a private root CA, it then also needs to be pushed to client machines. This can introduce a lot of additional challenges.

Deployment

We have documented the high level flow for using custom domains with Application already, but below is another look at these steps. While this information is current at the time the blog is published, please be sure to reference the documentation for the most up-to-date information.

Part #1: Adding a Verified Domain

First you need to add the desired domain as a verified domain in the Azure Portal. Below is a summary of the steps. For more information, please see the adding custom domains documentation.

1. In the Azure Portal, navigate to Azure Active Directory -> Custom domain names and select the “Add custom domain” button.
2. Enter the domain name and click “Add Domain”
3. You will be prompted to create a new TXT record in your domain registrar with specific information.
4. Once you make this change, you can come back to this page and click “Verify”. That will update the status of the domain to “Verified” and you will now be able to use this domain when applicable in across your Azure AD configurations, including for Application Proxy.

Part #2: Create the Application Proxy application, and add the certificate

Next you need to apply your custom domain when publishing an application. The steps below start at publishing a new application. However, you can also change the domain of an application after publishing. In that case, navigate to the application through the Enterprise Applications menu, select the “Application Proxy” menu, and go to step #2.

1. When you publish an application that uses custom domains, follow the standard add application flow. Navigate to Azure Active Directory -> Enterprise applications, select “New application” and then “On-premises application”.
2. To use a custom domain, ensure that you chose your verified domain while defining the external URL.
3. You will see an information bubble telling you what DNS entry you need to configure on your external DNS to make sure that your external traffic to the custom domain is getting directed to the Application Proxy endpoint. DNS configurations are handled in more depth in part #3.
   
4. Click Add (or save if modifying an existing application).
5. If you have uploaded a certificate to Application Proxy that matches the external URL, you are done with this section. Otherwise, navigate to the "Application Proxy" menu for the application you just created. Click on the certificate upload prompt at the bottom of the screen.
   
6. Upload the certificate, enter the certificate key, and click Upload Certificate.
   
7. Save the application, and your custom domain is now set up. Be sure to assign users to your application before testing or releasing it.

Part #3A: Setting Your DNS entries – Same Internal/External URL, Different Internal and External Behavior

If you would like to make sure your internal users are not directed through the Application Proxy, you will need to set up a split brain DNS.
A Split DNS infrastructure is used to direct internal hosts to an internal domain name server for name resolution and external hosts to an external domain name server for name resolution.

Part #3B: Setting Your DNS Entries – Same Internal/External URL, Same Internal and External Behavior

Both the internal and external DNS CNAME entries point to the msapproxy.net URL.

One common case for this scenario is if you wanted to apply conditional access to the web application/websites irrespective of the location of the devices - for example a trusted device is only allowed access from a Azure AD Registered/Join Device.

Part #3C: Setting Your DNS Entries – Different Internal/External URL

When your internal and external URLs are different, you don’t need to configure the split brain behavior since the user routing is determined by the URL they hit. In this case, you will only be changing the external DNS, routing the external URL to the Application Proxy endpoint.
In part 2, after selecting your custom domain from the external URL, you will see a pop-up that shows the CNAME entry you need to add to the external DNS. You can always see these instructions again by navigating to the application in Enterprise Applications, and clicking on the Application Proxy menu.

Is there anything else you'd like to know about custom domains? Let us know in the comments!

Best,

Harshini Jayaram

Program Manager II

Hi Everyone,

Until now, only Global Admins were able to configure and change Azure AD Application Proxy settings and features. This week we announced the new "Application Admin" role in public preview. This is a delegated role that includes permissions for Application Proxy settings and configurations.

Test it out and let us know what you think! Learn more in our EMS Blog Announcement.

Best,

Harshini Jayaram

Program Manager II