SharePoint Alternate Access Mappings, Host-named Site Collections and SSL

SharePoint has been around for a while now, so we should all be good and knowing how to create web applications, site collections and sites. In reality we should also be good at defining the URLs that are needed, along with any mappings, and configure the use of an SSL Certificate. However, having spent time looking at SharePoint environments for some time, it seems that knowing how to setup “Alternate Access Mappings” and what you would really them for is more common than I thought. Also the mystical Host-name Site collection seems to also be a problem, along with setting up an SSL certificate for the site.

So let’s begin by understanding “Alternate Access Mappings”. First off, navigate to this site to learn about them: https://technet.microsoft.com/en-us/library/cc261814.aspx, as it is a great explanation of what they are for.

The Microsoft definition for an Alternate Access Mapping is “Alternate access mappings enable a web application that receives a request for an internal URL in one of the five zones to return pages that contain links to the public URL for the zone. You can associate a web application by using a collection of mappings between internal and public URLs. Internal refers to the URL of a web request as it is received by SharePoint 2013. Public refers to the URL by which SharePoint will format links that correspond to requests that match one of the internal URLs on that zone when it returns a response. The public URL is the base URL that SharePoint 2013 uses in the pages that it returns. If the internal URL was changed by a reverse proxy device, it can differ from the public URL.”

Doesn’t that make so much sense?

Just kidding, however reading it often does not make any sense at all.  So let’s break it down a little more.  SharePoint Web Applications can reside in a zone. A zone for all intense a purposes is really a container for the URL and Authentication process that is needed for your site. A Web Application can actually have multiple zones that can contain not only different URLs but also different Authentication, though you do not have to have it that way. The following flow shows a SharePoint site with a public URL of https://portal.sharepoint.com and then an internal URL of http://portal.sharepoint.com. 

Now what is the difference between the public and internal URL?

The public URL is the one that everyone will access the site on, could be specific types of people such as a true external user or a regular network user. The internal URL in this case is used to ensure that HTTP is translated by SharePoint to HTTPS. Setting a URL as Public with an Internal will ensure that a redirect is performed.

Now a SharePoint site can also have many URL’s based on what is required, some of these can be assigned to the same zone, others can be assigned to separate notes based on what is needed. As an example if we had a site http://www.sharepoint.com and it needed to be changed to the https://www.sharepoint.com and then ensure that http://portal.sharepoint.com is also redirected to the same site then we would create the following in SharePoint.

We could scale this even further if we had other URLs. Let’s say we wanted to have an internal only accessible URL such as http://admin.sharepoint.com, as well allow http://intranet.sharepoint.com to work and to be redirected to https://intranet.sharepoint.com, as well as allowing for NTLM on the “Admin” URL and “Forms Based Login” using the “Intranet” URL we would create the following.

Setting the right Alternate Access Mappings can ensure that SharePoint works from each URL with the correct Authentication. Setting them incorrectly can actually make SharePoint look like it is breaking, as it is confused with the URL access. Too many times URLs get added because of backwards compatibility, but they are just added as new URLs in new Zones instead of really planning out what is needed.  For example, they might be added like this.

Though this works, this just means that the Web Application will respond to each URL as independent URLs, and are not related to each other. In the scenario where the core URL should be http://one.sharepoint.com, the other URLs could be mapped differently.

This approach would allow SharePoint to handle the redirect to the new URL yet support the other URLs as access point it the site.

Now when it comes to using SSL certificates, SharePoint can handle the redirect internally by setting the public URL to the SSL one, and then set the HTTP ones as internal to the public URL zone. SSL certificates needs to be assigned within Internet Information Services (IIS) as well as Alternate Access Mappings defined for the site. Without these two even though IIS will respond to the request, SharePoint will complain that it is responding in the wrong URL. The logical architecture is based around one to one mappings from IIS to SharePoint, along with SSL certificates and Alternate Access Mappings.

The only exception to this rule is when host-header site collections are used. This changes the design somewhat purely based on how SharePoint recognizes the host-headers for the site collections.

Image from: https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/01/45/88/metablogapi/2110.image_755E24DF.png

To learn much more about how they work, you can read this post https://blogs.msdn.microsoft.com/kaevans/2012/03/27/what-every-sharepoint-admin-needs-to-know-about-host-named-site-collections/.

All in all, getting an understanding of how URLs work, how SSL is to be applied along with Host-named site collections can make or break the end user experience.

Some great resources can be found here: