Check user permissions for users in trusted domains

Copper Contributor

I have identified a change in how SharePoint handles the Check Permissions functionality from SharePoint 2013 to SharePoint 2016/2019. If you have users in domain A, and a SharePoint farm and security groups in domain B, SharePoint 2016/2019 will fail to show if a user has access to a site if he is granted access using security groups (from domain B).

This is caused by a change in the internal static method

 

Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProviderGetRolesForUserBestEffort(string username)

 

In SharePoint 2013 the implementation of this method makes a call to

 

System.DirectoryServices.AccountManagement.UserPrincipal()

 

In SharePoint 2016 and 2019 this method will never be called because of an enabled feature flag (AuthZenImprovedGetRolesForUserBestEffort) that now changes the implementation to only make a call to the method

 

Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider.GetTokenGroupsForUser(PrincipalContext principalContext, SPClaim entity, List<string> result)

 

The behavior in SharePoint 2016 and 2019 is the same as what would happen in SharePoint 2013 if the SPWebApplication PeoplePicker property SidHistorySafeMode or UseGlobalCatalog where set to true (both defaults to false).

 

My questions are:

Is this design change intentional, and if so, what is the reason behind that? Does it mean that it's not supported to have a SharePoint (2016/2019) farm installation that has users in a separate domain like mentioned above?

 

Is this a bug/oversight or something that can be changed so that it's possible to correctly identify permissions for users in a trusted domain?

 

Is there a workaround or alternate approach to successfully have the Check Permissions functionality work when having users in a separate trusted domain?


SP2013 code:

 

UserPrincipal principal = null;
try
{
    principal = UserPrincipal.FindByIdentity(principalContext, entity.Value);
}
catch
{
    principal = null;
}
if (principal != null)
{
    userSecurityIdentifier = principal.Sid;
    if (SidHistorySafeMode || UseGlobalCatalog)
    {
        GetTokenGroupsForUser(principalContext, principal, result, strDomain);
    }
    else
    {
        foreach (Principal principal2 in principal.GetAuthorizationGroups())
        {
            result.Add(SPClaimEncodingManager.EncodeClaimIntoFormsSuffix(SPClaimTypes.GroupSid, principal2.Sid.Value, SPClaimValueTypes.String, SPOriginalIssuers.Format(SPOriginalIssuerType.Windows)));
        }
    }
}

 

SP2019 code:

 

if (VariantConfiguration.IsGlobalExpFeatureToggleEnabled(ExpFeatureId.AuthZenImprovedGetRolesForUserBestEffort))
{
    GetTokenGroupsForUser(principalContext, entity, result);
}
else
{
    UserPrincipal principal = null;
    try
    {
        principal = UserPrincipal.FindByIdentity(principalContext, entity.Value);
    }
    catch
    {
        principal = null;
    }
    if (principal != null)
    {
        userSecurityIdentifier = principal.Sid;
        foreach (Principal principal2 in principal.GetAuthorizationGroups())
        {
            result.Add(SPClaimEncodingManager.EncodeClaimIntoFormsSuffix(SPClaimTypes.GroupSid, principal2.Sid.Value, SPClaimValueTypes.String, SPOriginalIssuers.Format(SPOriginalIssuerType.Windows)));
        }
    }
}

 

5 Replies
Is this cross forest? Adding users in a cross forest scenario to a security group in the remote forest has never worked as the users are added to the remote forest as a foreign security principal which SharePoint cannot resolve.

@Trevor SewardYes, it's cross forest. It works in SharePoint 2013 if the People Picker properties SidHistorySafeMode and UseGlobalCatalog both are set to false (which is the default value).

It works in SharePoint 2013 because principal.GetAuthorizationGroups() is always called when getting the token groups. 

The users are in the remote domain, and groups are in the local domain where SharePoint is installed.

@Jens Otto Hatlevold Did you get any more clarity in this?

 

We have a 2016-farm (connected to Domain A) and users in Domain B-AD groups do not get access unless they click "Sign Out" on their user top right corner. The AD groups from Domain B are added as Edit-permission in SharePoint Permission Groups.

 

Domain A and Domain B has two-way trust between them.

 

UP sync works for settings against Domain B.

@Matz Höög No, the company I worked for had plans for migrating into a new domain removing every domain trust that they had. After this was completed not long ago we did not have this issue anymore as all users, groups and SharePoint is now in the same domain.

Check user permissions for users in trusted domains

Hi,


I have the same problem, did you find a solution.


I have users in domain A, and security groups (AD Goups) in sub domain B (trusted domains).
Domain B security groups contain users of Domain A.

The Permissions check functionality in SharePoint 2019 (CU March 2021) does not pull up security groups (AD Groups) from a different domain than the user's domain.
In the SharePoint logs file, we get this error message "unable to obtain GroupPrincipal object for group SID {0} which is found in the SPClaimsAuthRoleProvider.GetTokenGroupsForUser() method.

This works perfectly with SharePoint 2013 and SharePoint 2016


Best Regards
Edmond