Part 2​ - Securely publishing SharePoint externally using Web Application Proxy ​(WAP)

Part 1 of this series gave you an overview of the new capabilities of the Web Application Proxy (WAP) feature in Windows Server 2012 R2, and how it can be utilized by your SharePoint 2013 environments to securely publish your sites externally. In this post we will take a look at the end-to-end configuration process of WAP using pre-authentication for Windows claims-based SharePoint web applications.

The steps discussed in more detail below are as follows:

1. Configure SharePoint Web Applications to use Kerberos authentication
2. Install and Configure WAP and AD FS
3. Create a non-claims aware relying party trust
4. Configure constrained delegation
5. Publish SharePoint Web Applications in WAP
6. Verify external access to SharePoint Web Applications

Step 1: Configure SharePoint Web Applications to use Kerberos authentication

As mentioned in Part 1, taking advantage of pre-authentication in WAP will require that your SharePoint web applications are configured using Windows claims-based Kerberos authentication or SAML based claims. Therefore it is worth re-iterating that the first step is to ensure you are using Kerberos authentication for all SharePoint web applications that you want to expose to the outside world via WAP. Configuring SharePoint to use Kerberos is straightforward and relatively well documented now.

To summarize the steps detailed in the link above, you'll need to firstly edit the authentication provider for a chosen zone of the web application you want to expose externally (e.g. Default zone if this is the zone that you will be publishing externally) and select Negotiate (Kerberos) as the authentication method, as per the screenshot below.

You will then need to create the appropriate Service Principal Names (SPNs) within your domain for the service account running the application pool that hosts the web application you will be exposing externally. In my case my service account is HASSANIONPREM\shassani and the web application I'll be exposing through WAP is https://team.hassanionprem.com. Therefore the two SPNs that I need to create are HTTP/team and HTTP/team.hassanionprem.com. You can see that these have been added via ADSIEdit as per the screenshot below.

Step 2: Install and Configure WAP and AD FS

Once you have the SharePoint pre-requisites configured, you can go ahead and install AD FS and WAP. As mentioned in Part 1, installing WAP requires Windows Server 2012 R2 and AD FS also running on Windows Server 2012 R2.

Installing WAP and AD FS on servers is pretty much as straightforward as adding roles and features on servers with a small amount of configuration following this. Steve Peschka does a great job of explaining this process, so I won't repeat this here, but advise you follow the link above for his detailed guidance.

One key point to remember is to ensure you have the certificate available that you will be using to secure your AD FS service URL, as well as the certificate you use with your SharePoint web application (of course all of your SharePoint web applications should be secured over SSL). These certificates may well be the same certificate, but either way you'll need to make sure you have these available as part of the configuration process.

Another point to bear in mind which often causes a little bit of confusion is that as you are configuring the WAP service once you have installed and configured AD FS, during the WAP configuration wizard, when you are prompted to enter the Federation Service Name the wizard expects the name in a format such as adfs.hassanionprem.com, rather than https://adfs.hassanionprem.com. The wizard does not validate what you enter at this stage, and you'll receive some rather unhelpful error message at the final stage of configuration should you not enter this correctly. The screenshot below illustrates how not to enter the service name and shows how no validation is carried out by the wizard.

One final point to mention is that WAP acts as a proxy to AD FS. With Windows Server 2012 R2, the AD FS proxy role has been removed, WAP incorporates this functionality and is effectively configured for you as part of the WAP configuration process when you enter your Federation service details (as shown above). Therefore all external DNS entries should route to the WAP server's external interface, there is no need for AD FS server(s) to be available directly externally.

Step 3: Create a non-claims aware relying party trust

Now that your AD FS and WAP servers have been built, the next step involves configuring AD FS so that in can handle the authentication of external users against your SharePoint web applications. This is achieved by creating a non-claims aware relying party trust. One should not be confused by the term "non-claims" here. This is simply referring to SAML based-claims rather than the Claims mode of our SharePoint web applications. This trust can be established in AD FS via the following steps:

1. Within the AD FS Management console click Add Non-Claims-Aware Relying Party Trust on the left hand side of the screen.
2. Click Start on the first page and then enter a name such as "Non-claims provider for SharePoint".
3. In the Add Non-Claims-Aware Relying Party Trust Wizard, on the Welcome page, click Start.
4. On the next page click next and when prompted to enter a relying party trust identifier, enter any URL (it really doesn't matter what this, but useful to be something you recognize).
5. Click Next, Next, Next and finish, and when the Edit Claim Rules window appears, click Add rules.
6. On the Edit Claim Rules click Add Rule, and from the drop down select Permit All Users and then click Next and then Finish.

We will return to this later on to show how this trust is actually used by WAP.

Step 4: Configure constrained delegation

The next step to allow AD FS and WAP to handle the authentication of external users against your SharePoint web applications is to configure constrained delegation for your WAP server. Remember, we've already configured SPNs for your SharePoint web applications, which are the services that we need to allow the WAP server to delegate to.

1. From a domain controller open Active Directory users and computers, and open the properties window for your WAP server(s).
2. Select the delegation tab and choose the 3rd radio button - Trust this computer for delegation to specified services only, and then click Use any authentication protocol.
3. Click Add, find the service account running the Application pool hosting your SharePoint web application, then select the correct SPNs, in my case HTTP/team.hassanionprem.com. Selecting this will also add HTTP/team, as illustrated in the screenshot below (note that the Expanded check box is selected). 

Step 5: Publish SharePoint application in WAP

The final step of configuration is to go ahead and publish the SharePoint application in WAP.

1. Within the WAP configuration tool click Publish in the Tasks pane.
2. Click Next on the first page and then select AD FS on the pre-authentication page. Remember, we set out at the start with the goal of using WAP and AD FS to pre-authenticate our user requests.
3. On the Relying Party page, select the Non-claims aware relying party that you created.
4. On the next page Publishing Settings, do the following, and then click Next:
   • In the Name box, enter a name for the published SharePoint Web Application (the same name you use in SharePoint could be a good idea here!)
   • In the External URL box, enter the external URL for the SharePoint web application; in my case I'm using the same URL externally and internally i.e. https://team.hassanionprem.com
   • In the External certificate list select the certificate which we mentioned earlier is used by SharePoint (should your internal and external URLs be the same) that covers the external URL
   • In the Backend server URL box enter the URL on which SharePoint will be listening for the request. Note, if this differs to your External URL you'll need to ensure you have your Alternate Access Mappings (AAMs) configured correctly in SharePoint
   • In the Backend server SPN box, enter the SPN that you previously configured delegation for, in my case HTTP/team.hassanionprem.com 
5. On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.
6. On the Results page make sure that application published successfully and then click Close.

Step 6: Verify external access to SharePoint Web Applications

One thing you can now do is revert back to your AD FS server. Open the properties window of the non-claims aware relying trust that you created, and selecting the Proxy Endpoints tab will show that this is used by WAP for external URLs that you've published, as per the screenshot below.

Now you're good to go! From a machine off of your internal network, hit the URL of the web application that you published externally, in my case https://team.hassanionprem.com and if all has been configured correctly, you should first be presented with the default AD FS sign in page. Enter your credentials, and once AD FS has authenticated you, you'll be redirected to your root SharePoint site collection within the web application.

If you have any questions or feedback about this guidance, please feel free to email me via the button below. Good luck!