Inheriting something is a mixed pleasure.
You can become the proud owner of your uncle’s lovely old-timer, or be able to wear your grandmother’s diamond necklace and matching earrings at grand events, but you generally receive those treasures only after a dear one has passed away.
But you can also inherit debts, a house with an expensive mortgage, a nephew or other “things” that you have never wanted.
Inheriting permissions in SharePoint can also be a curse rather than a blessing.
“I have suddenly lost access” has been the title of many recent incidents. No need to blame this on Microsoft, SharePoint or the support team, because in 99% of cases this is a human error:
The Site Owner accidentally removed their own permissions while cleaning up a document library’s or site’s permissions. The support team can easily fix this.
The Site Owner accidentally inherits the permissions from the parent site. That is pretty serious and has happened alarmingly often!
I have already mentioned in many of our instruction materials: “if you see “this web site has unique permissions” in the yellow bar, DO NOT CLICK “Delete unique permissions” as you will
Inherit the permissions from the parent site
Lock yourself out of your site if you have insufficient permissions on the parent site
Remove all unique permissions in your site (and there is no “undo” or “restore” option)
The warning message appears not to be informative enough to keep people from proceeding.
Recently I have guided a few people through “permissions stuff” via screenshare and I notice that they always want to click ‘Delete unique permissions” when they want to remove users. In several cases these users were individuals who were not in a group and therefore were seen as having unique permissions.
On those occasions I have been just in time to guide their mouse pointers to the right button: “Remove User Permissions”.
This has now happened so often, with such serious consequences, that I have added a suggestion to Microsoft SharePoint Uservoice to rename “Delete Unique Permissions” into “Inherit permissions from parent” as this is probably easier to understand for the user than the current wording. If you agree, please support my request. (Happy to return the favour, of course)
You know, like in SharePoint 2007:
And if you have taken any measures that successfully prevent this accidental inheritance, please share!
Image courtesy of Phil_Bird at FreeDigitalPhotos.net
Part of my role is solving user issues. Sometimes they are so common that I have a standard response, but sometimes I need to do some sleuthing to understand and solve it.
As many of my readers are in a similar position, I thought I’d introduce SharePoint Holmes, SharePoint investigator, who will go through a few cases while working out loud.
The first case is about a Datasheet View.
One of the users of a site did not see the items in a list. Having access to the data was a requirement for his role and he had always been able to see this content before it was migrated to SharePoint Online.
So, I put on my SharePoint Holmes cap and rolled up my sleeves.
I logged in with my Admin account and went into the site.
I saw the items perfectly well. Just items in a Datasheet view.
Permissions check – the user had Read permissions to the site.
Items with unique permissions check – the list had unique permissions but the user had Read access.
Item-level permissions check – in the Advanced List Settings it showed that all items were visible to all users of the site.
Workflow check – no workflow reducing permissions after going through a process.
Right, that was an interesting one.
It was time to look through the eyes of the user, so I added myself to the same user group and checked. An empty list stared back at me.
I went through the other views and found a standard one. I could see the items in there, and so could my user.
One of my colleagues mentioned that issues with the latest IE update had been reported, which might have influenced the Datasheet view. We tried different browsers. That made no difference, but there was always that difference between user and admin.
Search engine to the rescue! One of the results surprised me, and I had to test that.
I created a datasheet view in my own tenant. It looked like this:
Then I logged in with Contribute permissions. It looked like this:
Then I logged in with Read permissions. It looked like this:
In my latest post I showed you how you could limit the options to share the content in your site. I hope that you have made some decisions, so now it is time to clean up the mess.
Let me remind you why too many options to share can turn into a problem:
Sharing a document or list item, or using the “Get a Link” option, creates unique permissions, and that means that the permissions of a document or list item no longer follow the permissions of the site. So if you add a new group (recommended) or a new person (not recommended) to the site, this group or person will not automatically get access to those items.
This will lead to unexpected access denied messages and therefore Access requests.
Approving Access requests may lead to more unique permissions AND they give people Contribute permissions by default, which may be too much.
Unlimited sharing (especially with external users) can lead to your documents falling into the wrong hands.
So, how to take back control of your site after you have changed some of the settings?
Have a note-taking system ready – paper, OneNote, Notepad, document – whatever is your thing. You will need to make some notes.
1. Process pending Access requests
Go to Site Settings > Access Requests and Invitations and see who has requested access.
Click the … next to each name and add people to site groups as much as possible. If you do not see the site group mentioned, note down their names with the group that you want to add them to.
2. Remediate content with unique permissions
a. Go to Site settings > Site permissions and click on this link:
b. You will get a pop-up with all lists and libraries that have different permissions.
c. The items marked as “manage permissions” are usually lists and libraries that have different permissions by design. Skip these.
d. Click on “view exceptions” for the first list or libraries that has this mentioned. You will see all documents (including pages and images) or list items that have unique permissions.
e. Using Rightclick > Open in new tab, click “manage permissions” for the topmost item. (If you just click “manage permissions”, you will have to start at a. again for the next document or list item)
f. Check if there are any people mentioned that you may want to add to one of the site groups, and note down their names + intended site group.
g. Click “Delete Unique permissions” to re-inherit the permissions from the list or library.
h. Repeat steps e, f and g for the next document or list item.
a. Go to Site settings > Site permissions and click on this link:
b. Check if there are any people mentioned that you may want to add to one of the site groups, and note down their names + intended site group.
c. Remove any individual users so you are left with only the site groups.
4. Add the new users
Add the users that you noted down during steps 1, 2 and 3 to their respective groups.
5. Review the Members group
During the time that you had no restrictions, Members may have added other Members. Review your list of Members and change their roles or remove them where needed.
6. Replace any “breaking links” on your pages
Hover over every link on every page in your site and look at the link in the bottom-left of your screen. Links of the “Can View” or “Can Edit” type will generally have “guestaccess” in their link and they will cause unique permissions.
When I did not know all this yet, I had created some Promoted Links with the “Get a Link – Can View” link to a page. As soon as I created the link, the permission inheritance for the page was broken and everyone who clicked on the link was added as individuals to the page.
Replace every one of those links with the “Restricted Link” equivalent.
Review on a regular basis if the restrictions and the cleanup work make you feel more in control of your site. Depending on your choice of measures, you may need to do more approvals from Visitors or Contributors who want to share content.
How have you dealt with the “Unholy trinity of creating unique permissions” 🙂 ? Would you like to share your frustrations or have you found a good way to deal with this that other readers can benefit from?
Image courtesy of artur84 at FreeDigitalPhotos.net
In my most recent post I focused on sharing documents and items by the Site owner, demonstrating that the Site owner him/herself can easily create lots of unique permissions by sharing folders, documents and items.
But what happens if a another user of your team site shares? Can a Member or Visitor create unique permissions as well, and does the Site owner know what the Site members are doing?
Once again, we start out with a team site with the standard permission sets (Owner, Member with Edit permissions, Visitor with Read permissions) and no unique permissions.
Durian Grey is a Visitor and Mystery Guest is a Member. We also introduce Kimberley B, who has no access at present.
Document 1 does not change permissions since Durian already has Read access to this site.
Documents 2, 3 and 4 get unique permissions after clicking the “Share” button in the Sharing screen.
The persons are added as individuals to the document
Documents 3 and 4 have the individual added with “Contribute” while Members in this site have “Edit” permissions. (and the Share option is called “Can Edit”) So, a new role is added.
These following results were a surprise for me:
The documents shared with Kimberley B generate an External Sharing Invitation (access request) but the Site owner does not get an email notification.
Kimberley B can only share the document with existing site members when she has View permissions. but she can share the document with ANYONE, including new externals, when she has Edit permissions.
When Kimberley B shares with another external user this creates an External Sharing Invitation for the new person.
Sharing documents/items by a Visitor
Durian shares document 5 with Mystery Guest. He can not select Can View or Can Edit. When he clicks “Share”, he sees a message that this request is being sent to the Site Owner but that does not happen; the message goes straight to Mystery Guest. She can access in her normal role and no unique permissions are created. Phew!
Durian then shares document 5 with Kimberly B.
When he clicks “Share” the following things happen:
The Site owner receives the normal “someone wants to share” email, Durian gets a copy
An access request in Pending Requests appears. By default, the request is for Edit (not Contribute), as an individual. The Site Owner can not select one of the permissions groups, so has to give individual permissions. 😦
As soon as the Site owner selects a permissions set and hits Approve, the item has unique permissions.
Durian receives an email that the sharing request has been accepted.
Kimberley B receives an email that a document has been shared.
Kimberley B can share the document with only existing members or anyone, according to her permissions.
Sharing a site
Since Mystery Guest has found that Kimberley has no access, she shares the complete site with Kimberley. She is not a Site owner, so she can not select a permission set when she shares the site.
As soon as Mystery Guest clicks “Share”
Kimberley B receives an email.
She is added into the Members group (even without having accessed the site).
Durian has the same thought.
He shares the site with Kimberley B.
His request is sent to the Site Owner and an Access Request is created.
The Site Owner goes to the Access Requests list and selects the Visitors group of the site and clicks Approve. (Members is the default, btw)
A confirmation email is sent to Kimberley B and Durian.
Now Durian wants to share the site with another external person, who has never been invited before. He can not do that.
What to think of this?
It is complicated!
Although a number of things are understandable this can turn into a messy site:
Get a Link, Share and Access Requests can all very easily create unique permissions for documents (including pages), folders and list items.
Members can use Get a Link and Share, create unique permissions, and add new Members, without the Site owner knowing.
Visitors can do less and generally need approval from the Site owner; this is better for the Site owner’s overview, but can create a lot of work because of the approval requests.
External users can share your document with anyone, if they have Edit permissions.
Before you start panicking, please be aware that my tenant is almost out-of-the-box and all the sharing options are turned on by default. Tenant admins can take measures to reduce the unlimited sharing Microsoft thinks we need.
I will share those measures with you next time.
I have also found a few differences with regards to users who are mentioned in my tenant (with and without license) and who are not. When I have recovered from my current identity crisis, juggling 4 accounts and 3 browsers, I will try to find out more. 🙂
Image courtesy of marcolm at FreeDigitalPhotos.net
Some people call me “obsessed” with SharePoint permissions, and especially with breaking permission inheritance from the parent.
They are correct and I’ve got good reason (or so I think): the majority of issues and support questions have to do with non-standard permissions and people not fully understanding the consequences of creating unique permissions that they or their predecessors have done, knowingly or accidentally.
So while pondering my personal branding 🙂 I thought it might be better to embrace the options that Microsoft has created for us to share freely. After all, this thing is not called SharePoint for nothing! In Office365 everything is geared towards sharing content, without any considerations or warnings that many of these options create unique permissions, so who am I to worry, or go against that principle?
And what’s more, people who create unique permissions keep me in work! There’s nothing I like better than a complicated permissions puzzle, so if I want to stay away from boring discussions about columns that do not align 100% or the exact dimensions or rotation speed of carousels, why not make sure that I create some interesting work for myself?
So, let us make sure we all share content freely and without abandon!
In order to do that, I have collected these 7 principles for site owners.
1. Never give anyone “Read” access
This restricts the options for these people to share content. You will give them ugly words to share with (“Restricted Link”…ugh!), and they will need your approval. Come on, these are grown ups that know what they are doing! If they want to share a document, they must have a good reason. And you, as a site owner, have better things to do than approve or decline sharing requests.
Treat everyone the same and give them Contribute permissions at the very least. Who knows, they may have some great insights to add to your policy or project statement. Added April 27, 2017: And they may even help you design your homepage and other pages! Thank you for that addition, Helena! (See comments below)
2. Always use individual permissions
Well, you know there is this site group option of Owners, Members and Visitors, but who wants to be in a group, if the only thing joining you is having an interest in a document? Why bother puzzling out which group would be the best option for a person? You know it never fits 100% – this document is interesting to Stella, Eric and Tom, while the other document is interesting to Stella, Tom and Cindy. How can you make groups if every document has their own audience?
Surely your audience consist of all individuals, with individual needs. Using individual permissions will give you the most freedom to match each document with the people who really need it.
3. Break permissions inheritance freely
When in doubt, break! Or when your boss tells you so, of course. SharePoint has the option to allow access on a granular level, so why not make use of it and enjoy this to the fullest? You can pinpoint any document library, folder or even document or list item and give exactly the right individuals access.
4. Never use the “restricted link” option
Restricted…what an ugly word, it feels so….limited! Why would you want to impose restrictions? When you want to share content, select the “Can read” link to make sure that your intended audience can read it and not bother you with requests for access. Even better, use the “Can Edit” option. After all, your audience may have great ideas to share in that document. Policies and other controlled documents are a thing of the past, let’s crowdsource them all!
5. Immediatelyaccept any Access Request
Hit the “Accept” button and do it quickly, or you may lose a perfectly good reader or editor of the page or document you are sharing. Be ashamed of yourself that you have excluded someone from your content! Rejoice that they go to so much trouble to see it!
Only then, but only if you have the time, find out why and to which content this person wanted access.
6. Never review your permissions
You may be tempted to add Caroline, John and Marcia into a group if you see their name appear on every document, but who are you to decide they need to be grouped? As mentioned in paragraph 2, they are all unique individuals and throwing them into a group only because they read or edit the same documents does not do justice to their uniqueness. And the excuse of “groups are easier to manage for me” is a bit selfish, don’t you think?
7. Stop managing permissionsaltogether
This may be the best advice anyone can give you.
After all, is it not a bit conceited to say that “you own this content” or “you are managing this site”? The other people in the site know very well what they are doing, and they will take care of ensuring that this content is available to all the right people! Together you know who needs, or is interested in, your information. Over time, your content will gravitate towards exactly the correct audience.
To make sure that your unique permissions grow fast enough, you may want to enter in a competition with other site owners. It may well be that companies like ShareGate have a tool that can measure unique permissions. If they don’t, I suggest they develop one quickly.
Let me know how it goes!
Image courtesy of digitalart at FreeDigitalPhotos.net
What do you do when you receive a request for access to your SharePoint site? Accept it immediately (because you want to be done with it, or you feel a bit ashamed that you have excluded someone) or find out exactly what they want because there may be more to the request than meets the eye?
Yes, I thought so. 🙂
Let’s dig a bit deeper into Access Requests. There’s quite a lot you can do with them, including creating unique permissions. You know that I hate that!
Microsoft explains this in detail but of course they they let you figure out all the implications by yourself. Or by me :-).
If your email address is in the Access Request Settings, you will receive access requests via email, and the requests will be replicated in the Site settings > Access Requests and Invitations page.
How does it work?
When you get the access request in your mail, you will see the link to the desired content. You can immediately click the “Accept” button from the email and give them Contribute permissions by default.
Yes, Contribute. That means they can edit the content.
Hmmm, perhaps clicking Accept immediately is not such a good idea after all. Perhaps Read-permissions are good enough. Or, if you have sent this link assuming they had access, it may be a good idea to give them access to the complete site.
Alternative: the Access Requests and Invitations page!
So, here comes the Access Requests and Invitations page to look at (and manage) the request.
You will see three categories: Pending requests, External user invitations and History.
Here again, you can click Approve or Decline, or check first what will happen if you click Approve. So, click the … next to the name of the requester. This pop up opens:
Here you see some more info:
What Office365 has decided about their permissions. In this case Office365 would add them as an individual to this document with Contribute permissions – most unpleasant!
You can click the drop down to select the Contributors or Visitors group for the site.
Who has asked access and what exactly for. Hover over the link to see the URL.
Date and time of the request
Email conversation with the person who requests access. You see I was busy writing this post, so the impatient Mystery Guest asked for permissions again 🙂
What would have happened…
If I had clicked Accept from the email or Approve from the Access Request page, this is what would have happened:
Exception: Site welcome page
There is one exception to this rule and that is when you send the link to the welcome page of the site. In that case the requester is added by default to the Members group. This also may be more than you want, though.
After approval, the request ends up under “Show History”. This gives a nice overview of everything that has happened in your site.
If you see a name very often, it may be an idea to give them access to the whole site.
When you receive an Access Request it may be better to spend some time figuring out the details, than to click Accept immediately. This will cost you some time now, but will save you time fixing unique permissions later (and dealing with even more access requests because too many inheritances are broken!).
Have you found any other “interesting” behavior of the Access Request?
As I am writing help materials for our new intranet I do not only have to think about “HOW do you do this” but also “WHY would you do this” and “How can you do this BEST, without spending too much time, adding maintenance or messing things up?”
With the migration of content to the new platform, many Site Owners need to rework their publishing pages. Generally these pages contain (clickable) header images, Promoted Links, Summary Links and links in the text.
On the old platform, when you want to grab the link to a document or image, you go to the library, right click on the name and select “Copy Shortcut” from the pop up. This is no longer available in SharePoint Online.
So, how does one get a link in SharePoint Online?
I have found 3 ways to link to a document, page or image:
In Summary Links as well as the Rich Text Editor on a page (Wiki page style), you can browse for the link to a document or image that lives in your site or site collection.
You can open the item and grab the URL from the address bar.
There is the new Get a Link option, which you will see when you select a document or image from a library, in the Action Bar (is that what it’s called?) and the pop up menu.
The users in my company are all accustomed to grabbing a link when they want to share a document via email or on Yammer, so I think this “Get a Link” will appeal to them.
However, at first glance I see 5 different options. What to select?
Let’s find out how this works!
Microsoft has already written about this but it is not very detailed.
So, I have created a brand new site in my own tenant. In this site I have uploaded 5 documents, each named after the action I will take.
I assume the file type is irrelevant so I have used a mix of Excel, Word and PowerPoint.
Please note I am the tenant admin, so I am not a normal Site Owner. Some things may work differently for a regular Site Owner with Full Control.
My tenant is almost out-of-the-box and external and anonymous sharing has been enabled on all site collections.
How to use Get a Link:
Select the document and click “Get a Link”
Select one of the 5 options
Click “Create” (if the link has already been created earlier you will immediately see “copy”
Click “Copy” and the link will be added to your clipboard
Paste wherever you need it.
You can remove a link if you longer want to share. This means the link will be disabled if someone clicks on it.
For links with “no sign-in required” you can set an expiration date. This means the link will no longer work if someone clicks on it after the expiration date.
2. Using the “View” and “Edit” links will break permission inheritance for the document as soon as you hit “Create”.
Yes, you may want to read this again:
Using the “View” and “Edit” links will break permission inheritance for the document as soon as you hit “Create”.
I was a bit worried about the word “guest_access” that I saw appearing in 4 of the 5 links, so I decided to check the permissions of my site.
Microsoft mentions this in the small letters of their post, but it is easily overlooked.
4 of the 5 docs have broken permissions inheritance! The permissions have not changed yet, but the inheritance has broken. This may not appear to be a big deal now, but if you ever happen to add a new group or individual to your site, which is not unlikely, you will have to remember to give them access to these documents.
Do you seriously think any Site Owner will remember this? Or have the time for that?
More scary and inconvenient findings
As soon as someone clicks on a link they are added to the permissions of the document, regardless of their existing role in the site.
People in the Members group get all the options for “Get a Link” as well!
I have tested this in my work environment and it turns out Members can see and use the “view” and “edit” options so they can break the permission inheritance of documents without the Site Owner being aware!
You can only find out which links have been created by checking the options for each document. Click “remove” if you see that an unwanted link has already been created. Now go find out which of your links (In a text, in Summary Links etc.) used this link 😦
You can remove the link, but the permission inheritance is still broken.
You can only “delete unique permissions” per document, so you have to go to Site settings > Site permissions > Show items with different permissions > View Exceptions > Manage permissions > Delete unique permissions.
This is a tedious process.
I think this can turn into a serious issue. I have found that many Site Owners do not fully understand the consequences of broken permission inheritance, and do not understand the extra maintenance and support issues involved. I have tried to tell them NOT to break permission inheritance unless it is really needed, and to never do this on a document or item level.
And even if they know, it is a time-consuming job to reset the permissions.
Also, why all this complexity for just getting a link? I think only the “Restricted link” would be sufficient. Who would ever want to use the “edit” options when linking to an image? Why would you use the “Get a Link” option to share via email if there is also a “Share” option which sends an email? (and which, in some cases, asks permissions to the Site Owner first?)
What would I recommend if you need a link?
Use the “Insert > Link > From SharePoint” option to link to a document or image when working in the text editor of a page
Use the “Browse” option when creating Summary Links
Use “Get a Link > Restricted View” when you want to get a link otherwise. This respects the permissions of your library.
Instruct your site Members about the dangers of Get a Link and ask them to use the Restricted Link.
What are your experiences with the Get a Link functionality? Have you been able to reduce the scope and if yes, how? I would appreciate to hear and learn from you!
Kitten image courtesy of Top Photo Engineer at FreeDigitalPhotos.net. Text added by myself.