Office 365 SharePoint Site Shared With External - Some users have "Deny" Permissions

Iron Contributor

Hi,

We have an SharePoint Online site which is shared with a number of externals. Some of the externals (who are authenticating with Office 365 accounts, not Microsoft Live accounts) are having the pages on the site continuously refresh/reload. Capturing a network trace with them, it appears this happens after a 403 encountered at SP.Web.GetContextWebThemeData.

Looking further into the permissions these users have, the ones with the issue all have a set of "Deny" permissions applied to them, which are not a part of the permission set on the SharePoint group they have been added to.

We restrict Sharing on the site to "Allow external users who accept sharing invitations and sign in as authenticated users", and also "Limit external sharing by domain" - providing a list of domains we are comfortable to share with.

Does anyone know where these "Deny" permissions may be coming from? I know in SP On-Prem we would start by looking at any policies applied to the web app, but obviously this doesn't apply to SPO.

 

Thanks,

 

Nigel

8 Replies

Meant to embed the image, not attach it:

 

Perms.png

Hi Nigel,

 

Can you send me an e-mail with this info at srice@microsoft.com and we can debug further. Thanks!

 

Stephen Rice

OneDrive Program Manager II

Thanks for the response Stephen.

 

I actually completed a service request investigation of this with Microsoft Engineering, and we found the issue was caused by the logic that implements the restrict by domain setting:-

 

  • We restrict user access to only a specified number of domains
  • The logic checks the domain by comparing the list to the users "Email Address" field
  • A number of the partners we are sharing to who have Office 365 accounts do not populate their user's email address field

 

Users without email address values who were granted access (and accepted the invite) were added to the SharePoint security groups, but the domain restrictions logic determined they should not be able to access, and applied the set of "Deny" permissions against them.

 

In my opinion the logic should be checking the domain against the user's login (not email address) as this is a required field, and hence is always populated. I also think it more correctly represents the user's corporate identity - especially for an Office 365 user (as opposed to an MS Live user).

 

The solution for us was to remove the domain restrictions, as we didn't feel we could dictate to other companies that they had to populate their user's email address field within Office 365. Disappointing, as this domain restriction was considered a key component in alleviating security concerns around external sharing.

 

Thanks

 

Nigel

@Nigel Witherdin The solution for this issue is to add your own domain to the list of allowed domains(tenantname.onmicrosoft.com) on the Tenant and to the site collection that is being shared externally. In my testing, in some cases by just populating external user's work email address in the user's profile did not work and I had to add our own domain to allowed list which helped.

 

Please test this and let me know if this solution worked for you.

Hi @Nigel Witherdin,

 

Thanks for getting back to me. I'm glad you were able to find the root problem even if the reasoning seems odd. I'll forward this to the folks who own this feature and make sure they're aware of this restriction. Thanks!

 

Stephen Rice

OneDrive Program Manager II

Has there been any more updates to this problem? I am doing some testing with the domain restrictions as it is a key part of our sharing in regards to securing data. The restriction works for any new users coming in. The issue I am seeing is that if an external user has already accepted an invite to one of our externally shared sites, they are able to be invited to another site where their domain is not allowed. I am wondering if it has to do with the same scenario above where it is looking at an email field that is not populated somewhere.

Joe, you are able to share with  an already accepted external user from a domain A on another externally shared site where domain A is not white listed is because the user from domain A is in your AAD and is a valid user in your tenant. Good thing is - though you can add the user to the site, the user gets notification but they will not be able to access the content on the site. When you check the user's permissions, you will see the deny list. When the user tries to access the link, he/she will be prompted with a message "Let us know why you need access...". Access request approving person on the site will be able to see requests and be able to approve but the user still gets "Let us know why you need access..." message.

 

But to your and our concern, the user shouldn't be allowed to receive share or invite notifications when their domain is not white listed on a site collection.

 

Hope this helps.

I am also having this constant page refresh issue, with the difference being that this is a fairly new SPO setup, with only 1 site migrated to test. there is no Domain whitelist configured yet, so not sure its the same root cause, but seems to be the same symptom.

 

If a hit the stop button in my browser, the page will load and i can browse it, with the exception of file icons and images not loading correctly.

 

We do have a custom theme applied, but i cant find anywhere to list the users full permissions a la SharePoint On-Prem.

 

Any one shed any light on this for me?

 

Thanks