This post is an update to the original architectural guidance I published previously at http://blogs.technet.com/b/speschka/archive/2013/10/11/architecture-design-recommendation-for-sharepoint-2013-hybrid-search-features.aspx.  If you read that post then you’ll recall that we had a “scenario problem” with hybrid search when SharePoint 2013 released.  The problem, which I explain more fully in that post, is that there wasn’t a good way to publish both an endpoint for hybrid search as well as users outside of your firewall to access a SharePoint farm.

IMPORTANT:  The features described in this post require that you install the April 2014 CU or later for SharePoint 2013.  That introduced one breaking change that you will also need to fix for everything to work.  Please see this post for details and the fix:  http://blogs.technet.com/b/speschka/archive/2014/08/28/you-start-getting-a-401-unauthorized-error-when-using-the-sharepoint-hybrid-features-after-applying-april-2014-cu-or-later.aspx.

The good news is that the team has been able to add some new functionality to the hybrid features such that we can now support this scenario.  In short what needs to be done is:

• Create a new AAM mapping for a SharePoint zone
• Configure DNS for your AAM mappings
• Publish the AAM mappings through your reverse proxy
• Modify your farm configuration to have the hybrid features use the AAM lookup for inbound queries instead of basing it on the Public Url

Here’s a few more details on these steps.  To help illustrate, let’s assume you have a SharePoint zone with a Url of https://portal.contoso.com and it is reachable on your corporate network at IP address 10.1.1.1.  You have a reverse proxy in your DMZ and it is configured to listen for incoming requests on IP address 175.10.10.10.  Now let’s see how this scenario would be implemented.

Create a New AAM Mapping for a SharePoint Zone

When https://portal.contoso.com was created it was added to the default zone.   We’re going to add another incoming Url for the zone that will be used for hybrid search, so I’ll call it https://hybrid.contoso.com.  Now in terms of how you add the incoming Url I’ll just say that there are a few ways of doing it, and a lot of documentation out there for how to do it.  For my purposes I created my web application with this in mind, so I used hybrid.contoso.com as the Host Header value and https://portal.contoso.com as the Public Url.  After the web app was created I had to a) go add an incoming Url for the zone of https://hybrid.contoso.com and b) add another HTTPS binding in IIS on my web application so that it listens for portal.contoso.com.  Since I used hybrid.contoso.com as the Host Header value when I created the web application, that HTTPS binding was already created in IIS.  I used the SNI feature in IIS so I could set both host header values and still use SSL.

Configure DNS for Your AAM Mappings

Configuring DNS for users to access the Public Url of the zone can be done in one of two ways:

• Single DNS – everyone uses the same IP address for the Public Url.  That means that even users in your corporate network will be sent outside to the proxy server and their request will then get routed back into your network to access SharePoint.  Naturally all users accessing the Public Url from outside of your corporate network would also go through the proxy server.  So in this case you end up with a single DNS A record of 175.10.10.10 for the hostname “portal.contoso.com”.
• Split DNS – in this scenario the DNS used for users on your corporate network resolves “portal.contoso.com” to the internal IP address for the Public Url.  The external DNS resolves “portal.contoso.com” to the reverse proxy server.  So in this case your internal DNS has an A record of 10.1.1.1. for “portal.contoso.com”, and your external DNS has an A record of 175.10.10.10 for “portal.contoso.com”.

Configuring DNS for the incoming Url for the SharePoint zone is much easier; you’re just going to create one A record in your external DNS for “hybrid.contoso.com” and it will use the IP address of the reverse proxy server, which is 175.10.10.10.

Publish the AAM Mappings through Your Reverse Proxy

The exact details of how you publish endpoints in a reverse proxy are going to vary by the proxy product being used.  For an example of how to use WAP in Windows Server 2012 R2 you can see one of my prior posts here:  https://blogs.technet.com/b/speschka/archive/2013/12/23/configuring-windows-server-2012-r2-web-application-proxy-for-sharepoint-2013-hybrid-features.aspx.  At a high level though there’s really just a couple of concepts you need to know when you publish the endpoints:

1. You’re going to publish one endpoint for the Public Url of https://portal.contoso.com.  That endpoint does not require any pre-authentication (although you can do that if you choose to); the request can just be redirected to the internal IP address for the site which is 10.1.1.1.  This is the endpoint that users will reach when they are outside the corporate network and trying to access the farm.  If you only use a single DNS then internal users will also get routed here.
2. You’re going to publish one endpoint for the incoming Url of https://hybrid.contoso.com.  This published endpoint needs to require client certificate authentication, and it should use the certificate that you configure your Result Source in o365 to use for hybrid search.  The request should retain the original host header and also forward it onto the internal IP address for the site of 10.1.1.1.

The goal here is to have two unique hostnames for the same SharePoint content.  By using the AAM feature, when the request comes in for hybrid.contoso.com, any search results that it returns will be rendered using the Public URL for the zone, which is portal.contoso.com.  When a user clicks on a search result then they will be sent to whatever IP address resolves for portal.contoso.com and they will be able to access the SharePoint content using their credentials, without having to provide a client certificate like hybrid search does.  In your Office 365 tenant that also means that when you create the Result Source for the on premises farm, you need to configure the Url to be https://hybrid.contoso.com so that it gets routed to the correct published application on the reverse proxy server.

Modify Your Farm Configuration to use AAM for Hybrid Search

This is the last and most important step, which was provided by the April 2014 CU.  A new property was added to both the SPSecurityTokenServiceConfig as well as SPWebApplication.  The property is called UseIncomingUriToValidateAudience and is set to False by default.  In order to get the hybrid features to use the AAM lookup as we’ve configured above you need to set it to true.  To make this change farm wide, use the SPSecurityTokenServiceConfig object; to set it on just one web application use the SPWebApplication.  Here’s an example of the PowerShell needed to set it at the farm level:

$cfg = Get-SPSecurityTokenServiceConfig

$cfg.UseIncomingUriToValidateAudience = $true

$cfg.Update()

Once you’ve completed all of these steps you should be able to have Office 365 issue inbound queries to your on premises farms and get search results back that are rendered using the Public Url of your SharePoint zone.  This request will be securely authenticated using the client certificate you configure the Office 365 Result Source to use.  You will also be able to have users outside your corporate network access the SharePoint zone using their corporate credentials, and they will not be required to present a client certificate to get to the SharePoint farm.  This is a really nice improvement in the hybrid features so I hope you find it useful.  For more details on the new property that was added please see this article on TechNet:  http://technet.microsoft.com/en-us/library/dn751515(v=office.15).aspx.