SharePoint 2010 claims migration issues and possible workarounds

If you migrate SharePoint 2010 to claims, you will be one step closer to leverage SharePoint 2013 architecture. We have followed the instruction provided in previous blog "What you need to know to migrate SharePoint 2010 from classic-mode to claims-based authentication as IT Pro, developer, or end user?". However, there are some issues issues we are facing after the migration. It might worth to discuss the symptom and possible workarounds. 

1. The first issue is exception when calling all SharePoint 2010 web services within browser based InfoPath 2010 forms.

Opening this form works fine as long as you open the form using InfoPath on the client. When attempting to view the form in the browser the error occurs as described in Russ Maxwell's blog.

Several blogs have explained some workarounds and I've summarized as below.

• Call a Web Application configured to use Classic Authentication from Russ Maxwell
• Configure a security store and use it for authentication
• Modify UDCX from the data connection string user name and password

When we worked with Microsoft, we found following message from IIS logs.

POST /_vti_bin/userprofileservice.asmx - 80 0#.w|nt+authority\iusr 172.30.36.22 HTTP/1.1 InfoPathDA

It seems like the InfoPath web form is using “nt authority\iusr” to access web service instead of the app pool account. The fix is to modify the web.config as follows to disable anonymous impersonation.

<add key="aspnet:AllowAnonymousImpersonation" value="false" />

After the changes, you should be able to call the web service without error. However, the user name display will be application pool account anme instead of the end user! There is major difference when execute using InfoPath client vs. browser. When you run a form from InfoPath client, it uses credentials from the user currently logged in to the computer. When you run it from the browser, it runs as the application pool identity when web.config key is set to false.

The solution is to change the call to use userName(0 to get from the context the user who's logged in, instead of the process account as in the following screen shot. You can associate userName() as the value of any text box controls.

2. The second issue is user/group display names as SID from two places.

One place is the display name for both user or group will append the SID if you add them directly to SharePoint NOT to the SharePoint groups as in the below screen shot. 

There is no workaround at this time. You should educate the users not to grant permissions directly but through SharePoint groups. The good news is this issue will be automatically resolve after you upgrade the site to 2013. All the names will be displayed correctly.

Another place is the display name for group for managed metadata term store if added to "Group Manager" or "Contributor". The group will be displayed as SID instead of the name. The good news is by click the person icon when in edit mode, you could "convert" the SID to group name. The bad news is it will be displayed as SID after you saved it again. This will be same when you upgrade to SharePoint 2013. We will work with Microsoft to find a good solution.

3. The third issue you may not find user "Permission level" through check permission UI for users who have not logged in to the site AFTER claims conversion. The permission chek result will be "None" as in the below screen shot. In addition, these users will not able to email to the email enabled list!!!

The display issue is only happens for certain AD instance with AD group level in previous version NOT on 2008.

The email issue is major issue for those users. This issue seems to be same on 2013!

We are working with Microsoft now and suspect this might be related to AD function group version. We will keep you posted.

4. The forth issue there will be two duplicated owner entries for any mySite created after claims conversion as in the below screen shot.

You may noticed one entry is window authentication and the other one is claims with SID. If you modify the owner permission, it will only affect the one in claims.

We have verified this will still be the issues on SharePoint 2013 and it's even worse since it will display user name only as in the below screen shot and you will not see the difference for these two entries.

Although there is no impact to the permission, we could like to remove the unused duplicate Window based owner entry. The workaround is to remove the window authentication owner entry from event receiver code. We are working with Microsoft to find a final fix.

5. The fifth issue is the designer workflow using user field issue. The workflow will stop working and the work around is to republish the workflow.

If you have any other issues after claim conversion, please share your findings.

 

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.