SharePoint – Troubleshooting “Access denied” issues when using SAML authentication
Are SharePoint users getting the message "Sorry, this site hasn't been shared with you." when trying to give them access to a SharePoint site that uses SAML authentication? Below I explain some of the common mistakes that administrators make when giving users permissions to a SharePoint site that is using SAML authentication.
Giving users access to SharePoint using SAML
When using SAML claims with SharePoint, depending on your SAML configuration. You can give your users access either by using the user's identity claim or Group/Role claim. Below I go over both methods.
Giving access using the Identity claim of the user
To give access using the user's Identity claim, you first need to determine which claim is configured as the Identity claim in your SharePoint farm. This is the special claim that SharePoint uses to identify the user. If you are not sure which claim has been configured to be the identity claim in your farm. Then run the following PowerShell script on one of your SharePoint servers using the SharePoint Management Shell. In the screen shot below you can see that my identity claim is "E-Mail Address". In other cases, it might be configured as the UPN, SamAccount, or some other type of claim used for identifying the user.
Get-SPTrustedIdentityTokenIssuer | % {$_.IdentityClaimTypeInformation}
Now that you have found your identity claim type. We need to determine if the user is getting added to the site correctly.
If you do not have a custom claim provider configured on your farm. It is important to understand that it is very easy to add the user in-correctly to SharePoint. SharePoint will not validate the user against the identity provider like you are used to when using Windows claims. This means you must enter the user's identity claim correctly without typos.
Incorrectly adding the user
Since my farm doesn't have a custom claim provider configured, I can accidently add the user in correctly. I should be using the E-Mail address claim and not something like the users display name.
Correctly adding the user
When picking your user, make sure you select the user in the list that has the identity claim and not some other claim that is not the user's identity claim. In the screen shot below I am choosing the user with the E-Mail claim by hovering over it to see the claim type.
Giving access by using a Group/Role claim
Depending on your custom claim provider, you might call your groups "Roles" or "Groups. They are both the same thing. Using the group/role claim can be just as tricky because they can come in a few different formats. Depending on the custom claim provider configuration, you could be using one of a few formats for groups. For example, they might be in the format as "domain\group name" or just "group name" without the domain name. Below I show examples of a few group format examples.
Unique Group name – "Group A"
Domain name with group name – "Contoso\Group A"
If you are not sure what format your Group/Role claim is in. You can capture a Fiddler trace of the user to collect SAML token being created for the user. There we can determine if we are using the right claim format. See the next section below.
Collecting the SAML token with a Fiddler trace If you have determined that you are correctly giving your user permissions either by the identity claim or by Group/Role claim. We can take a Fiddler trace from the user's workstation during the login process to the SharePoint site. You can validate what claims your custom claim provider is provider to the SharePoint server on for the user.
Step 1 – Download and install the Fiddler application to the user's workstation - Fiddler Download Here. Installing Fiddler is straight forward, just go through the install wizard selecting Yes to all the menus till its completed.
Step 2 – Once you have Fiddler installed, start the Fiddler application. Next make sure you enable HTTPS so we can decrypt the SSL packets. To do so, select "Tools/Options" on the Ribbon, then select the "HTTPS" tab. Check the box next to "Capture HTTPS CONNECTs" and the box next to "Decrypt HTTPS traffic". Select OK to complete the configuration.
Step 3 – To start and stop the capturing, you can click on File in the top ribbon and select "Capturing Traffic" or by clicking "F12". When it's capturing you will see the words "Capturing" in the lower left corner.
Step 4 – Once you have Fiddler capturing, have the user log in to the SharePoint site using Internet Explorer. The user should be re-directed to the custom claim provider for authentication.
Step 5 – Once the user gets the error message, stop the Fiddler trace by pressing F12.
Step 6 – Now review the Fiddler trace looking for the URL that contains " /_trust/ ". See my screen shot below. You can see in frames 2 through 5 the user accessed the SharePoint site and was re-directed to the custom claim provider in frames 7 through 9. Frame 10 is where we get the SAML token that was generated by the custom claim provider. Select the "Inspectors" tab and then the "WebForms" tab. Locate the "wresult" section and copy everything opposite from it in the value Colum.
Step 7 – Paste the contents into a Notepad and save it as a XML file, see below. Be sure to switch your Save as type to "All Files (*.*) ".
Step 8 – Open the saved XML file using your web browser. Reviewing the information in the SAML token you can see the claims provided by your custom claim provider.
SAML token explained:
GREEN Box – Here you can see the email address identity claim for the user. This is the claim we are looking for when identifying the user. When giving this account permission to the SharePoint site, it has to be in the same format as found in the Fiddler trace above..
BLUE Box – Here you can find the role claims for the user. Take note of the format of the role claims in your SAML token, this is the format you should use when adding it to your SharePoint site with people picker.
YELLOW Box – Here we can find the SAML Life time by subtracting the Created time from the Expired time. This value is set by the claim provider. In this example its set for 1 hour.
STEP 9 – Using the information in the SAML token you can validate if you are giving the user permission correctly to the SharePoint site using the correct identity or Group/Role claims. Try re-adding the user to the site collection using one of the claims found in the users SAML token captured in the Fiddler trace and have the user test again. Once you get the right claim added the user should be able to access the SharePoint site successfully.
Note – If you do not see the correct claim information in the SAML token. Then there must be a configuration problem with your custom claim provider.
Comments
- Anonymous
January 29, 2018
This is great, so useful! - Anonymous
January 29, 2018
Thanks for sharing this Sean! - Anonymous
January 30, 2018
5 Star Blog!! Thanks for sharing! - Anonymous
January 30, 2018
Very detailed guide. Keep up the good work.