SharePoint 2013 Multiple App Domain with Host Named Site Collections Issue

SO, the other day I ran into a problem at a customer:

Summary

My client has setup an environment where they can only utilize sub domains of their primary domain.

For example: command.com

Hence different sites would be sub domains such as:

• release.command.com
• forward.command.com

To save time, maintenance and resources these two web applications are in one central farm. Previously they were in separate farms to secure content from each other.

The client has also utilized HNSC (host named site collections) in order to be cloud ready. During the configuration of app domains for the organization to start building and deploying SharePoint hosted add-ins, the client ran into an issue.

The issue is as follows:

When utilizing HNSC and configuring SharePoint for multiple app domains. The settings for the following app domains are ignored.

• release.command.com
• forward.command.com

A global (via the UI) was setup such as: apps.command.com, and all redirects when utilizing a SharePoint hosted add-in goes to this location.

Problem with this are twofold:

• URL changes to guid.apps.command.com
• No web site exists at that URL, hence 404.

The problem does not exist when not utilizing HNSC, though this would remove the organization from being cloud ready.

This is a discovered issue unique to the configuration the client has, as there are required security boundaries that need to be in place between SharePoint Web Applications. Even if the above configuration is made to work, it means the site hosting the app domain has to have security rights to both web applications. This is a breach in the security design the client needs to maintain between web applications and content.

Solution Design

Summary

This solution to the issue at hand is to utilize an often used module provided by Microsoft called URL Rewrite. It also involves a careful use of extended sites and IP addresses.

This solution will outline the elements required and the configuration of the solution.

Note: there is no code for this solution, this is all configurations.

DNS Settings

First step is configuring the DNS, this is a bit different than most documentation. The standard configuration calls for a totally separate domain which isn't possible for the command or desired.

Note: these would be load balanced IP's by a load balancer. Each web front end in the farm would require this configuration be applied.

The following Table illustrates the configuration of the DNS for this solution:

The separate apps domain off the root domain is strictly for redirects and will be discussed later.

As illustrated in the above table, there are four addresses; this is because of the need for SSL certificates that are blank.

Note: in Windows Server 2016, the issue of not being able to have "Require Server name Indication" checked for blank host name bindings is resolved. Hence the requirement of multiple IP addresses is null.

Certificates

The following is a list of certificates required for the solution:

The solution requires the use of wild card certificates; this is not a requirement of this solution but of SharePoint Hosted Add-ins by Microsoft.

Web Applications

This solution has the following configuration:

Web Applications:

• Release Home
• Forward Home

Each of the above is extended via Central admin

• Release Apps
• Forward Apps

Note: the reason to extend the sites is because of the blank bindings for the *.apps.[site].command.com calls. Hence all such calls will go to the extended site and be covered under that certificate. If extended sites are not used then invalid certificates will be indicated for most sites.

Each site has the following site collection, though what is described is not a limit, just a short list.

• [site].command.com
• [site].command.com
• [site].command.com(location of app catalog)

Note: set the app catalog for each web app pointing to the respective HNSC.

Note: also set the app domain URL to:  apps.command.com

IIS Bindings

The following are bindings for each website:

Note: all are 443, blanks do not have "Require Server name Indication" checked.

Note: due to another issue within the redirect.aspx that builds the URL, all ports have to be 443, this is a SharePoint issue and cannot be changed until a fix is implemented.

Redirect Site

A site needs to be created in IIS, it can point to an empty folder, and nothing needs to be set.

Make sure the URL rewrite module is installed, download it if needed: https://www.iis.net/downloads/microsoft/url-rewrite

The model would show up when you click on the web site in IIS:

Two rules need to be created to support the solution discussed.

NOTE: this solution could be applied to more than one SharePoint web application, although only 2 are discussed here.

Double click URL Rewrite:

Click Add Rule(s)

Select Blank Rule from the inbound rules section.

Now you must define the actual rewrite rule. In the URL Rewrite Module, a rewrite rule is defined by specifying four required pieces of information:

• Name of the rule.
• Pattern to use for matching the URL string.
• Set of conditions.
• Action to perform if a pattern is matched and whether all conditions checks succeed.

Rule 1:

Name: Release Apps Redirect

Match URL section

Requested URL: Matches the Pattern

Using Regular Expressions

Pattern: ^(.*)$

Note: the string that comes in as an input is normally "sites/siteofinterest/pages/page1.aspx". Hence nothing to identify it as the URL you want, so here we simply say give us anything that is a string.

Conditions Section:

Logical Grouping: Match All

Action Section

Action Type: Redirect

Action Properties:  https://{C:1}.apps.release.command.com{PATH_INFO}?{QUERY_STRING}

Uncheck Include query

Rule 2:

Name: Froward Apps Redirect

Match URL section

Requested URL: Matches the Pattern

Using Regular Expressions

Pattern: ^(.*)$

Note: the string that comes in as an input is normally "sites/siteofinterest/pages/page1.aspx". Hence nothing to identify it as the URL you want, so here we simply say give us anything that is a string.

Conditions Section:

Logical Grouping: Match All

Action Section

Action Type: Redirect

Action Properties:  https://{C:1}.apps.forward.command.com{PATH_INFO}?{QUERY_STRING}

Uncheck Include query

Review

At this point, all the rest of the development process for building SharePoint Hosted Add-ins is the same. Deploying SharePoint Hosted Add-ins is the same, this is strictly an infrastructure solution and changes nothing of how users implement or use applications.

One aspect that is not mentioned in this document thus far is authentication; this assumes both the main and extended sites utilize the same authentication methods. If federation is used then the extended sites will also need to utilize the same provider.

References

The following are references for this solution: