SharePoint 2013 introduced the concept of Host named site collections (HNSC). Actually, that isn't strictly correct, HNSC were also available in SharePoint 2010 but for various reasons, not widely adopted. In its broadest, description HNSC give
the appearance of multiple web applications (allowing the creation of third
level domains like https://hr.myorg.com, https://sales.myorg.com, etc).
This post does not seek to describe in detail the role and configuration of HNSC in SharePoint 2013. Indeed, there are a number of very good blog posts already published which I will include for reference at the end of this post. What this post seeks to highlight is a particular SharePoint bug which I have been unfortunate to fall victim to and hopefully help anyone else who may have faced or be facing the same issue.
Microsoft are pressing very hard to encourage implementer's to make use of HNSC wherever possible and this is absolutely the right way to go, however there may still be a need to create multiple/additional web applications when different
authentication providers or zones are required. In almost all
other cases, the best and recommended practice is to use HNSC and a single web application (3).
When architecting my SharePoint 2013 farm I was keen to embrace the Microsoft recommendations, where possible. It was decided that we would use ADFS as our default authentication provider. Now, when using ADFS the suggested approach is to enable, under Claims Authentication Types, both the ADFS and the Windows authentication providers.
This has the side effect that when a user tries to authenticate, an Authenticate.aspx page (in the SharePoint layouts folder) is presented, asking to select the desired authentication method. This can be solved with a simple HTTP module which checks the user agent of the incoming request. Alternatively, the discussion (4) mentions the possibility of creating a redirect rule inserted on the F5 load balancer. Unfortunately, as these options were not available to me and the authenticate.aspx page was rejected my options were somewhat limited. There is a way to bypass the the multi authentication provider selection page (6) which suggests replacing the login page, however this approach is not supported and does not allow patching/upgrading of SharePoint.
In the end, I decided on creating and extending a web application, setting the default zone to use windows credentials (NTLM, Kerberos) as authentication provider and the Intranet (extended) zone to use ADFS (SAML) as authentication provider thereby negating the need for HTTP modules, F5 load balancer redirects or forcing users to have to select an authentication method via the authenticate.aspx page and still leverage the use of HNSC.
Using ADFS (SAML) as your authentication provider results in some significant changes to People Picker (8) behaviour which need to be addressed (9). I addressed these using the LDAP/AD Claims provider or LDAPCP (10) hosted on CodePlex.
Prior to implementing LDAPCP a people picker query would result in both Default (NTLM authN) and Intranet (ADFS authN) profiles being returned in the results. My assumption having implemented LDAPCP was that when users executed a people picker query in the Intranet zone only ADFS authN profiles would be returned as the NTLM authN was not selected for that particular zone as authentication provider.
This unfortunately proved not to be the case. Further testing proved that the anticipated behaviour resulted in Path Based Site Collections (PBSC) but not in HNSC. Armed with my findings I raised a support case with Microsoft and was put in touch with Microsoft Premier Field Engineer Yvan Duhamel, the author of LDAPCP. Yvan was able to reproduce the issue and confirmed that I was facing a bug with HNSC and extended web applications when using ADFS authN as exclusive authentication provider. Yvan offered a workaround, which I had in fact already implemented (11) and that he would need to go back to product group to ascertain whether a permanent solution would be made available.
Root Cause:
Essentially when a people picker query is executed what happens is a call is made to SPWebApplication.Lookup() to get the SPWebApplication object based on the Url of the current HNSC site. The SPWebApplication.Lookup() method is also responsible to set an out parameter of type SPAlternateUrl which returns the Url and the zone with which it is associated. In our scenario the code sets this out parameter SPAlternateUrl to null.
Because it is null, the SPClaimProviderManager.GetClaimProvider() method causes code to call the SPClaimProviderManager.GetClaimProvider() for each zone of the web application instead of only the current zone (that doesn't contain the AD claims provider) and as a result people picker returned the identities for both authentication providers.
I am happy to be able to say that I have had communication from Yvan recently and Microsoft will look to provide a fix in the April 2015 cumulative update (CU).
References:
