Cloud SSA is one of the latest offerings in SharePoint search world which is next level in a Hybrid Configuration Scenario . Here is a Great Post by Brian here which provides some insights of what entails in a Cloud SSA Setup
While we had many customer's Try & Deploy Cloud SSA , leading to discovery of interesting information about the working of the Cloud SSA . There are differences on a how a Cloud SSA & Search would behave in a hybrid scenario when you compare this with a Traditional On-prem SSA , here are a 2 Important ones ..
Windows Claims only
Cloud SSA or To be Specific the Search Components in SharePoint online at present do not understand any other ACL type other than Windows Claims , This ACL information ,about the Content which is fed along the index is used for Security Trimming the results . SAML Identity Providers are not supported with Cloud SSA . So basically the On-prem Site you are crawling using the Cloud SSA should be using Windows Auth only .
if you search on an extended URL of Web-applications which is ADFS / LDAP or Some other type of Auth other than Windows Claims , No search results will be returned as the logged in user's Identity cannot be resolved to ACL mapping we have on an Index Item .
Searching on Non Default Zone URL's
While this used to work like a Charm in a Regular SSA on premise , but would not in case of a Cloud SSA in Hybrid Setup .
In an On-prem Scenario , the SSA has access to Alternate Access mappings URL for the Web-application & affectively change the Default zone’s URL and enables the query component to switch it out with the equivalent URL for the zone the user is trying to Search for . What this means that the results show up effectively with Same Zone URL's you came & searched on . Provided you crawled the Default Zone URL only . Refer to Brain's Post Here if you need to understand this a bit in detail
Whereas on a Cloud SSA , the Crawling Happens on premise and the Default Zone url which you are crawling is fed to the Index on the Cloud . Since the Query is being served from Components in the Cloud which have no knowledge of the alternate URL's available for On-prem Web-application , no URL Translation happens . In Fact there is No concept of AAM's in cloud Space.
The Only way to work around these limitations is to ensure that
- The Public Default Zone URL should be a FQDN URL or The END URL which you want to Show up to the users in search results.
- The Default Zone URL which is being crawled should have Windows Claims Auth so that ACL information sent along with crawled Content is recognized by Search Components correctly .
- The User Needs to Perform Search from a URL while logged in windows Identity , so that it can be resolved effectively to validate Claims & Security Trimming to work effectively .
Note : Please ensure that Public URL which you want end users to see , should be accessible to Crawler on premise to be able to crawl the site successfully .
POST By : Rajan Kapoor [MSFT]