Udostępnij za pośrednictwem

Kerberos Access Denied for Domain Local Groups

  • Artykuł

We recently encountered a situation where users were denied access to site collections in SharePoint 2010 web applications using Kerberos authentication. The users should have been granted access because they were members of domain local security groups, and those domain  local groups were added to the visitors SharePoint group for the site collections. The same users were able to access site collections in a separate WSS farm using the same domain local group for granting access. The only difference between the SharePoint Server farm and the WSS farm was Kerberos verses NTLM authentication for the web applications.

OK, so start checking Kerberos configuration:

  1. SPNs created correctly for the service accounts and web applications? Check!
  2. Users successfully authenticated by Kerberos when directly added to the SharePoint group? Check!
  3. The domain local group is in the same domain as the SharePoint farm? Check!
  4. Can the user access a new web application in the SharePoint farm using NTLM and the local domain group? Check!

Everything checks out, so why is access denied when the domain local group is used for a web application configured with Kerberos authentication????

OK, let’s take a step back and think about this. What is the definition of a domain local group? Looking at https://technet.microsoft.com/en-us/library/dd861330.aspx we find:

Domain local groups

Members of domain local groups can include other groups and accounts from Windows NT, Windows 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 domains. Members of these groups can be assigned permissions only within a domain.

Groups with domain local scope help you define and manage access to resources within a single domain. These groups can have the following as their members:

  • Accounts from any domain
  • Global groups from any domain
  • Universal groups from any domain
  • Domain local groups, but only from the same domain as the parent domain local group
  • A mixture of any of the above

Our domain local group complies with this definition, the members are domain accounts, the SharePoint farm is in the same domain, etc.; so again, why is access denied using Kerberos but not NTLM? It’s time for some deeper investigation.

SharePoint 2010 in Windows Classic mode keeps an internal token with the security identifiers (SIDs) of the user, and all the groups the user is a member of. This token is matched against the secured object’s ACL to determine if the user has access either by the user SID directly, or by membership in a group. This seems to imply our user’s token must be missing the domain local groups SID – but why?

How does SharePoint populate the list of SIDs in the token? SharePoint pulls the SID list from the Kerberos ticket. Looking at https://blogs.msdn.com/b/openspecification/archive/2009/04/24/understanding-microsoft-kerberos-pac-validation.aspx we find this high level description of the Kerberos ticket contents.

The Privilege Account Certificate (PAC) is an extension element of the authorization-data field contained in the client's Kerberos ticket. The PAC structure is defined in [MS-PAC] and conveys authorization data provided by domain controllers (DCs) in an Active Directory-enabled domain. It contains information such as security identifiers , group membership, user profile information, and password credentials. The illustration below shows the relationship between a Kerberos ticket and PAC.

KerberosTicket1

Noting the phrase conveys authorization data provided by domain controllers (DCs) , what DC is being used to generate the Kerberos ticket? To answer that, think through the ticket granting steps:

  1. What identity is used to request a ticket from the DC (remember the DC is also the KDC)? The SPN account.
  2. What is the SPN account for a web application? The web app’s application pool identity.
  3. What is the application pool identity? admin\AppPool1.
  4. What DC is contacted? The first DC in the admin.contoso.com domain that responds to the request.

And now one final question:

  1. Which domain contains the domain local group and SharePoint farm? prod.contoso.com.

The light bulb comes on! The service account (admin\AppPool1) is in a different domain from the users and SharePoint farm. The DC in the admin domain that generates the Kerberos ticket has no knowledge of domain local groups in the prod domain, since by definition, domain local groups are scoped to the local domain. The Kerberos ticket presented to SharePoint lacks the SIDs of the prod domain local groups, hence access is denied.

How can this be resolved? That depends upon the existing investment in domain local groups and the organization’s security policies. Some possibilities are:

  1. Promote the domain local groups to universal groups. This may be painful if there are hundreds or thousands of domain local groups. Besides the logistics of group promotion, you have to consider the additional DC replication traffic, and the possibility of breaking other legacy applications depending upon domain local groups.
  2. Move the SPN service accounts to the same domain as the SharePoint farm. This allows continued use of domain local groups, but may violate the organization’s security model;  that is, the admin domain may be used for service accounts due to other security considerations. This approach has side effects, like the need to get exceptions for the SharePoint service accounts, the need to delete and recreate the SPNs, and the need to modify GPOs that control password changes.

PS:

Another interesting factor to consider. Testing access to a site needs to be done using the user account itself. The Effective Permissions feature in Site Settings does not acurately reflect permissions granted by group membership unless the user has actually visited the site since the last group membership change.