Should we care about broken permissions in the context of sharing files in O365?

Iron Contributor

In the Office 365 ecosystem almost all files are essentially stored in SharePoint. The sharing window is now also being standardised across services including mobile experience

 

When users share a file, except for People with existing Access all other 3 sharing options break inheritance.

 

Assuming that we are following best practices like train users to use the most appropriate option, use Anonymous only where necessary, set default expiration, maybe use sensitivity labels to protect files shared externally, etc. at the end of the day when users share files, even internally, there will be tons of files with broken inheritance.

 

Is there any negative impact about this or any recommendation or best practice?

 

clipboard_image_0.png

3 Replies

Hi @mikkele ,

 

It would be nice if it didn't break inheritance, but the benefit of sharing cancels out the issues. I have kind of got used to it. 

 

I think with none sharing links its still a good idea not to break inheritance if you can, so at the document library and folder level but in some cases it has to happen. 

 

One thing to bear I mind is that when each file breaks inheritance when a link is created the inherited permissions are copied. Whatever you do, do not accidentally delete once of the groups giving access  - such as <Site name> members to the site. Contrary to what I thought it cascade deletes down to all uniquely permissioned files. Try adding those permissions back in and it doesnt work as the files are uniquely permissioned. I had a site with 200,000 files and every single file that had unique permissions disappeared from the 50 users that needed to access them. Luckily you can roll a full library back to a point in time now. You couldn't at the time.

@Andrew Hodges 

Contrary to what I thought it cascade deletes down to all uniquely permissioned files. 

that's good to know (and unexpected?) I didn't think that would be the case, it's probably because those SharePoint groups object are still linked 

I would expect the objects inside the group to be updated but I wasnt expecting if I uniquely permission a document library deleting that same group from above removes it from doc lib. Just how it is I guess.