This project has moved. For the latest updates, please go here.

check permissions

Apr 13, 2015 at 5:41 AM
Edited Apr 14, 2015 at 2:41 AM
after configuring LDAPCP we realised that the "Check Permissions" function returns "None" when users do have access.
This happens for users that belong to AD groups and those AD groups do not live in SharePoint groups.
The main one is Domain Users which has Read access on the portal. All our AD users belong to Domain Users so that they have read access to SharePoint.
If a user or AD group is added directly to a SharePoint group, Check Permissions returns the expected permissions.
Any idea why this is happening?
Apr 21, 2015 at 12:07 PM
this feature relies on a non-interactive token that is not the same as the SAML token of user.
It is normally built when user authenticates and is valid for 24h by default.
When this token expires, it is refreshed by the component that is trying to use it. If it is refreshed upon a user action, then it will contain all the claims as expected, including group membership present in the SAML token.
But if it is built by an operation not triggered by the user himself (like the check permissions feature), the token built will be minimal as it doesn't know the claims Inside the SAML token of the user. The only claims it will contain are the ones added by augmentation by claims providers. As LDAPCP does not implement augmentation, it will not add any claim to the token of trusted users.
This explains why randomly SharePoint does not find actual permission of the user when using "check permissions" feature.