I’d a really, really weird problem with a customer yesterday. We’d set up their SharePoint search. Indexing seemed to be working correctly, and when I logged in as an administrator, I was getting search results correctly. However, logged in as a normal – though very highly privileged – user my search results were missing! This was some thing of a surprise. It felt like security trimming, but the user was a Site Collection admin, and had Full Control throughout the entire main content web application. Also, we were indexing content off the network file share, and we knew he could access both the SharePoint Content.

However, when he ran a search, he didn’t get any search results. That sucked. I tried another user account – and had the same problem.

Eventually, I looked in the logs and found the following message:

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.

Hmm. Sounds likely. I don’t think they were using Claims auth, and I think that the ‘Admin’ account that I had been given (which could search correctly) was actually a domain admin. Yeah, I know, I wouldn’t let me loose with one of those. I wondered if queries a the domain admin would actually be able to access the tokenGroupsGlobalAndUniversal attribute.

Anyway, I googled some of the error message, and found a post with a description and fix from Jeremy Thake, which I think ultimately came from Russ Maxwell. Well, we tried that – and it worked, which was reassuring! From his post:

In order to call the AuthzInitializeContextFromSid, the caller “service account” needs to able to read the TGGAU attribute. In Windows 2000 and Windows 2003 domain, members of the Pre-Windows 2000 Compatibility Access group are able read the TGGAU attribute. At a minimum, certain service accounts like the search service account need to be a member of this group. See the resources section for more information.

I was still curious, though. What really was the issue? Why did making the search service account a member of the Pre-Windows 2000 Compatibility Access group fix things. Well, the AuthzInitializeContextFromSid does the following, apparently:

The AuthzInitializeContextFromSid API function call reads the tokenGroupsGlobalAndUniversal (TGGAU) attribute of the security identification number (SID) that is specified in the AuthzInitializeContextFromSid API function call to determine Windows group membership information for the current user.

Okay, so we’re trying to get group membership. I can see how that ties in with security trimming our search results. But why wouldn’t we have that permission to read that attribute?

Well, I found a post from Matt Stratton where he mentions this being a problem in a one-way trust between domains scenario. And I found others describing the the same – repeatedly – and so changing their search service’s account to be in the same domain. Fair enough. But I don’t think that was the case for us.

To be honest, I’m still unclear what the problem was in our case.

More information here: http://support.microsoft.com/kb/331951