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));
public static bool IsUserInADGroup(IPrincipal principal, string groupName)
if (principal is WindowsPrincipal)
// 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.