Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

SharePoint 2010: Searching with a User from a Trusted Domain Returns No Results

Leave a comment

This “issue” is documented  under MS KB 2344518: Unable to Perform a query on a One-Way trust Domains Scenario when an User from the trusted domain performs the query and the SSA Application Pool account is from the Trustee Domain. So why bother blogging about it then? Well just for my very own pleasure of scratching the surface of things of course!

ok so here are the conditions to be met for the problem to occur:

  • The SharePoint 2010 Server is member of an AD domain considered as a resource domain: it contains only servers and service account, no real user account
  • That resource domain has one-way trust with one or more trusted domain whose real users are member of
  • De-facto, classic Windows authentication is used
  • The content is indexed “as usual” with the crawler storing item permissions based on the user’s SID (as well the SID of the AD groups it belongs to if necessary) in order to use them for security-trimming of search results when user performs queries
  • The group “Pre-Windows 2000 Compatible Access” from the trusted domains does not contain “Everyone” but “Authenticated Users” (default “secure” configuration)

And this is what really happens behind the scenes (intentionally simplified to ease understanding):

  1. The users issue a query against the WFE role
  2. WFE authenticates the users as DOMAINUSER and builds its access token (group membership, SID history and so on…)
  3. The WFE passes only the authentication information to the “Query Processor” (QP) component (which may reside on another server depending upon the farm topology)
  4. In order to perform security trimming on search results, the QP has to know about the user’s authorization, to do so, it contacts the user’s domain by first calling the function “AuthzInitializeContextFromSid()”.
  5. To respond to this call the DC of the user’s domain expects the client to authenticate (a consequence of the Pre-Windows 2000 Compatible Access). This fail since only a one-way trust in in place
  6. The DC responds with “Access Denied”, the information cannot be supplied to anonymous caller
  7. The QP is unable to construct a valid token and therefore, will not return any result for the search

When this happens, the message hereunder will show up in the SharePoint diagnostic logs of the server hosting the QP role (source: Query Processor):

AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user’s Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user

But wait, it did not happen on my MOSS2007 infrastructure! That’s right, it simply worked differently because the QP component was part of the WFE role and since the WFE role was aware of the user’s token, it could perform security-trimming without having to contact the user’s domain for this purpose.

Any Solution or Workaround?

Yep there are but I will let you qualify them and rank them by quality and feasibility 🙂

  1. Change your IIS Application Pool Identity for SharePoint with one from the trusted domain… This way the authentication of the call to the user’s domain is always ensured . Of course, it will not solve the problem if you have multiple trusted domains
  2. Establish 2-way trusts between the resource domains and the user domains. While this will solve the issue in all cases, some “security specialist” do not like 2-way trusts, it may not be allowed in your organization…
  3. Adding “Everyone” the the “Pre-Windows 2000 Compatible Access” group of the user’s domain. This is against security best practices since it will also expose large part of your AD to anonymous users…But it will also solve the problem
  4. Finally you can also change the way the indexer stores security descriptor by default by switching from Windows to Claim. This is the solution (rather poorly) documented in the KB2344518. Although exact consequences of this changes are unclear to me, it actually solves the problem. BTW, some say you cannot revert the change so as usual, make sure you test it in lab carefully! BTW, here are the commands in the correct order:

$SearchServiceApp = Get-SPEnterpriseSearchServiceApplication
$SearchServiceApp.SetProperty(“ForceClaimACLs”, 1)
$SearchContentSource = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $SearchServiceApp -Identity "Local SharePoint Sites"

Implications on Scalability

If the default configuration is left as it is, I have noticed that for each search request, the method AuthzInitializeContextFromSid() is used. The user’s context seems therefore not to be stored in a cache. You guess it, this means one roundtrip to the user’s AD for each search. IO let you imagine the traffic and possible latency that occur if you AD’s are not designed appropriately. So I ask myself this question: since everything in SharePoint is internally based on claims and claim-based ACLs, why not using claim-based ACL OOB in Search application?

More information



Author: Marc Lognoul

Relentless cloud professional. Restless rider. Happy husband. Proud father. Opinions are my own.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s