SharePoint + Web Application Proxy - 2016 Edition

[アーティクル]
04/04/2017

I’ve done a couple of articles already on Web Application Proxy (WAP) with SharePoint, and figured it was time to update the series now Windows Server 2016 has improved on it. Here’s how to set-up SharePoint 2016 with Windows Server Web Application Proxy 2016, up, high-level.

First, a quick recap; why use WAP on-top of SharePoint & ADFS? Because it gives you a way of exposing your public SharePoint applications to the internet without anyone having any line-of-sight. This is important because it means nobody could overwhelm your SharePoint infrastructure without being authenticated first.

The idea is WAP sits in a DMZ, can be completely unconnected to any domain even, and just forward requests to SharePoint once a valid ADFS token has been gotten.

This is very nice as we can isolate our precious production servers from any direct contact from outside.

Also, WAP gives us extra authentication options for ADFS Server – we can insist on different security policies depending if the user has come from externally or internally.

How does ADFS know if a user is external or internal? Simple – a user request either came via the proxy or it didn’t.

New Things in 2016

So what’s new then? On the SharePoint side, not much as far as ADFS/WAP is concerned.

In WAP though we can now do things like:

Use single wildcard certificate for publishing applications. Much easier for things like SharePoint-hosted apps which have unique domain-names per app.
Redirect to HTTP back-ends (HTTPS no longer required).
Some other stuff.

All in all, quite a worthy upgrade for Windows Server Web Application Proxy.

Network Requirements

The network setup is key to the whole thing working.

As our Web Application Proxy will be the contact point for all traffic both to SharePoint & ADFS, it needs to have the same SSL certificates & IP associations as internal SharePoint addresses do. Behold, figure 1:

WAP needs to be the external contact-point for everything needed internally; SharePoint & ADFS too.

It’s true though that SharePoint doesn’t necessarily need the same DNS names internally & externally, but I’d highly recommend it for simplicity sake – alternative access mappings are a pain. Some network guys like to have visibly different internal & external URLs, but frankly it only causes headaches for SharePoint URLs – things that work inside the network magically don’t work outside, etc.

Keep URLs the same please! Seriously…

SharePoint Security Configuration

For my tests, I’ve taken an internal ADFS-secured SharePoint web-application & simply published it externally. It is possible to have WAP convert ADFS tokens into internal Kerberos tokens for standard Windows-authenticated SharePoint web-apps instead, but I simply can’t be bothered with protocol transitioning. Why? Because ADFS is simply a better security solution that Windows auth directly on SharePoint web-applications, and ADFS can authenticate with Windows auth anyway.

ADFS published websites are the way to go; forget native Windows authentication for SharePoint web-apps – you’ll be doing yourself a favour in the long-run, IMO.

Why Use ADFS Instead of Windows Auth for SharePoint?

ADFS give you a lot more control over identities. First, you can set what the “ID” (identifying claim) of each user will be; account-name, email address, whatever you want.

Second is that, with the claims sent to each application (SharePoint in this case) we can manipulate them before sending them to the client-app (SharePoint) if we want too. This can make things like domain-mergers much easier; users from a newly absorbed domain can appear to SharePoint like users in another domain for example.

Third, is the extra security you have for authentication. Multi-factor-authentication is possible for users based on certain policies, etc.

Oh, and single-sign-on for Office 365/Azure AAD can use it.

In the end, SharePoint isn’t designed to handle authentication & identity policies; ADFS is and does it very well. SharePoint & ADFS complement each other very nicely.

Use it!

Publishing a SharePoint Web-App

So first up then let’s make sure the network is working – ping/nslookup from inside & outside the network and verify the IP addresses are correct for each address, in all networks (internal, DMZ if you have one, and outside on the internet).

Then get your certificates installed on your WAP 2016 machine(s). Obviously WAP needs line-of-sight to your ADFS instance too. Do not continue until you have this infrastructure verified.

Now install the Web Application Proxy role. Configure the ADFS server being used.

Finally publish your SharePoint application in WAP like so.