Publishing SharePoint with Windows Server 2012 R2 Web Application Proxy

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 - https://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 1^st.

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)!

SharePoint Prerequisites

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

(0x8009030e).

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; https://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 - https://blogs.msdn.com/b/sambetts/archive/2015/07/01/sharepoint-server-and-web-application-proxy-continued.aspx

 

That’s it!

Cheers,

Sam Betts

Comments

• Anonymous
  June 14, 2015
  Can we publish a subsite only using WAP?

• Anonymous
  June 24, 2015
  Hey "Can we publish a subsite only using WAP" :) I'm afraid not; there's no filtering options based on URL in WAP as far as I know. In TMG on the other hand... // Sam

• Anonymous
  November 11, 2015
  I have done this in our environment but here is my scenario and I just need to know if this is expected behavior Logging in externally:

• Browse to the SP URL

• WAP server authentication page comes up

• Login successfully

• Open Office document (word, excel), i get the same WAP server login prompt again I would have thought that there would be some token or cookie passed so that i wouldnt have to authenticate again?

  • Anonymous
    August 11, 2016
    We have the same issue concerning additional authentication with office apps.We are using the same external and internal URL .WAP Server ist NOT domain integrated, so Sharepoint is configured for ADFS authentication.Anyone has solved this issue?

• Anonymous
  January 13, 2016
  Hi Shaun, Are your internal & external URLs the same? If they're different it can be very tricky to get right. Also bear in mind WinINET on the client will or will-not share cookies between processes depending on the zone of the URL. It should work if it's all setup right. // Sam

• Anonymous
  May 19, 2016
  The comment has been removed