Procedure to configure NextLabs to support policies on claims based SharePoint 2010 or 2013

We are migrating SharePoint 2010 to claims to prepare 2013 upgrade as described in previous blog and would still need manage entitlement policies. At this point we are using NextLabs to manage the entitlement policies especially the one use cases – deny users in a certain group on selected site collections. In this blog, we will provide the detailed procedure how you could configure the NextLabs to fulfill this deny access policy. 

After SharePoint convert to claims, NextLabs could utilize the claims attributes instead of groups enrollment to apply policies. Here are the detailed procedure. 

1. The first step you need to do is to identify the claims attributes you could use for policy control. In this cases, we are looking the group that users belong to.  The unique identify for the group is SID. You could use claim viewer to display the attributes of the claims and LDAP viewer to find the SID for certain group. For example the SID for ExcludeGroup is S-1-5-21-945540591-4024260831-3861152641-341518.  

You could use one of the “features” on SharePoint 2010 to identify groups SID. Add the group to managed metadata term permission group like “Group Manager”. After you save the setting and come back, the group name will be displayed as SID as in the below screenshot.

On SharePoint 2013, you could use the permission check and identify the group claims SID at the bottom of the dialog box.

You could always use Powershell to get the claims SID.

2. The second step you need to add the claim attribute into NextLabs enforcer configuration file. The file is named  Configuration.xml under folder .\Program Files\NextLabs\SharePoint Enforcer\config. IISRET is required for NextLabs enforcer to pick up the change.

<Claims disabled="false">

                <Claim name="emailAddress" attributename="EmailAddress" claimtype="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" disabled="false" />

<Claim name="Groupid" attributename="Groupid" claimtype="http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" disabled="false" />

</Claims>

3.  The third step you need to configure the policy from Policy Studio using the Groupid configured from step 2. You could add a users subject and with property "Groupid" exactly same as in step #2 and the SID identified in step #1 as in the screenshot. You do not need to enroll users or groups anymore!

Then you could use this Users object inside the policy as in the following screenshot.

After you configured the policy, the users within the group with that SID will be blocked for the claim based SharePoint site collections. The first advantage using claim based attributes is the overall process is simplified since there is no group/user environment needed. The second advantage is the dynamic policy implementation and there will not be any group change delay due to the enrollment schedule.

Please note, the procedure provided here will only works for claim based SharePoint sites, if you have some webapps in classic mode NOT claims, you still need to enroll the groups and users and configure users object to point to enrolled groups.