1

I have an on premises deployment of SharePoint 2013. Using the OOB Claim authentication provider (not using ADFS). Using NTLM. Not using Forms Based Authentication (FBA).

I've created a web part and trying to check the AD Group of the current user

if (Page.User.IsInRole("MYADGROUP")) {
   ...do something
}
//Adding the domain yields the same results
if (Page.User.IsInRole(@"DOMAIN\MYADGROUP") {...}

In the Page.User, I can see that there are many claims for groups but checking IsInRole always returns false.

Any thoughts on what could be the problem?

2
  • 1
    Try passing domain\groupname Jan 15 '15 at 17:25
  • I've tried this as well with the same results. I'll update the question with this
    – dwaynef
    Jan 15 '15 at 20:04
1

We encountered the very same thing when we transitioned from our pre-claims SP2010 environment to our claims-based SP2013 environment. Active Directory groups no longer represent roles under the new system, so you can no longer depend on IPrincipal.IsInRole to meet those needs.

Here is a block of code from our solution which has treated us well and should set you on the right track.

    public static string LookupSID(string accountOrGroupName)
    {
        var account = new NTAccount(accountOrGroupName);
        var sid = account.Translate(typeof(SecurityIdentifier));
        return sid.Value;
    }

    public static bool IsUserInADGroup(IPrincipal principal, string groupName)
    {
        if (principal is WindowsPrincipal)
        {
            return principal.IsInRole(groupName);
        }
        else
        {
            // I haven't figured out a better way to do this in the SharePoint Claims world yet.
            // For now, this is the SID of the group, and we hunt for the SID in the list of claims
            // verified in the current user identity. Note that it is VERY important to use the
            // Microsoft.IdentityModel.Claims.ClaimsIdentity class here. There is another ClaimsIdentity
            // class that will botch this up.
            var sid = LookupSID(groupName);
            var user = principal.Identity as ClaimsIdentity;
            return user.Claims.Any(c => c.Value == sid);
        }
    }

The first method is a utility method for retrieving the SID of an active directory group. The reason we grab an SID, is that the SIDs for groups that the user belongs to will be included in their list of claims.

Mind the comment about ClaimsIdentity. Apparently there are two ClaimsIdentity classes in different namespaces, and if you use the wrong one you'll be in worlds of hurt.

We keep these methods in a static class, which we call like so:

if (!CommonUtility.IsUserInADGroup(Page.User, "GroupName"))
{
    // Do authorized actions.
}

Note the absence of the domain\\ prefix in the group name. It wasn't necessary for us. Your mileage might vary if you operate in a forest rather than a single-tree domain. Even so, this should give you a head start on a solution.

Cheers!

1
  • Marking as the answer, this solves my issue. According to the documentation, msdn.microsoft.com/en-us/library/… the Windows Identity Framework 3.5 has been deprecated but looks like SP2013 still uses it.
    – dwaynef
    Jan 23 '15 at 13:55
0

Since the SharePoint site runs on IIS we can call
Page.User.IsInRole("domain\groupname")
to determine if the user is a member of the Active Directory group.

Take a look here: SP AD group

1
  • 1
    Sadly, using Page.User.IsInRole() is outdated, as it no longer seems to work with Claims. This is the approach we always used before Claims came around, though, so it will apply to those using older versions of SharePoint. Jan 15 '15 at 21:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.