A customer recently had a very odd issue crop up in SharePoint Online and although I’d seen the error message before it was always in the context of the user being a guest in the environment. Being that this was an internal user it’s probably worth documenting it for future use by someone…maybe even my future self!
User received a valid sharing link and was granted direct permissions to an internal SharePoint Online Modern Team site however was unable to login to the site and received the below error message:
“This link is not available to you.
Sorry, you are currently signed in a email@example.com but that account is not on the list of people this is secured to. To try a different email please sign out and open the link again.”
Investigation and Resolution
Having seen this exact error message a number of times for guest users attempting to access tenants with the wrong Microsoft Account/Organizational Account I initially assumed that was the issue here however I did not that the user was using the organization email address but was still getting sent to the GuestAccess.aspx page when attempting to login. Attempted to remove the various sharing already done on the site and regrant the users permissions to no avail. Even had them use the direct link to the folder that had been shared with them with no success so I started poking around in Azure AD and noticed something a little off on the account name then confirmed it via Delve…the UPN was firstname.lastname@example.org but the Skype ID and Email was JDoe@domain.org.
At that point I remebered a really odd issue we ran into with a customer around a year ago where a user wasn’t seeing SharePoint sites in the Office products. I thought it was enough of an edge case to post a blog article about it so I referred back to it to confirm my suspicion. As I was working with the organizations IT support when I mentioned this they noted there was some issues when originally creating this users account in Active Directory and it was recreated. Bingo!!! So it turns out that SharePoint still cares about the casing of names in certain situations and we happened to find one of them.
Fortunately we didn’t have to blow away the users Active Directory account. We were able to wipe the user our of the site collection completely (from the user information list) and regrant permisssions successfully. See “Remove people from the UserInfo list” for details but let this be a friendly-reminder to all my systems admin compatriots out there…if something seems wrong, fix it:)