A new toy I’ve played around with recently is this new web-application proxy (WAP) role in Windows Server 2012 R2. I thought I’d write a quick post about setting up SharePoint 2013 with it because reverse proxying SharePoint applications is a good practise for publicly accessible SharePoint sites, and it’s good to share.
Web Application Proxy is basically a simplified TMG Server; it’s without a lot of the functionality TMG Server has but on the plus side it gives a real quick way of setting up a reverse-proxy for a web application like SharePoint. There’s no firewall functionality as before outside of what comes with Windows Server by default; the beauty of this role is its simplicity.
Edit: check out version 2 of this blog-post here – http://blogs.msdn.com/b/sambetts/archive/2015/07/01/sharepoint-server-and-web-application-proxy-continued.aspx
Web Application Proxy has two modes of authentication for authenticating against whatever web-app you’re publishing; pass-through and ADFS. The principal is the same though; it’ll act as a safety buffer between your internal SharePoint systems and the outside world as no traffic will reach SharePoint unless it’s been authenticated 1st.
SharePoint admins can sleep happily that no baddies are going to be able grind it into grounds with DOS attacks, internally at least.
Test Setup & Configuration
A picture paints a thousand words, so here’s what we’ve got:
The proxy is going to use the internal intranet HTTP zone (Kerberos enabled) with the already nicely-working service-principal name “HTTP/sp15” (or “HTTP/sp15.sp15.sfb-testnet.local” for the FQDN).
The point of all of this is that if our SharePoint site were to suffer a fatal attack of some kind; a denial-of-service attack for example, the only thing that would be impacted here is the DMZ. SharePoint would not even know somebody was trying to hammer it – happy days(ish)!
As hinted at already, SharePoint needs to be setup in a specific way – the application which you’re internally routing to needs to be configured for Kerberos (negotiate) and be working that way already.
Web Application Proxy Setup
Server Role Setup
You’ll need to have an ADFS server first & foremost for any application that might need ADFS. Using ADFS is optional but the role needs one available at least so you’ll be asked for this during the initial configuration.
You’ll need to import an appropriate certificate with private-keys; it needs to be a FQDN and have a matching subject name as your ADFS certificate, so you need a wildcard certificate for ADFS & your public-access URL.
Next add the name of the ADFS server used to authenticate users if needed.
Next step is to specify the SSL certificate that we’re going to use for the external address. Here I’m using a wildcard certificate so it works for the ADFS server too.
After that we’re pretty much done for initial configuration. PowerShell equivalent of the wizard is offered too at the end.
AD Delegation Permissions
As the proxy is basically pretending to be the logged in user, it needs permissions to do so for the SharePoint application.
Find the computer object in Active Directory & enable constrained delegation for the SharePoint application-pool account.
Without this delegation setup you’ll get an error logged on the proxy:
Web Application Proxy encountered an unexpected error while processing the request.
Error: No credentials are available in the security package
It’s basically a message saying “I didn’t get sent any credentials” (because the sender didn’t have permissions to impersonate whoever logged in).
Also if your proxy is in another AD site as SharePoint (normal, considering the proxy is supposed to be in a DMZ) then these changes will have to replicate in order to work.
Create ADFS Relying Trust
Next we need a relying trust in ADFS for the web-application-proxy to authenticate with before passing requests to SharePoint.
Add a “non-claims aware replying party trust” in your ADFS server. We’re going for non-claims aware because the end-point (SharePoint) is just using raw Windows authentication. For the identifier just use the URL of your app – it doesn’t really matter; non-claims aware trusts are pretty simple really.
Publish SharePoint Web Application
One the role is setup we need to publish a SharePoint application. Click “publish” to start the wizard. Just like before, this is possible with PowerShell but also via the GUI too (which again will give you the PowerShell equivalent way of executing your actions done in the GUI too in case you’re interested). Click “publish” in the GUI to start the wizard.
For SharePoint we want to use the ADFS option so only authenticated requests arrive to SharePoint.
You’ll need to specify which pre-configured relying party trust we’re interested in for the ADFS.
Here’s where we specify what the URLs will be for internal & external access.
Once done, that’s pretty much it!
Testing the Published Application
Open the proxy URL from an external client and see what happens.
When the user goes to https://sfb-proxy.sfb-testnet.local/ in my example, we get redirected to ADFS (but via the proxy – authentication fails if the client can access ADFS directly).
Once logged in we get sent back to the original proxy address (although as mentioned, both ADFS and the proxy address need to route through the proxy).
SharePoint is none the wiser that the user came from outside. Everything is translated nicely; http://sp15 is host-header enforced so this operation just wouldn’t work if it wasn’t converted correctly. No need to even add an alternative access mapping. Make sure you set both publicly & internal URLs correctly in SharePoint. See more here – http://blogs.msdn.com/b/sambetts/archive/2015/07/01/sharepoint-server-and-web-application-proxy-continued.aspx