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.
How about accessing our internal SharePoint site from an iPad!
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.
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.
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.
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.
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.
Make sure to set the port to 443 and set “Use Secure Sockets Layer” to Yes.
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.
Now open up the SharePoint 2013 Management Shell on the SharePoint server and create a host-named site collection.
- $w = Get-SPWebApplication https://spdev
- 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.
Click Create Domain Certificate.
For the common name, I used *.corp.blueskyabove.us (notice the asterisk).
On the next page, select the certificate authority and provide the friendly name.
Once you click Finish, you will see the new certificate.
Go to IIS Manager, select the new IIS site that was created, and choose Bindings.
Select the binding and choose Edit.
Select the domain certificate.
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.
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
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.
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”.
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).
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.
Now open a PowerShell window and type “"klist” to see the list of Kerberos tickets. You should see the SPN you registered.
Look in the Security log on the SharePoint server, you should see events with ID 4624 in the event log indicating logon using Kerberos.
Publish the Application in Azure AD
In your Azure AD tenant, go to the Applications tab and choose “Add” to add a new application.
On the next screen, choose “Publish an application that will be accessible from outside your network”.
Give the name of your application, the internal URL, and set the pre-authentication method as “Azure Active Directory”.
Once the application is created, you will see 3 steps that need to be completed. Enable the Application Proxy in the directory.
Next, download the Application Proxy connector and install it. In my environment, this is the “ADSync” server.
The installer prompts to log into Azure AD.
When complete, you will see “Setup Successful”.
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.
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
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.
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.
Click the Portal application. In my environment, I get this:
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.
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:
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.
Click the “Default” link, then change the IIS Authentication Settings to Negotiate.
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.
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!)
And the SharePoint portal accessed from the app.
For the O365 users, you will be glad to see that the app experience is integrated.
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