Unexpected Access Denied: Invitations via Group Membership result in Single Instance Access Denied.

This post has been republished via RSS; it originally appeared at: SharePoint Support Blog articles.

 

Note: for a breakdown and overview, see the bottom of this article.

Background

Mary works for Tailspin Toys.  Excited about her new project, collaborating with a freelance artist on a new product, Mary uploads her project proposal and design documentation to a document library in a subsite dedicated to this project, and hosted in SharePoint Online. Wanting to share only this file, she breaks inheritance and grants permissions to the file to an external collaboration group, per her company policy regarding external collaboration.  She then emails her SharePoint Admin, who then adds her collaborator, Abdoulaye, to the group.

 

Abdoulaye receives an invitation email to Tailspin Toy’s SharePoint Online tenant and clicks the accept invitation link.  He proceeds through the registration process, using his own Office 365 Small Business Account (Organization Account) but gets an access denied.  He copies the text of the error and  forwards it on to Mary, who sends it to her SharePoint Administrator, Peter.  Peter opens a support case with Microsoft, and together with the Support Engineer Alice, set up a troubleshooting session with Abdoulaye.  When they ask Abdoulaye to access the file, he can access the file with no issues.

At first, Alice is leaning towards this being an isolated issue, but Peter, who has had this same exact thing happen to him twice before, forwards Mary the Service Request Numbers of the previous two interactions, mentioning that he has had reports of this prior to opening a request with Microsoft. Alice agrees that this is peculiar, and the two agree to attempt to reproduce the problem.  Working together, Peter walks Alice through each step in the process.

 

  1. First, the owner of a sub-site (Mary) with broken permissions inheritance will decide to invite External Users. They create a SharePoint Group and assign permissions for the site or library to the group. 
  2. The Site Collection Admin, (Peter), then receives the request to add a user to the group, and he adds the user to the SharePoint Group. Working with Alice, Peter adds her to the collaboration group.
  3. Alice, or the user invited, receives the invitation. When Alice clicks the link to accept the invitation, she too receives the access denied.  Luckily, she had a Fiddler capture running and was able to capture the access denied immediately.
  4. She then tries again to access the file, and can open the file, just like Abdoulaye.

The Investigation Continues

Because Alice was able to capture a reproduction of the error, she is immediately able to access backend logs.  SharePoint Online generates a significant amount of telemetry data in the form of usage logs, and there is a limited time window when the full logs are available before they are scrubbed clean of any Personally Identifiable Information.  When she reviews the logs, she’s immediately able to spot the issue.

 

With broken inheritance subsites or items, the group has only limited access to the resources that exist higher up the hierarchy.  When the invitation is being generated however, it is done not in the context of the item, which exists in a subsite below the main site, but rather in the context of the root of the site collection, where all groups for all subsites exist.  Because of this, the invitation email was forwarding the user to the root of the site collection, and not the item.  The invited user does not have the proper permissions to the root of the site collection, and thus gets the access denied.  Subsequent attempts have the user going directly to the resource, and so it works.

 

Peter is now really frustrated.  He wants to be able to implement an approval process to include some sort of check on external user sharing, and now he’s being told he can’t do that.  However, by explaining to Alice the specific business needs he’s trying to accomplish, Alice can suggest an alternative method to satisfy those business needs, while at the same time, not having to instruct users to ignore error messages.  Together, they turn to look at a different process.

Azure B2B (Business to Business) User Invitations

We will be taking a deeper look at the way in which Azure Active Directory Business to Business (AAD B2B) interfaces with SharePoint Online in a future article that will be linked below when it becomes available.  But after looking at the feature sets and process ideas suggested by Mary, Peter was not only interested in using Azure B2B to satisfy his requirements, but also excited at the possibilities for auditing and security reports available to him using his AAD Premium subscription. 

 

Peter decided on implementing a process where the external user would receive a B2B invitation, accept that, and then be directed to the resource to which they were invited.  With Azure B2B Invitation API, Peter could customize the invitation email to include instructions on what to expect as well as a privacy and consent disclaimer. 

 

As Mary resolved and closed the latest Service Request, Peter was thankful he and Mary were able to discuss not just the technical problem that started the service request, but the underlying implementation goals that allowed Mary to direct him to a far richer and less frustrating feature set for him to accomplish the same task, with less worry and less overhead.

 

The next time you find yourself speaking with Microsoft SharePoint Online Support, remember to take a step back, and consider the underlying goals you’re attempting to accomplish.  Perhaps your Support Representative can suggest a new or different method of accomplishing the same objective, and in doing so, help you be more successful and more efficient.

Join us next time for more on how Azure B2B and SharePoint Online interface for rich collaboration experiences that are simple and secure.

Key Points and Summary

  • When you are inviting users through group membership, it is possible to generate invitations to resources that the group does not have access to.
  • This will often result in a single instance failure for external users and can lead to frustrating support experiences.
  • When you have a situation where an issue is causing multiple support engagements, consider having those previous SRs and the summary closures with you to share with your new engineer, in order to facilitate faster troubleshooting.
  • When implementing an approval process for external user sharing, consider leveraging Azure Active Directory’s Business to Business (B2B) features for a suite of tools that will facilitate this kind of process implementation.

Many thanks to my Colleague, John Fulton, for the idea that led to this post.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.