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.