[#SP2013] Host named site collections, ADFS claims and AAM

In my previous blog post I wrote about host named site collections in SharePoint 2013. As this is the recommended way to go according to Microsoft, you should definitely consider it for new SharePoint deployments. But with these URL’s bound to your site collections, you can get into trouble quickly. It’s important to get a good grasp of the matter before implementing it in a production environment. Today I’ll discuss setting up host named site collections, claims based authentication and alternate access mappings.

The requirements

Let’s first see what we’re going to set up here. For this scenario, I’m using a farm which is living outside of the domain where our users live. A common scenario would be a (privately) hosted farm at some service provider, as we do often at Atos. To provide our users with single sign-on, we implement ADFS which allows users to log in using their corporate credentials.

Using host named site collecitons, we’re going to host several site collections with their own URL’s. We’d like our users to browse to those sites, get an authentication prompt from ADFS and then log in, without giving them any further options.

And of course, we should secure this environment using SSL certificates.

 

Things you need to know

Zones and authentication: The authentication options for a web application are set on the zone level. The zones in SharePoint are Default, Intranet, Internet, Custom and Extranet. Every zone has it’s own list of authentication providers, which means we can use different providers per zone. Normally we would have Integrated Windows authentication enabled, in combination with NTLM or Kerberos. When we now add our Trusted Identity Provider, users will have to choose which method of authentication they want to use. We do not want to give our users that choice, since they’d probably make the wrong choice and start calling the servicedesk, right?

Authentication and search: another important thing to know is that search requires you to have an endpoint which is configured using Windows authentication (NTLM or Kerberos). When you do not select Windows authentication for your web application, SharePoint will notify you of this:

If Windows authentication is not selected on any Zone of this Web application, crawling for this Web application will be disabled.

The thing it doesn’t mention though, is that you need Windows Authentication enabled on the Default zone. Technically it is not unsupported to use a different zone, but practically you will run into much more trouble if you should choose that road. And yes, that also applies when you instruct search to crawl that different zone which has Windows authentication configured, it really needs to be on the default zone. For more information about this subject, check out this excellent blog post by Brian Spender: http://blogs.msdn.com/b/sharepoint_strategery/archive/2014/07/08/problems-when-crawling-the-non-default-zone-explained.aspx

Zones and ports: there are some best practices in the community around setting up zones and authentication. One is to secure everything you set up with SSL, which is never a bad idea. The second is not to use port 80, for obvious security reasons. So basically, we shouldn’t use port 80 and we should make sure any other port is either secure, or not published to the outside world. Nothing new, but good to refresh this knowledge.

 

Webapp architecture

When we now combine everything mentioned above; we get the following guidelines:

• We need a single web application hosting all our host named site collections.
• The default zone should be secured with Windows Authentication, running on a non-default port and optionally secured via SSL.
• We have to extend that webapp to a SSL secured endpoint which will be available to the outside world. The most logical port to use would be 443, unless you do some kind of port mapping on your load balancer.

Note that there is one best practice we can’t possibly fulfill now: the default zone will not be used for our end-users. When you read some articles on how to set up your environment, they will say that this is best practice. It might be, but it’s not feasible combined with the above statements which – in my opinion – are more important.

This translates into the following setup:

• Default zone, port 9735 (any random port), windows authentication / NTLM or Kerberos
• Internet zone, port 443, SSL secured, ADFS authentication

A little Powershell script helps to set this up:

Some work to be done afterwards:

• Configure your SSL certificates in IIS
• Check if search is crawling http://server:11978 and verify it all works in the search log. Remember; there needs to be a root site collection present at that URL.

 

The gotcha’s… 1) Zones

When we now create a new host named site collection using the New-SPSite command, the URL we specify is bound to the default zone. But our users are not accessing the environment via the default zone.

I was mistakenly assuming that SharePoint would understand I would like my site collections to be hosted on port 443 in an SSL secured version, but this is not the case!

When using host named site collections, the URL of the site collection is linked to a zone! And when nothing is specified, the default URL is used.

What does that mean? We should make sure each site collection is mapped correctly to both of the zones we have created. That’s the only way both our users and our search crawler / service apps won’t run into any problems. That means it needs two URLs:

