Why the tokenGroupsGlobalAndUniversal (TGGAU) attribute matters in SharePoint 2010


I’ve seen more than one major issue affecting multiple service applications due to the same cause. If SharePoint 2010 service accounts don’t have appropriate rights in Active Directory, you may see common things fail like the following:

For Example:

Related to Search: Attempting to search throws “Unable to display this web part” error.

Related to Profiles: Unable to provision user profile synchronization service “local instance” on a server.

For both of these issues, the ULS logs contain the following event:

AuthzInitializeContextFromSid failed with GLE: 5

In SharePoint 2010, most service accounts require some specific access to Active Directory or certain functions will fail. SharePoint 2010 uses AuthzInitializeContextFromSid function. In a service application scenario, this function runs under the context of the associated service account and performs an S4U logon.

From MSDN:

AuthzInitializeContextFromSid attempts to retrieve the user’s token group information by performing an S4U logon.

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.

Resources:

http://msdn.microsoft.com/en-us/library/aa376309(VS.85).aspx

http://support.microsoft.com/kb/842423


Comments (5)

  1. My question for Microsoft is this – how in the heck are we supposed to do this with a one-way trust?

    My servers are in RESOURCE. Users are in ACCOUNT. RESOURCE trusts ACCOUNT. The service accounts are in RESOURCE. So there's no way to grant this access to the service account. And when I try to use an account in ACCOUNT as a managed account, SharePoint 2010 complains that it cannot look up information about this.

    I am really starting to think that Microsoft did NO testing of SharePoint 2010 in a multi-domain envionment. Many, many things just don't work in that setup in 2010 that worked fine in previous versions of SharePoint.

  2. Darren says:

    Matt, I totally agree … I'm suffering with exaclty the same issue — RESOURCE domain, one-way trust, sharepoint 2010 and a failing search with :

    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.

    Progressing with MS now — I'd like to hear if you find out anything on this.

  3. Russ Maxwell says:

    Matt,  I'm just the messenger  🙂

    You didn't see this in SharePoint 2007 because I believe we didn't use this function.  We did use it in SharePoint 2003 though:

    support.microsoft.com/…/894632

    Question:  Does it work if you enable 2 way trust as a test?  

    You stated the following:

    "when I try to use an account in ACCOUNT as a managed account, SharePoint 2010 complains that it cannot look up information about this."

    Answer:  My guess is another account "farm service account" is attempting to do the lookup.   I would test one way trust by specifying all SharePoint Farm Service and Service Accounts in the Account Domain..

    Hope this helps…

    -Russmax, MSFT

  4. For Search you can make a managed account from the ACCOUNT domain.

    This managed account needs to be created using PowerShell.

  5. Andy Burns says:

    I just thought I'd outline another failure symptom:

    Search index is configured, and a Domain Administrator account can successfully search with SharePoint search. However, a user cannot, even if they have very broad permissions within SharePoint. It seems like the problem is with security trimming (and ultimately, I guess it is) but there isn't and obvious relationship with the permissions configured within SharePoint.

    Matt Stratton's post describes it nicely:

    http://www.mattstratton.com/…/configuring-sharepoint-2010-search-in-a-one-way-trust-scenario

Skip to main content