Remote SharePoint Index, Hybrid, and SAML

  • Article

Today's post combines a few different topics, that dare I say, started as a dare (I think). The gauntlet thrown out was whether or not Remote SharePoint Index would work for SAML users as well as Windows users. For those of you not completely familiar with Remote SharePoint Index, I covered it in some detail in my blog post here: https://blogs.technet.com/b/speschka/archive/2012/07/23/setting-up-an-oauth-trust-between-farms-in-sharepoint-2013.aspx. The gist of it is that you set up an OAuth trust between two SharePoint farms, and it lets you get search results from both farms into a single search center results page. All of our examples in this area have been around using Windows users, but when the question was posed my best guess was "yeah, seems like that should work". As it turns out, it's true, it really does. In order to get this to work it requires the following:

  • Two SharePoint farms
  • Both farms have an SPTrustedIdentityTokenIssuer configured (ideally using the same Name, but in theory should not be required. In theory.)
  • Both farms have at least one web app configured to use the SPTrustedIdentityTokenIssuer
  • Both farms have UPA configured and running
  • Both farms are doing a profile import from the same Active Directory forest.
  • Both farms have the profile import Authentication Provider Type configured to be Trusted Claims Provider Authentication and Authentication Provider Instance configured to be their SPTrustedSecurityToken Issuer. When you're done it should look like this:

 

After you've set all of that up, you also need to into Manage User Properties in the UPA and map both the Claim User Identifier and (usually) the Work email properties. In my case I used email address as the identity claim, so I mapped both of those properties to the "mail" attribute in Active Directory. If you are using a different identity claim then you would map the Claim User Identifier accordingly and would not need to map Work email. By default, the Claim User Identifier is mapped to samAccountName, so you'll want to Remove that mapping, then add one for mail. There's nothing to helpful about doing this, you literally just type in "mail" in the Attribute field and then click the Add button. When you're done it will look like this:

.

You'll probably want to do a full import after that (unless you have a really huge directory). The biggest gotcha here is that you can really only set up one profile connection per Active Directory domain (at least when using Active Directory import instead of FIM). The reason that may be a problem is that most folks do an import to get all their Windows users into the UPA. However if you want to use the same domain to import users for both Windows and SAML auth into the UPA, it won't work. You'll get an error when you try to create a second connection to the same domain. So you basically have to be all in - all SAML or all Windows; otherwise you'll end up getting all sorts of seeming random results.

Once you've get everything configured and you've run a profile import in both farms, then you can set up the first part of this scenario, which is doing cross farm searches by SAML users using Remote SharePoint Index. I literally used the same exact steps that I described in my previous blog post I referenced at the start of this posting (setting up an oauth trust between farms). Once that trust is set up then it's just a matter of creating a new result source that is configured as a Remote SharePoint Index, using the Url to the web application in the other farm (the one you used when creating the trust between the farms), and then creating a query rule to execute your query against the remote farm. When it's all said and done you end up being able to authenticate into your local farm as a SAML user and search results from the remote farm. In the screenshot here I'm logged in as a SAML user; you see his full display name because it was brought in when I did the profile sync:

Now, the real beauty of this solution is that we can actually get this to work when using the SharePoint 2013 hybrid search features with Office 365. In this case I have a farm where I already had the hybrid features configured and working. When I created my SPTrustedIdentityTokenIssuer, I made sure to include 3 of the 4 claim types (the only ones I populate) that are used in rehydrating users for OAuth calls - email, Windows account, and UPN. Since those values are also synchronized up to my Office 365 tenant (and thus put into the UPA for my tenant up there), I'm able to rehydrate the user in Office 365 and get search results from there as well, even though I'm logged in locally as a SAML user. Very cool!! Here's a screen shot of the same SAML user getting both local search results as well as hybrid search results from Office 365:

Hopefully this helps to clear up some of the mystery about SAML users and OAuth, as well as how it interacts with some of the built-in features of SharePoint 2013 like Remote SharePoint Index and Hybrid Search. Clearly the complicating factor in all of this is the UPA and managing your user profile imports. That would be the first planning item I would be thinking about if you want to use SAML authentication on site, in addition to SharePoint Hybrid. It's also clearly a sticking point if you wanted to use both Windows and SAML auth in the same farm with the same users from the same domain.