Last week I faced a challenge publishing non-claims-aware application (SharePoint 2013) using Kerberos Constrained Delegation (KCD) by Web Application Proxy (WAP).
The customer environment consists of a multi-forest active directory where user accounts and server objects each stored in a separate forest. Due to the introduction of Microsoft Enterprise Mobility Suite (EMS) we added a public User Principal Name (UPN) which was required to log on using a public domain namespace.
After publishing the web application and succesfully being authenticated I received a HTTP 500 Internal Server Error. In the eventlog of the Web Application Server the Kerberos token request is forwarded through a domain controller in forest A. This token request is based on a User-ID in a child domain of forest B.
But for some reason no Kerberos ticket can be retrieved by my WAP server on behalf of the user .
After a while I decided to involve my colleague and identity specialist Mark Scholman to force a breakthrough. After walking through some basic steps (name resolving, trusts, service principal names (SPN)) we decided to reproduce the customer set up in order to exclude matters.
At a certain moment we dediced to create a testuser in both forest A and B in order to verify and validate access. What struck us was that we could successfully login with both accounts. This gave us to think. After some clicking around in the properties of Domains and Trusts I ran into the tab Name Suffix Routing and saw that routing for the custom UPN suffix we added previously was disabled.
After enabling routing suffix for our custom UPN suffix we renewed our attempt to access the web site, this time with success!
First of all keep your forest/domain as flat and simple as possible. This avoids complexity and additional configurations such as Alternate Logon ID and Kerberos Domain Routing. Make sure when adding one or multiple UPN suffixes in a multi-forest Active Directory to set up and configure Kerberos Domain Routing when using Kerberos Constrained Delegation.
Part of the project objective of implementing Enterprise Mobility Suite (EMS) we had to publish intranet web applications in a secure and controlled manner. Using Microsoft Intune, these intranet web applications made available as web application to managed (mobile) devices. These applications must be published through Web Application Proxy (WAP) with minimum impact to the according application(s). As Azure Application Proxy Services was no option (user objects must resides in the same forest as where you installed the Azure Application Proxy Connector is installed) we fallback to Web Application Proxy (WAP) with Active Directory Federation Services (ADFS) pre-authentication. The relevant intranet web application (SharePoint 2013) is claims aware but requires additional configuration at both SharePoint and ADFS sides (Authentication Provider,ADFS Identity Provider, Trusted Identity Token Provider). To prevent additional (complex) customizations at both sides we rather prefer using Kerberos Constrained Delegation (KCD) with Web Application Proxy (WAP).
In this blog I’ll not cover the configuration of publishing claims-aware/non-claims-aware applications through Web Application Proxy (WAP) server. Some great resources are available which describes this configuration in details. See brightstarr.com and kloud.com.au. In order to be able to use Kerberos Constrained Delegation (KCD) your Web Application Proxy (WAP) must be domain-joined.