SharePoint: Quick Troubleshooting Tip: Add the Account column to User Information List
Often while troubleshooting authentication or permission problems, you need to see the actual account name for the user or group added to permissions.
This is particularly important in SAML / Trusted Provider authentication because the way the claim is being passed in the SAML assertion must match exactly with the way claim has been added to SharePoint site permission.
Adding the “Account” column to the User Information List makes it easy to see how the user or group was added to the site.
How to:
Go to Site Settings | People and groups.
In the browser address bar, change the number at the end of “MembershipGroupId=” to a zero:
That will take you to the User Information List, showing all users and groups in the site.
Click on Settings in the tool bar and choose List Settings:
Scroll down to the “Views” section and click “Detail View”
Select the “Account” column. I also like to change the position so that the Account column appears right next to the Name column:
Now I can see the account names for each user and claim that have been added to site permissions.
I have a mix of SAML (ADFS in this case) claims for Email, UPN and Role, and also a Windows-claims authentication user and group.
I’ve added some notation to the screenshot below to point out which is which:
Example of when this is helpful:
Now lets pretend that I’m trying to give permission to a site using ADFS authentication, using my Active Directory group named “Group Area” as a role claim.
I can see that a role claim has been added to site permission for that group:
But if a get a Fiddler trace of the user logging in, I can see that the role claim for that group is being passed slightly differently in the SAML assertion:
The Problem:
“joroar.local\group area” does NOT match “joroar\group area“, therefore I should not expect to get any permission to that site based on that role claim as it currently stands.
When it comes to claims, the claim type and value must match exactly. There’s no such thing as ‘close enough’.
To make this work, I would need to make a change on one side or the other to make the issued claim match the permissioned claim.
I would need to either change how the trusted provider is issuing the role claims within the SAML assertion, or I would need to change how the role claim is being added to site permission.
Trusted Provider side: The claim mapping would need to be adjusted to send the claim in the expected format.
SharePoint Permission side: Often, the way claims are added to site permissions is governed by a custom claims provider like LDAPCP. Depending on the claim provider, you may be able to make a simple configuration change. In other cases, the source code of the custom claim provider may need to be updated.