Trick or Treat? A Day in the Life of the SharePoint Share Button…

 

Every once and a while I work a little on my next book, SharePoint 2103 Security. At the pace I'm going it may never get done. As I'm always a bit surprised at the response and disbelief I get when I tell people about the Share button, I added a chapter to the book about the Share buttons, what they do and what you can do about them. As the book may never get done… I'll click a "share" button and share part of it with you. 

 

Is the Share Button Evil? 

So how about a little demo. One of my users, Sam, thinks Susan would be interested in one of our purchase orders. Here’s a walkthrough of what Sam, Susan, a few other strangers, and the Site Owner might see.

 

Mike adds a team member to the new site

Mike, the Site Owner of a new site, adds Sam to the members group.

1. Mike goes to Settings (gear), Site Settings, Site Permissions.
   
2. There he notes that this site has unique permissions, i.e., does not inherit permissions from the parent site, and that users currently only have access to the site through group membership. He also notes the “different permissions” message and checks it to see that it only applies to the MicroFeed.
    
3. Mike adds Sam to the Team Subsite Members group. Note that the group has the default “Edit” permission level. (Sam can add, edit and delete documents, and customize and delete the entire library!)
   

 

Along comes Sam…

Sam is browsing the Purchase Orders library and thinks Susan would be interested in one of the Purchase Orders.

1. Sam checkmarks one of the purchase orders and clicks one of the Share buttons. (Share buttons are above the library, in the ribbon and in the “…” menus.)
    
2. Susan receives an email with a link to the document. Sam got copied on the email, but the Site Owner did not.
   

 

Susan gets an email…

Susan receives the email and out of curiosity…

1. Susan clicks the link in the email… the document opens in Office Word Apps (now called Office Online). If the document is not supported by Office Web Apps or the browser then Susan will get a blank page with a download prompt.
    
2. Susan sees the “Share” button! She clicks it and shares the file with a coworker!
   

 

And then there's Stella…

1. Stella clicks the link, and not knowing about the auto-save features of Office Web Apps, makes a fun edit.
    
2. Not knowing about the “comments thing” she adds a couple little test comments.
   
    
3. Stella thinks this is kind of fun and clicks the Share button…………
    
4. Later she sees the site name (“Team Subsite” in this demo) and clicks the link.
    
   As she has "Limited Access" to the site she can see the library page, and there only the document that was shared with her. While she cannot see Quick Launch or the Top Link bar, she can see other custom text and links that you may have added to the site's master page. She may also see that you have changed your site logo to a picture of your new top secret product.

 

Bad day for Mike!

1. The next day Mike gets a phone call from the team member who created the purchase order asking “Who is Stella” and why is she making changes to my purchase orders? I thought you only granted access to this site to our team? Oh, and I’m going to talk to HR about some of the comments she added!”
        
2. Mike starts doing detective work…
   1. The file has been modified. (“Gee I wish I had turned on versioning!” he says.)
   2. He checkmarks the purchase order, clicks the Share button (one of several ways to do this) and clicks Shared With, and sees “there’s a lot of sharing going on!”
          
   3. He notes that Sam is on the team, but has no idea who Stella or Susan are. Hoping to find who shared this file with these people, he clicks ADVANCED.
           
   4. But, there’s nothing there that he hadn’t already seen.
       
   5. He clicks Check Permissions, enters Stella's name and only learns that she has Limited Access. This only lets him know that she has special permissions set on some object in the site… could be one item or hundreds… and there's nothing out of the box that will list them all in one step.
           
   6. Sam goes to Settings, Site Settings, Site Permissions to see if there anything to be learned there.
          
   7. Clicking Show users he again finds that Stella and Susan have Limited Access permissions to the site.
           
   8. Clicking Show these items he finds he has a dozen libraries with hundreds of “shared” files, all with broken inheritance.
       
   9. Mike thinks about finding another job…
       
3. A few days later Mike creates a new group called Managers and adds three people to the group. Later one of those people call Mike about a missing purchase order. “Hey Mike, I can see PO’s 12345, 12346, 12348, 12349, but not 12347. Did we skip a number?”
   1. With broken inheritance Mike has to remember to grant access to all broken inheritance files whenever adding new groups.
       
4. Mike gives up, resets all of the broken inheritance (hours of work) and turns off the ability for team members to share:
      
   He did leave “Allow access requests” for those special situations.
    
5. If he unchecks all of the Access Request options then the Share buttons are still displayed to tempt the users, but when they click the buttons they will get this popup:
      
   
   You may just want to hide those Share buttons! Take a look at this article: http://techtrainingnotes.blogspot.com/2015/08/hiding-evil-sharepoint-2013-share.html

 

And did you know…

Visitors can share! But at least it’s not automatic. When they click Share and complete the form a Sharing Request is sent to the site owner (actually the name listed in the Access Request Settings dialog box). And there’s a surprise… the new user by default gets Edit Permission Level access to the document!

The flow:

1. Visitor user checkmarks a file, clicks Share and share the file.
2. A popup is displayed:
        
3. The site owner gets an email,
   
   and if they go to Settings, Site Settings, Site Permissions they will see:
        
4. If the site owner clicks the link in the email and approves, the user gets the Edit Permission level. If the site owner goes to Site Permissions and click the link there, they can click “…” and pick a permission.
   

 

Takeaways…

1. Sharing a file is easy!
    
2. By default, team members can share any file.
    
3. Visitors can even generate Share Requests that could result in someone else getting “Edit” permissions on the document.
    
4. Sharing breaks inheritance and complicates future site maintenance.
    
5. There is no audit trail. No “who done it” report.
    
6. There are no built-in tools or reports to list everything a user has access to. (Third party tools and/or PowerShell to the rescue!)
    
7. It can be turned off. The buttons can even be hidden with a customization.
    
8. Having items with broken inheritance will create a lot of additional work for site owners and auditors.

 

.

Oh, and if you can't wait for the book…

Buy the 2010 book. A good 98% of it still applies to 2013. The only big things missing are the Edit Permission Level, the Share buttons and App permissions.

 

 

.