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.