Kirk Evans Blog

.NET From a Markup Perspective

Azure AD Application Proxy and SharePoint 2013

This post will show how to configure Azure Active Directory Application Proxy for an on-premises SharePoint 2013 installation using Kerberos constrained delegation.

Background

I see this question in emails and online forums alike almost weekly: “We need users to access our on-premises SharePoint farm from their mobile phones.” This usually involves an in-depth conversation about reverse proxies and ADFS.  When a developer hears “at least 2 more servers”, they kind of freak out and say, “well that’s just not worth it, I’ll find another way.” 

The Azure Active Directory team made this RIDICULOUSLY easy, and avoids the infrastructure burden of adding new servers and opening firewall ports to accommodate.  The Azure Active Directory Application Proxy is a software reverse proxy that enables routing of on-premises resources from a cloud entry point.  It enables the ability to pre-authenticate calls to the server, and unlocks the power of Azure AD to enable things like dynamic groups, conditional access, and multi-factor authentication over existing on-premises assets. 

Newly introduced for Azure Active Directory is the ability to use Windows Integrated Authentication to authenticate to on-premises systems.  In order for this to work, systems must use Kerberos constrained delegation.  As my friend Miguel Wood demonstrated at SharePoint Saturday Houston this weekend, this enables you to use an iPad to access an on-premises server without multiple authentication prompts!  The remainder of this post shows how to set up the environment to enable this scenario. 

Just to prove it, here is what you will be able to do with Azure AD Application Proxy… here is my on-premises SharePoint farm accessed remotely from an Android emulator.

image

How about accessing our internal SharePoint site from an iPad!

image

Prerequisites

The steps in this post require an Azure Active Directory Premium subscription.  I simply activated the Azure AD Premium Trial on my tenant.

I assume your on-premises users that will access SharePoint using Azure AD Application Proxy have the same UPN as the users in the cloud.  This means if my on-premises user in Active Directory is “demouser@blueskyabove.us”, the user is listed in Azure AD as “demouser@blueskyabove.us” as well.

image

image

I did this in my lab by using the Azure AD Connect tool (currently in Preview) to synchronize my on-premises AD to Azure AD.  These configuration steps are outside the scope of this post.

The user that will access the on-premises SharePoint server (I am going to use demouser3@blueskyabove.us) needs to be assigned a license for Azure Active Directory Basic or Premium.  If you have an O365 directory or a free directory, you can enable the AAD Premium trial, then go to the Licenses tab for your directory to assign the user.  The application will fail if the user does not have a Basic or Premium license.

image

Lab Setup

I have 4 virtual machines in my lab environment, all in the same domain.

  • JavaDC – Domain controller using Active Directory Domain Services.  Also serves as enterprise DNS.
  • ADSync – Windows Server 2012 R2 machine that runs the Azure AD Application Proxy Connector.
  • DevSP – Windows Server 2012 R2 machine where SharePoint 2013 is installed.
  • DevSQL – Windows Server 2012 R2 running SQL Server 2014.

In Azure AD, I have a user “demouser3@blueskyabove.us” that I will use for testing, and this user is also in my on-premises AD as well.  We will register the “Portal” application.  Users of that application make a secure request on-premises without requiring a reverse proxy or ADFS. 

image

Add a DNS Entry

Add an A record in DNS for your web application’s URL.  It cannot be a CNAME, it needs to be an A record.

image

Create a Web Application and Site Collection

In Central Administration, create a new web application with no host header on port 443 using SSL, and using Negotiate authentication.  This web application currently is behind the firewall and is not routable outside the network. 

image

Make sure to set the port to 443 and set “Use Secure Sockets Layer” to Yes.

image

Change the application pool to a domain account.  My lab environment uses an account “corp\sp_app”.  This step is important because this is the account I will when configuring Kerberos constrained delegation.

image

Now open up the SharePoint 2013 Management Shell on the SharePoint server and create a host-named site collection.

Host Named Site Collection
  1. $w = Get-SPWebApplication https://spdev
  2. New-SPSite -Url https://portal.corp.blueskyabove.us -OwnerAlias "corp\sp_setup" -HostHeaderWebApplication $w -Name "Portal" -Template "STS#0"

Add a Wildcard SSL Certificate

Now that we’ve created the web application, we need to assign an SSL certificate to the web site binding in IIS. In my previous post, Adding Active Directory Certificate Services to a Lab Environment, I showed how to add Azure Active Directory Certificate Services to your lab environment.  We will now simply request a Domain Certificate.

Go to IIS Manager, select the server node, and select Server Certificates.

image

Click Create Domain Certificate.

image

For the common name, I used *.corp.blueskyabove.us (notice the asterisk). 

image

On  the next page, select the certificate authority and provide the friendly name. 

image

Once you click Finish, you will see the new certificate.

image

Go to IIS Manager, select the new IIS site that was created, and choose Bindings

image

Select the binding and choose Edit.

image

Select the domain certificate. 

image

For more information on using Active Directory Certificate Services, visit my previous blog entry at Adding Active Directory Certificate Services to a Lab Environment.

Grant Permissions