• Default: http://portal.contoso.com:11978
• Internet: https://portal.contoso.com

Normally, we would use Alternate Access Mappings (AAM) to add URL’s to different zones. With host named site collections we can do the same, but need to use the Set-SPSiteUrl Powershell cmdlet instead of Central Administration.

It’s also good to know that you need a root site collection for every URL you’re going to host, and SharePoint uses the alternate access mappings for any site hosted on a managed path. So for instance, when we create http://www.contoso.com and add an alternate access mapping for the Internet zone on https://www.contoso.com, then https://www.contoso.com/sites/team would also benefit from that same mapping.

Update: Waldek Mastykarz wrote an article about issues with restoring or copying site collections using multiple SPSiteUrls. Check that one out here: http://blog.mastykarz.nl/inconvenient-copying-host-named-site-collections-multiple-spsiteurls/?utm_source=mavention&utm_medium=preview&utm_campaign=Mavention%20Blog

 

2) SSL

When you have these sites running on SSL (and you should), you need to add the proper certificate(s) to the corresponding binding in IIS. Normally, you’d have one certificate per URL and each certificate is bound to one IP address. Some exceptions:

• When using wildcard certificates, you can configure *.contoso.com and be able to run portal.contoso.com, teams.contoso.com, projects.contoso.com, etc.
• Using Subject Alternative Name (SAN) certificates, a single certificate can hold multiple domain names it secures.
• When using Server Name Indication (SNI), it becomes possible to configure multiple certificates on a single IP address. This reduces the need for additional addresses, but be aware there are compatibility issues with older browsers; in Windows XP for instance.

 

3) AD FS and realms

When you now have it all working, you’re probably still running a single domain (like in this example: portal.contoso.com). But when you introduce a new (sub)domain, you’ll notice something weird: when logging in via AD FS, you are now being redirected to your original domain again. Huh?

Well, if you did the configuration of AD FS yourself, you’ll remember the URL and realm you had to configure. AD FS uses this information for 1) determining which relying party it’s dealing with and 2) where to return the end user after logging in. SharePoint sends a single realm and there is only one relying party in AD FS, so you’re alway returned to the /_trust URL you first configured. When we want our end users to be returned to the correct URL, we have to make AD FS aware of that by configuring a new relying party. This process is the same as for your primary URL, so I’ll won’t go into it. As identifier, enter the new URL you are configuring like https://teams.contoso.com.

In SharePoint, we need to add the new realm so that SharePoint sends the correct one, we can use Powershell to do so:

I would advise to make it a habit to configure this for every URL, so also do the same for the one you already had although that is the default realm. When viewing the ProviderRealms property, it should now return something like:

You do not have to use the URL as realm, you can use other strings as well as long as they map to an identifier present in AD FS.

 

4) Apps

If you know about SharePoint apps, you know that every app gets its own generated app URL. Something like https://app-12345.contosoapps.com. Combine that knowledge with item 3) and you’ll understand that actually making use of AD FS in your app, requires a different realm / trusted identifier because each app has a different URL. There is a good blog post on this by the SharePoint Escalation Serviices Team (of whom I did not know they exist), so please read that one here: http://blogs.msdn.com/b/spses/archive/2014/01/17/how-to-use-adfs-with-sharepoint-hosted-apps-in-sharepoint-2013.aspx.

 

Concluding

Putting this all together, you can safely conclude this allows for a lot of options, but is a tricky thing to get everything working right when you don’t know the theory behind it all.

• Having 5 zones means every site collection can run on 5 different URL’s, and each one can have a different port, SSL enabled / disabled, etc.
• Each zone can use it’s own list of authentication providers. Using the trusted identity providers, you can configure numerous ways of authentication (althought that might make it hard for the user to pick the right one).
• One web application for host named sites can now host a considerate amount of URL’s.
• The default zone is important for search and other services, and should have Windows Authentication enabled.

The above is based on my experience. As always, there are probably more ways to acheive the same. But this solution – in my opinion – makes sense and is most stable. Should you have any alternatives, feel free to comment!