So by now you should have had chance to play with (maybe not) the Web Application Firewall that comes with Server 2012 R2. To install it you simply need to access server manager and choose to add a new role and feature option.

Once we get to the selection screen we need to choose “Remote Access“.

At the feature screen we don’t need to select anything else, we can move on to configure the “Remote Access” role. Make sure you select the “Web Application Proxy” option only for this.

This will then prompt to install all the dependency options, accept those.

Let the installation complete.

Once it has completed installing, we need to run the configuration wizard from the management console.

The wizard is really simple to use, first off you need to associate it to an ADFS environment. Lucky for me I have one, if not I would need to build one. In wizard we need to type the URL we use to get to the ADFS server, no protocols needed just the server so something like “adfs.domain.com“, also add the local administrator credentials (or an account that is set to be one).

Next we are asked for the certificate hat ADFS is using. This means that this needs to reside on the server already in order for us to use it. One you have selected it, “PowerShell” is then run that will automate the installation.

Once it is completed you should get the amazing message like this.

This will then load the management console so you can then actually configure it for what you need.

For us to “Publish” something we need to choose the “Publish” option which starts the wizard off. A main feature of publishing is to determine if we wish to “Pre-Authenticate” before being able to access the published resource. We have the ability to simply “Pass-Through” with none or push to ADFS for the Authentication step.

I am going to choose “Pass-Through” first so we can see what this looks like. I am prompted to complete the following details.

For this example I am going to simply publish an empty website. My settings are as follows.

Notice the message saying that the Internal and External URL match. This is due to URL translation not being enabled by default. To resolve this you need to run some PowerShell. We will run this after we have created the publishing rule, as we need the application ID so we can enable URL translation.

Once it has completed we get one of those fantastic messages again.

So now let’s sort out the URL translation. Open the PowerShell window and then run the following command.

This will list us the current applications we have published along with the Unique ID that we need.

We now take this ID and use this in the following piece of PowerShell code.

Set-WebApplicationProxyApplication –ID <application_ID> -DisableTranslateUrlInRequestHeaders:$false

 

Once this is run we are then able to access the site using the new URL over SSL, which when we try on the server doesn’t work as the site is not configured for SSL using the original address.

HTTP

HTTPS

If we now use the new “Publish” address our site loads using SSL as we configured, with no “Pre-Authentication“.

So what happens if we now configure it for “Pre-Authentication”?

Well first we have to have added this site as a “Relying Party” in ADFS first. The only difference with this configuration is that we need to choose the relying party in the “Publish” wizard.

After selecting this, the configuration is set like this.

Notice the error from before, we will need to run the same PowerShell as before to fix this, once it has created it, now we can test and see if the site loads. Of course the site you are connecting to needs to be claims aware so ADFS can “Pre-Authenticate” correctly. My sample site that I am using for this simply returns back the claims I passed to the site.

In the next post we will focus on the end to end for SharePoint 2013 and a few other things for fun 🙂