Make sure to grant permission to the test users.  I simply allowed “Everyone” as visitors.

image

 

Set up Kerberos Stuff

When I created the web application, I used “CORP\sp_app” as the application pool account.  Add a service principal name (SPN) to the account for “http/portal” and “http/portal.corp.blueskyabove.us”.  The easiest way to do this is to open a PowerShell window on the domain controller and use the command:

setspn –S http/portal sp_app

setspn –S http/portal.corp.blueskyabove.us sp_app

image

You can see that I used setspn –L sp_app to list the SPNs registered for the account.

Go to Active Directory Users and Computers.  Find the computer name where the Azure Active Directory Application Proxy Connector will be installed.  Right-click that computer and choose Properties.

image

Click the Add button and enter the user name for the application pool account (sp_app).  That will let you choose the SPN that we just registered.  Click OK, then check the Expanded option to show all the SPNs to see that the computer is now trusted to delegate to those services.  Change the option to “Trust the computer to delegate to specified services only” to constrain the delegation.  Change the option to “Use any authentication protocol”.

image

This enables the Application Proxy Connector to impersonate users in AD to the applications that are listed.

Test Kerberos Stuff

Before we go any further, let’s make sure the basic plumbing works.  From the machine that will run the Application Proxy Connector, verify that you can open a browser and access https://portal.corp.blueskyabove.us site.  Add the site to the Local Intranet zone in IE so that it will automatically pass credentials (avoiding the auth challenge prompt).

image

Now browse to the site, and you should see the site with a valid SSL certificate.  We’re still within our corporate network at this point, we’ll enable the remote access in just a bit.

image

Now open a PowerShell window and type “"klist” to see the list of Kerberos tickets.  You should see the SPN you registered.

image

Look in the Security log on the SharePoint server, you should see events with ID 4624 in the event log indicating logon using Kerberos.

image

 

Publish the Application in Azure AD

In your Azure AD tenant, go to the Applications tab and choose “Add” to add a new application.

image

On the next screen, choose “Publish an application that will be accessible from outside your network”. 

image

Give the name of your application, the internal URL, and set the pre-authentication method as “Azure Active Directory”.

image

Once the application is created, you will see 3 steps that need to be completed.  Enable the Application Proxy in the directory.

image

Next, download the Application Proxy connector and install it.  In my environment, this is the “ADSync” server. 

image

The installer prompts to log into Azure AD.

image

When complete, you will see “Setup Successful”.

image

After the connector is installed, look in the event log (Applications and Services Log / Microsoft / AadApplicationProxy / Connector / Admin) to see that the service started successfully.

image

Go back to the Azure Management Portal and go to your new application’s Configure tab.  Change the Internal Authentication Method to “Integrated Windows Authentication”.  Change the Internal Application SPN to the FQDN SPN for your application, which was http/portal.corp.blueskyabove.us

image

Make sure to click Save to save your changes.

Go to the Users and Groups tab and assign the users.  Note that you could use groups as well.

image

Test It Out

Open the MyApps portal, http://myapps.microsoft.com, and log in as the user that was assigned the application.  You will see the applications assigned for the user.

image

Click the Portal application.  In my environment, I get this:

image

You can see the page render, just briefly, before the redirect.  I decided to turn off the Minimal Download Strategy feature for the site.  In the SharePoint site, go to Site Settings / Site Features and disable the Minimal Download Strategy feature.

image

When speaking with Miguel Wood about this, he said he didn’t have to do this in his environment.  If you get this error, then try disabling MDS and try again:

image

Success!  We were able to access our internal SharePoint farm from the internet without opening any firewall ports or adding infrastructure. 

Do Epic Stuff

Maybe that wasn’t quite easy enough.  What if you wanted to enable access to Central Administration remotely so you didn’t have to VPN into your network?  Maybe you want to temporarily provide remote access to Central Administration so that someone can configure your farm remotely without giving them network credentials?  The Azure AD Application Proxy is a very cool solution.

In SharePoint Central Administration, go to Manage Web Applications and click the Central Administration web application.  Click the Authentication Providers button in the ribbon.

image

Click the “Default” link, then change the IIS Authentication Settings to Negotiate.

image

Now add a SPN for Central Administration, add delegation permission from the machine where the connector is installed to the SPN, and register it on the portal.  You now have remote access to Central Administration.

image

It’s not just SharePoint that this would work for… this works for any internal system.  Perhaps you have an application that you want to enable on users’ phones: this works as well, just as I showed in the screenshot of the Android emulator previously.  There is also a MyApps launcher available for iOS that makes it easy to access apps from your iPhone and iPad without installing a browser extension.  Here is a screen shot of the application (thanks to Todd Baginski for grabbing these for me!)

image

And the SharePoint portal accessed from the app.

image

For the O365 users, you will be glad to see that the app experience is integrated.

image

image

I will be showing this and much more of Azure AD at the SharePoint Evolution Conference 2014, April 20-22nd in London, UK.  If you are attending, please make sure to come to the session to learn more about the capabilities of Azure AD.

For More Information

Azure Active Directory Connect Public Preview – March 2015 update

MyApps SSO Launcher for iOS