Back in the pre-release days of SharePoint 2010, one of the most reliable sources of information on infrastructure issues was Russ Maxwell’s SharePoint Brew blog. It’s still a great resource, although he’s posting less frequently now than he was during the beta. In this post I want to share my findings regarding Pre-Windows 2000 Compatibility Access group rights in Active Directory. Everything I have to say is supplementary to Russ’s foundational explanation of Why the tokenGroupsGlobalAndUniversal (TGGAU) attribute matters in SharePoint 2010. I’m picking the discussion up from his closing comment, “At a minimum, certain service accounts like the search service account need to be a member of this group.”
Context
A couple of months ago I was building a client’s production farm. It was a pretty straight-forward architecture with few unusual requirements. I’d successfully provisioned everything and was deploying the PDF iFilter as one of my last steps. When I ran a test crawl to see if it could pick up the contents of PDF documents, I was surprised to find the Local SharePoint sites Scope contained zero items, even though the crawl successfully gathered 459 items. To add to my confusion, the People scope was fully populated. I verified that the scope didn’t need to be updated, then launched ULS Viewer. While reading the trace logs in real time, I re-ran a full crawl and spotted this clue (my bold):
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.
Investigation
This error message reveals quite a bit. We know the error occurs in a w3wp.exe process associated with SharePoint Server Search’s, “Query Processor”, and that the application pool identity of this process doesn’t have read access to the tokenGroupsGlobalAndUniversal attribute in Active Directory. This tells us the error is occurring on the SharePoint Search Service Application pool’s identity, rather than on the Search Service (which is not a w3wp). After searching for a bit I found a few useful posts/articles, but what really helped me was Russ Maxwell’s article, which I linked to at the top of this post.
I suspect that in his testing, Russ found different scenarios where Pre-Windows 2000 Compatibility Access rights needed to be granted to the Search service account, but in my case these rights didn’t help. His error and his explanation of the problem are different. I don’t want to make too much of this, since his post was circa Beta, but it’s worth noting there may be multiple issues with these rights and Search. In our case, we tried to grant rights to the Search Service account but the error persisted until we added the Search Service Application Pool Identity account to this group. In actuality, we identified these same errors on the farm account initially as well, but granting these rights to the farm account didn’t solve the problem.
I should also note for completeness, that there were Security event 4625 Logon Failure errors accompanying the ULS log entries until we granted access to the Search Service Application Pool Identity account, at which point these events were replaced by 4624 Success events.
After running one more Full Crawl I confirmed that the ULS errors were also gone. It’s reasonable to infer from these new ULS events that when PluggableSecurityTrimmerManager is selecting, “workid from scope()”, it needs these Pre-Windows 2000 Compatibility Access permissions in a Windows Server 2000 or Windows Server 2003 domain. Presumably if SIDs can’t be initialised, everything gets security trimmed.
How to use these findings
I’d recommend adding this to the list of permissions you may need to grant in a Windows Server 2000 or Windows Server 2003 domain. This is basically what Russ Maxwell was saying initially, as I read it. In this scenario, I’ve merely spotted a scenario where different rights are required and I can’t shed any light on why this hasn’t been required in every Windows 2000 or Windows 2003 domain I’ve worked in.
If working from a principle of least privileged access, I’d suggest granting these rights as needed during deployment. They shouldn’t need to be granted particularly broadly (unless you’re working with a 1-way trust from a resource domain, which is another story – see the comments in the Russ Maxwell post for an introduction). Alternately, it’s arguable that granting read access to this tokenGroupsGlobalAndUniversal (TGGAU) attribute isn’t opening an enormous hole, but that’s a question for each organisation to answer based on their security models.
A Note on User Profile Pre-Windows 2000 Compatibility Access Rights
While I’m speaking of variance in these permission requirements, I should note that I’ve seen a number of sources including Spencer Harbar, TechNet and this Russ Maxwell article mentioning the need to grant these same Pre-Windows 2000 Compatibility Access rights to the User Profile Synchronisation account, but I haven’t had any problems running without these rights in two different Windows 2000 or 2003 domains.
If the domain controller is running Windows Server 2003, the synchronization account must be a member of the Pre-Windows 2000 Compatible Access built-in group. See Add an account to the Pre-Windows 2000 Compatible Access group for instructions to grant this permission.
Given those sources, I’d suggest you’re probably best off granting the rights, but I haven’t yet been able to validate the need myself. I’d definitely be interested if anyone can shed more light on that topic.