SharePoint Audiences are not Security!

In a nutshell… The SharePoint Audience feature is not security… ever. Audiences are used to filter (hide), not secure.

Some may consider the use of Audiences as “security by obscurity”, but it is not security.

From my SharePoint Security book…  (on Amazon – 2013/2016 version coming soon.)

Audiences

SharePoint audiences are used to target content to specific groups of people by hiding it from those who don’t need to see it. These groups can be SharePoint groups, Active Directory security groups, Active Directory distribution lists and SharePoint global audiences that are based on user profile data.

Audience targeting can be used with:

• List and library items, but only when displayed using a Content Query Web Part (part of the Publishing feature).
• Entire web parts.
• Top Link and Quick Launch navigation links. (when Publishing features are enabled)

Note: The Audiences feature is only available with SharePoint Server Standard and Enterprise editions. SharePoint Foundation has no support for Audiences. (Audiences is part of User Profile Services.)

Audiences are not security!

Audiences are usually described as being used to "target" content to a selected group. Audiences could also be described as being used to hide content from all users except for the target audiences. This second form sounds like security, but absolutely is not. While a list item or document web part might have a target audience, and non-audience members won't see the web part, if it is not otherwise secured they can still get to the item by using a direct URL or find it from search.

The Audience feature should be thought of as a filtering option, not security.

To filter list items using an Audience

List and library items can be filtered using the Audience feature using the Publishing feature’s Content Query Web Part. While the regular list web parts have an Audience feature, that feature hides the entire web part, not selected items. The Content Query Web Part is added to a site collection when you enable the Publishing features.

Four steps are required to filter list content using an Audience:

· Create a publishing site or enable the Publishing Infrastructure feature on a site collection.

· Enable the Audience feature on the list.

· “Tag” list items by Audience.

· Display the list using the Content Query Web Part.

Step 1: Enable the SharePoint Server Publishing Infrastructure Site Collection feature

First make sure there are no other reasons to not enable the Publishing features. (Policy, support, governance, etc.)

1. Go Settings (gear), Site Settings of the top level site of the site collection.

2. In the Site Collection Administration section click Site collection features.

3. If not already activated, activate the SharePoint Server Publishing Infrastructure feature.

Step 2: Enable the Audience feature on the list or library

1. Go the list or library, click the LIST or LIBRARY tab in the ribbon.

2. Click List Settings or Library Settings.

3. Click Audience targeting settings.

4. Checkmark Enable audience targeting.
A new field named Target Audiences will now be displayed in the New and Edit pages for the list.

5. Click OK.

Step 3: “Tag” list items by Audience

1. Edit the properties of a list or library item.

2. In the Audience area click the Browse button ( ) and select an Audience.

3. Save the changes to the item.

Step 4: Display the list using the Content Query Web Part

1. Move to your page where you want to display the web part.

2. Edit the page.

3. Click the Insert ribbon tab and the Web Part button.

4. Click on the Content Rollup category and then click the Content Query web part. (If the web part is not listed then you do not have the SharePoint Server Publishing Infrastructure site collection Feature enabled.)

5. Click Add to add the web part to the page.

6. Click the web part’s dropdown menu and click Edit Web Part.

7. Expand the Query section.

8. Select the Source (the scope) for the rollup from one of the following: Show items from all sites in this site collection, Show items from the following site and all subsites, or Show items from the following list.

9. Select the List Type and the Content Type to select the content to display from the Source selected above.

10. In the Audience Targeting section checkmark Apply audience filtering.

11. Optionally add filters or Presentation options.

12. Click OK to save your web part changes.

13. Save the page and test the results.

Note: the Target Audience option in the Advanced section of the web part’s property panel is used to control if the entire web part will be displayed for an audience.

Search Web Parts vs the CQWP

Microsoft currently recommends using the Search Web Parts in many of the places that we might have used the CQWP. While search uses cached content, and can be quite a bit faster, the data is only as current as the last search crawl. (I.e. Completed tasks may still display as incomplete.) The CQWP is always using live data and can be Audience filtered.

Resources for the CQWP:

Display data from multiple lists with the Content Query Web Part:
https://support.office.com/en-US/article/Display-a-dynamic-view-of-content-on-a-page-by-adding-the-Content-Query-Web-Part-3e35bd58-d159-43d6-bfc7-77878b4a856d (or just do a web search for “Display a dynamic view of content on a page by adding the Content Query Web Part”)

To show web parts for an Audience

You can use Audiences to hide an entire web part from all users except for the selected audiences. Simply edit the web part, expand the Advanced section and select an audience.

Note: The SharePoint Server Publishing Infrastructure Site Collection feature is not needed for web part Audience filtering.

To display a Quick Launch or Top Link Bar link for an Audience

Links in the Quick Launch and the Top Link Bar can be filtered by Audience when the Publishing Infrastructure feature has been activated. Once this feature has been activated the Quick Launch and Top Link Bar options are replaced with a single Site Settings option named Navigation. In the Navigation page Quick Launch is called Current Navigation and the Top Link Bar is called Global Navigation.

Enable the SharePoint Server Publishing Infrastructure Site Collection feature:

1. Go Settings (gear), Site Settings of the top level site of the site collection.

2. In the Site Collection Administration section click Site collection features.

3. If not already activated, activate the SharePoint Server Publishing Infrastructure feature.

To filter navigation links:

1. Go Settings (gear), Site Settings.

2. In the Look and Feel section click Navigation.

3. Scroll down to the Navigation Editing and Sorting section of the page.

4. Add or edit a Heading or a Link.

5. In the Audience area click the Browse button ( ) and select an Audience.

6. Set the Title, URL and other options as desired and click OK.

7. Test! The new navigation item should only be displayed for the selected Audiences.

SharePoint 2013 and SharePoint Online Built-In Accounts

 

I’m often chasing one SharePoint rabbit or another down a rabbit hole and spending hours there when I only wanted to ask the rabbit one simple question. In this case the question was who is “Everyone” and are they related to “NT AUTHORITY\Authenticated Users”. A simple question, or so I had thought. In this rabbit hole I found all kinds of interesting accounts, so I thought that I’d take a few notes while I was there. As to “Everyone”, I’ll follow up with another blog article. I also got distracted by two Office 365 users hanging around the hole named “Guest Contributor” and “Guest Reader” that will also get their own article.

If you would like to dive into the rabbit hole, here’s a few tools to investigate user accounts:

• PowerShell on prem: 
  $site = Get-SPSite http://yourDomain/sites/yourSite
  $site2.RootWeb.AllUsers | FT –AutoSize
• PowerShell for Office 365:
  Get-SPOUser -Site http://yourDomain/sites/yourSite | Select DisplayName, LoginName
• In the browser:
  • Go to Settings (gear), Site Settings, People and Groups
  • Edit the URL and change the GroupId to 0    (“?MembershipGroupId=0”)
  • Click any interesting user name. If the user has a User Profile you will probably be redirected to their profile page. If not, you will be redirected to userdisp.aspx where you can see the user name and their internal Account property as listed in the table below.
• Third party security and auditing tools.

 

Claims Based Authentication

SharePoint 2013 and later uses Claims Based Authentication which can support more than one authentication source. This slightly complicates the UserLogin property as it must have both the user name and the claims source data in the property value. In a non-Claims system the user name might be as simple as contoso\msmith. In a Claims system you need to know where the user was authenticated, so you end up with UserLogins that might look like i:0#.w|contoso\msmith for a Windows AD user or i:0#.f|ContosoFBA|susan for a Forms Based Authentication user.

If you would like to learn more about the Claims identity codes (“c:0!.s”, etc.) see: http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-claims-encoding-also-valuable-for-sharepoint-2010.aspx
and
http://www.wictorwilen.se/Post/How-Claims-encoding-works-in-SharePoint-2010.aspx

 

The Users

Who are all of these users? Well… I’m still negotiating with the rabbit for more details, but I’ll soon add these articles with what I have discovered:

• SharePoint: All Users vs. Everyone vs. Everyone But External vs. NT AUTHORITY\AUTHENTICATED USERS
• SharePoint Online “Guest Contributor” and “Guest Reader” - Who’s Guest Contributor,
  and what are they doing in my library?
• SharePoint internal and hidden accounts hiding in your Site Collection

For now:

• NT AUTHORITY\AUTHENTICATED USERS represents all of the users in your Active Directory, on prem or in the cloud.
• Everyone at the AD level is NT AUTHORITY\AUTHENTICATED USERS plus the Guest account. The Guest is disabled both by default and as a best practice. (You don’t see this one in SharePoint, but it is often listed as being the same as the SharePoint “Everyone”.)
• Everyone is defined at the SharePoint level and includes all users authenticated to SharePoint.
• Everyone except external users is found in SharePoint Online / Office 365 and is as named. External users are people not in your Active Directory, most likely not employees, who got their access from site members clicking the SHARE buttons.
• All Users (<somename>) is SharePoint defined and represents all of the users from a selected authentication provider. (If I created a Forms Based Authentication provider named “Vendors” then I would have “Everyone (Vendors)”
• All Users (windows) is SharePoint defined and is same as NT AUTHORITY\AUTHENTICATED USERS. After adding “All Users (windows)” to a site it is displayed as “All Users (windows)” in 2013 on prem and 2016 on prem, but is displayed as NT AUTHORITY\AUTHENTICATED USERS in Office 365.
• Guest Contributor and Guest Reader are at this time only found in SharePoint Online / Office 365 and represent users with anonymous / link access.

 

Best Practices

I was reviewing some training materials recently and ran across a statement to the effect you should put NT AUTHORITY\AUTHENTICATED USERS in all of your site Visitors groups so everyone can find content in SharePoint. Should you do this? Should everything in your SharePoint be freely accessible to everyone who can logon to your network? Contractors, vendors, summer co-ops, part timers? If you don’t already have a policy or governance on this, then you should be working on it.

SharePoint does not give us any way to prevent the use of the “Everyone” accounts, so you will need to deal with this through education and auditing.

UPDATE! Anders Rask responded to this post with info about a SharePoint Online cmdlet that can hide these “everyone” options in the people pickers. Turns out there are three options:

Set-SPOTenant -ShowEveryoneClaim $false
Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
Set-SPOTenant -ShowAllUsersClaim $false

The Set-SPOTenant cmdlet: https://technet.microsoft.com/en-us/library/fp161390.aspx 
Blog: https://blogs.office.com/2015/07/16/new-it-management-controls-added-to-onedrive-for-business/

 

Here’s a short list of best practices. The term “everyone” used here includes NT AUTHORITY\AUTHENTICATED USERS and any account that starts with “Everyone” or “All Users”.

• Educate your users on security, including the use of the “everyone” accounts.
• Do not use “everyone” accounts if a site contains non-public data.
• Document who “everyone” is. There’s more than one “everyone” group in SharePoint.
• Perform regular audits using PowerShell or 3rd party tools to track the usage of “everyone” groups.
• Document, audit and enforce your SharePoint content policies. Document what is allowed, and what is not allowed to be stored in SharePoint.
• If you do encourage the use of the “everyone” groups, add a banner to the top of every page that declares “Do not post confidential data in this SharePoint site! It can be seen by everyone with network access.”

 

The Built-In Accounts

While your SharePoint may vary… see the Notes column… here’s a list of the accounts that may include users other than those who you were expecting. This is not complete, so if you discover others please post a comment to this article.

DisplayName	UserLogin or SystemUserKeyProperty	Notes
All Users (membership)	c:0!.s|forms%3amembership	Only O365
All Users (windows)	c:0!.s|windows	Same as NT AUTHORITY\ authenticated users
All Users (yourFBAMembershipProviderName)	c:0!.s|forms%3aYourFBAMembershipProviderName	Form Based Authentication
Everyone	c:0(.s|true
Everyone except external users	c:0-.f|rolemanager|spo-grid-all-users/17b83262-5265-…	Only O365 (ID will vary)
NT AUTHORITY\ authenticated users	c:0!.s|windows
Guest Contributor	SHAREPOINT\writer_9e8a77849f89425c9cff6a6af5175…	ID varies with share
Guest Reader	SHAREPOINT\reader_cb6f6371456b4542ba0609638a4…
_SPOCacheFull	ylo001\_spocachefull	Only O365. Visible only from PowerShell
_SPOCacheRead	ylo001\_spocacheread	Only O365. Visible only from PowerShell
_spocrawler_17_3910	ylo001\_spocrawler_17_3910	Only O365 (ID will vary)
System Account	SHAREPOINT\system	Visible only from PowerShell
System Account	S-1-0-0	SystemUserKeyProperty
Company Administrator	s-1-5-21-1851826741-1401831065-3463747319-87287…	Only O365 (ID will vary)
Typical user (Sam Conklin)	samc@yourDomain.onmicrosoft.com	As seen in O365 PowerShell
Typical user (Sam Conklin)	i:0#.w|yourDomain\samc	As seen in On Prem PowerShell
Typical user (Sam Conklin)	i:0).w|s-1-5-21-2499188511-2905385804-3446143336-…	SystemUserKeyProperty
Typical FBA user (Susan)	i:0#.f|YourFBAMembershipProviderName|susan	Form Based Authentication

.

SharePoint: Undocumented Pending Shares Page

 

Article applies to SharePoint 2013, SharePoint Online and SharePoint 2016.

 

Did you ever wonder after using the Share buttons in SharePoint if the Site Owner ever responded to your request, responded with a question, or approved the request?

The My Permissions page

As I can’t find any documentation, I’ll call this undocumented for now… After a bit of web searching I did find a mention of the page in an Ignite presentation. In any case, this page lists the status of pending requests and lets the user who made the request check and send messages to the site owners. Requests that have been approved or declined will not be listed here.

The site owner can see your requests by going to Settings (gear), Site Settings, Site Permissions and clicking “Show access requests and invitations”. This will take them to the Access Requests page at _layouts/Access%20Requests/pendingreq.aspx.

You can check your pending requests by going to:
http://yourDomain/sites/yourSite/_layouts/mypermissions.aspx
This link will redirect to /_layouts/15 for now and may change in future versions.

Of course, no one knows about this page. There are no out of the box links to it. And… the site owner will probably not know to click the “SEND” button to start a conversation with the person who made the request.

If “Sharing” is important in your organization, you will need to provide some training, easy access to a link to the MyPermissions page, and do some work to “drive adoption”.

 

Details:

• Only “Pending” requests are displayed. Approved requests are not.
• You can click the “…” to see messages from the site owner, or to send a message to the site owner.
  
• This pending invites listed are unique to the current site. I.e. each site has its on MyPermissions page.

 

.

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.

 

 

.

SharePoint: Who can't you hide things from?

 

You just created a new subsite. You broke inheritance. You removed all of the inherited permissions. You gave only three people access.

Can anyone else see this site?

Yup…

• Your Site Collection Administrator.
• People granted Web Application level "super user" permission policies by the server administrators. These roles are often called "Auditors" and "Super Administrators".
• Server administrators who have granted themselves "super user" permissions.
• Any administrator using the farm service account. (Never a best practice.)
• Any one who your team members have "Shared" with!  (see below)
• The SQL Database Administrator. (we never directly query the tables… right?)

 

Site Collection Administrators

When a new Site Collection is created the server administrator can assign people to two roles named Primary Owner and Secondary Owner. These two users can see and change everything in site collection, unless some permission has been denied by Web Application level user policies.

These two Site Collection Administrators can add as many other people to the list of Site Collection Administrators as they like. Only the Primary and Secondary will receive site alert emails, all of these admins have Full Control over everything in the Site Collection. For more interesting things about these extra admins, see: http://techtrainingnotes.blogspot.com/2012/12/fun-and-games-with-site-collection.html.

 

Web Application Level "Super User" Permission Policies

Server administrators can define Web Application level policies and broadly give or remove permissions. These policies overrule anything done at the Site Collection or subsite levels. Here's a few examples:

• Remove the "Create Subsites" permission from all users.
• Remove the "Manage Lists" permission from everyone in the Active Directory Sales Managers group.
• Make a user an "Auditor" with rights to see everything in the entire Web Application. Yes, everything, including permissions and everything in the Site Settings page.
• Make a user a "Super Administrator" with the ability to change anything in the Site Collection, and even run in "stealth mode" with all changes listed as "by System Account".

 

Team Member Sharing – Members are security admins???

In SharePoint 2013 Online, users given the "Edit" permission level can share the site or anything in any list or library in the site where they have that permission level. All they have to do is click one of the many "Share" buttons or links. This one should really scare you! All they have to do is click the Share at the top of the page, and they have shared the entire site without site owner approval. If they click Share on a document or list item, then they have broken inheritance on that item, and then shared it!  The same user in SharePoint on-premises is only creating an "access request". See how to hide the share buttons here: http://techtrainingnotes.blogspot.com/2015/08/hiding-evil-sharepoint-2013-share.html

A bit odd, while the user with the "Edit" permission can "share" a full site or a single list item, then cannot share a list or library. If they guess the URL to "Permissions for this document library" they get "access denied".

SharePoint Online/Office 365 vs. On Premises:

	On Premises	Online
Member clicks the site level Share button	Creates an "access request" – site owner needs to approve	Adds new user to the Members group with usually has the Edit permission level
Member clicks the list or library item Share button	Creates an "access request" – site owner needs to approve. If approved, breaks inheritance and adds permissions for the new user.	Breaks inheritance and adds permissions for the new user.
Member guesses the URL to the People and Groups page…	Can only see the list of users in the groups.	Can remove users from groups!

So… Consider editing the "Edit" permission level and removing the "Manage Lists" permission!

 

 

 

.

You Cannot Test Your Own SharePoint Security

 

Test accounts are fun, but rarely a good thing.

As a typical site owner in a typical company, you are only issued one user account, one username/password. Having a "test account", especially a test account that is shared with multiple site owners is a bad practice, often prohibited, and sometimes grounds for termination. (In any case, your auditors will not like it.)

So why can't you test with your own account?

Consider creating a Permission Level that only allows Edit Items, but not Delete Items and especially not Full Control or Manage Permissions. To test with only your account you will need to grant yourself the Permission Level and then remove yourself from the Owners group. While you can do some testing… you can't make yourself an owner again! You just tested the car door locks by locking the keys inside.

Weird stuff if you do have a test account…
(and the auditors are looking for you!)

You create a list with custom permissions and add 50 items. You can see the 50 items with your account. When you log into the site with the test account you see 0 items. So far so good. Still using the test account, you click on Export to Excel… and you can see everything! Why? You are still logged into your PC as yourself, not the test user. Excel is running with your permissions when it makes the data connection back to SharePoint, not the test user's permissions.The test user's permissions are only being used in the browser. The same "dual accounts" problem applies to all other client side applications including Windows Explorer views.

By the way, this explains a lot of fun security issues when someone asks if they can use your PC to log into SharePoint to check something.

So…

(The following is borrowed from page 219 of my security book. Hint, hint )

As a Site Owner or Site Collection Administrator you have the rights to see everything in your site. To truly test SharePoint:

• You will need a partner who can do your tests.
• Before granting any permissions to the user ask them to visit the site, list or item and see if they can get any unexpected access.
• Grant your new custom permissions to the test user and let them see if they can exceed the permissions granted. I.e. can they delete stuff after you have removed the Delete Items permission?
• You will need a different computer or virtual machine.
• Switching between instances of the same browser brand can produce odd results due to the reuse of cookies or cached content. As a minimum you can use Internet Explorer’s “New Session” option or do your testing with two different brands of browsers.
• When logging in as a different user, and then performing any operation that uses a locally installed application such as Windows Explorer or Microsoft Office, you will be running the browser as your test user, but the local application will still be running as the account used to logon to your PC.
• The cleanest testing is done with a second computer where you have logged into the computer as the test account.
• · Delete the browser’s cache frequently to clear the cookies and temporary files.

 

 

.

SharePoint 2010 Limited Access Information Leaks

 

In a recent PowerShell SharePoint Auditing class we got side tracked on a discussion about security and the Limited Access Permission Level. I mentioned that even the names of lists and libraries can leak confidential information and that users with Limited Access permissions can often see these names. That led to a mandatory demo of the issue and a promise of a blog article with complete demo steps…

 

The Summer Co-Op said what?

You granted permissions to an innocent library like Sales Training Materials to a summer co-op. Later they ask you about plans to acquire a competitor. In a panic you check every document in that library for anything about the other company or about acquiring anything. You find nothing. You finally ask the co-op how they heard about that and they just answer "I saw it in SharePoint while looking for the training materials".

More fun security stuff!

How did they discover it? In the Quick Launch on the page for the training materials library there's a link named "Confidential: XYZ Acquisition Documents". How did they even get to see that? Limited Access.

Even worse… when they clicked the link they went to the library's page and there could the verbose description that was added by the person who created the list!

What about SharePoint 2013? 2013 has similar issues, but does hide the Quick Launch. I'll follow up with a 2013 specific article.

 

Demonstration:

Test setup:

• Create a new site collection. (just so everything is "clean")
• Go to Site Actions, Site Permissions, click Check Permissions and confirm that your test user currently has no access to the site.
• Create a new library or two so you have at least two for testing. Give them fun names like "Training Documents", "Top Secret", "Department Layoff Documents", and "Confidential Mergers and Acquisitions".

• Break inheritance on one of the more confidential libraries (Stop Inheriting Permissions button).
  • Remove all access except for the Owners group.

You now have a site with all content visible to your Owners, Members and Visitors groups… except for your test library, which only the Owners can see.

 

Test 1 – Grant a user access to the site

• Go to Site Actions, Site Permissions and click Grant Access
• Add your test user to the members group
• Open a browser and login as your test user.
  • Best ways to test (in order or preference):
    • Logon from a different computer as your test user.
    • Open a different brand of browser (Firefox, Chrome, etc.) using "Run as different user".
    • Open a different brand of browser. (Firefox, Chrome, etc.)
    • In Internet Explorer use File, New Session.
• Visit the site as the test user
  • In Quick Launch and All Site Content you should see all site content, except for the library where you broke inheritance. This user will not know that the secured library even exists. (This is probably what you expected with security trimming.)
  • If you copy and paste a URL that goes directly to the confidential library, or a file in the library, then you should get an Access Denied message.

Results:

• User can't discover the secured content.
  • Actually a good hacker can discover that the library exists. If they type or copy and paste the URL to a real library then they will get "Access Denied". They at least now know that the library exists. If they type a URL to a library that does not exist they will get a 404 Not Found error.
• Users using the REST web services (see later in this article) won't discover the secured lists.

 

Test 2 – Grant a user only access to a library with broken inheritance

• Remove any permissions granted in Test 1. Use Check Permissions to confirm that they do not have access to the site.
• Grant access to your test user to just the library  (don't add to one of the site groups!) Grant permissions to your test user and grant "Contribute".
  • Visit the library, click the Library ribbon, click Library Settings and click Permissions for this document library
  • Break Inheritance
  • Grant the Contribute Permission Level to your test user.
• Open a browser for your test user (see the info in Test 1) and paste in the the URL to the secured library. The user should be able to see the library and the library contents.
• Note the Quick Launch menu… All of the lists and libraries are visible!
• Click on any of the libraries listed in Quick Launch. The user will see the library's page, but no content. While the content is secure, the user now knows that the library exists. They can see both the list title and description.

Results:

• User can't discover the secured content., but the user can discover the names all of the lists and libraries in Quick Launch.
• The user will get Access Denied when accessing the home page.
• The user will see all custom links and content added directly to the master page.

 

Why?

Limited Access.

If you return to the browser where you are logged on as a Site Owner and visit the libraries you will see that the user with only access to a single library actually has the Limited Access permission level to all lists and libraries.

Why does Sam have Limited Access to this library? Sam was given "Limited Access" to the site when he was given Contribute to the library so he could see the master page and other resources needed to display the pages for the one library he was granted access to. All of the lists and libraries currently inherit their permissions from the site, therefore they inherit Sam's Limited Access permissions.

Side effects of granting permissions to a List, Library, Folder or Item, but not to the Site:

• User gets access to the List, Library, Folder or Item where they were directly granted permissions.
• User can see links to all lists and libraries in Quick Launch and other links. (I.e. no security trimming in Quick Launch.)
• User cannot see the content of the List, Library, Folder.
• User can hand enter a URL to any list or library and confirm that the item exists. (I.e. Gets to the list or library pages, but not to the items in the list or library.)
• User cannot visit the Site Content page. But that link is listed in their Quick Launch area and in their Site Actions. Clicking the link will display Access Denied.
• User cannot visit any page stored in the Site Pages library. Your home page is Site Pages.
• Your site icon may not display properly as they are often stored in Site Assets or other library. The same is true for any image, CSS or JavaScript stored in libraries.

 

 

What about all of the other lists not in Quick Launch?

Are they discoverable by the Limited Access user? Yes, if they can Google or Bing! SharePoint 2010 has a RESTful web service that exposes lists. While this is security trimmed, the user in the above scenarios has access to the list's name through the inherited Limited Access permissions. I.e. this is not a bug with Quick Launch, it's a "feature" of Limited Access! Here's what the user will discover from a web search:

         http://yourserver/sites/yoursite/_vti_bin/ListData.svc

That link will display via XML the list of lists and libraries!

SharePoint 2013 includes the above REST service plus a more generalized version.

         https://yourserver/sites/yoursite/_api/web/lists

 

The Fix?

To prevent the accidental discovery of other lists and libraries when using unique permissions on a single list or library you will need to break inheritance on every list and library and grant the appropriate access.

You will need to:

• Break inheritance on all content lists and libraries and grant access to the appropriate groups and users. If you do this after you have granted unique permissions to a user, you will need to remove the Limited Access users from each list and library.
• Grant View access to everyone to the Site Access library (or where ever you store site logos, CSS and other support files) so your icons and custom branding will display correctly. "Everyone" could be a group unique to your site or department or "NT AUTHORITY\Authenticated Users" for everyone who can logon to your networks. Granting access in anyway to "NT AUTHORITY\Authenticated Users" is not generally a good practice!

 

There's no end to learning SharePoint!

 

.

Merging Two PowerShell Collections into One Output

 

In SharePoint users and groups are both security principles, and both share some common properties. One property, ID, is interesting as it is unique and never duplicated between the lists of users and group. I.e. if there is a user with an ID of 5 then there is never a group with an ID of 5.

In PowerShell there are two separate properties for users and groups, but I wanted to merge the two into one sorted list. Turns out, as long as both Select statements return columns with the same names, then they can be "added" to get a merged result.

 

Example: Users and Groups

$users = $web.SiteUsers | Select Id, Name
$groups = $web.Groups | Select Id, Name
$users + $groups | Sort Id

If you wanted to do it all in one line, then use a few parentheses:

($web.SiteUsers | Select Id, Name)  +  ($web.Groups | Select Id, Name) | Sort Id

What if the column names don't match (but have similar data types)? You will need to create a PowerShell custom column. In the example below I wanted to use the user's DisplayName property instead of the Name property so I had to create a custom column named "Name" to match the "Name" property in the groups Select.

$users = $web.SiteUsers | Select Id, @{Label="Name"; Expression={$_.DisplayName|}}

$groups = $web.Groups | Select Id, Name

$users + $groups | Sort Id

 

.

SharePoint User Policy, Super Users and Auditors

 

I ran across a question in the TechNet forums today that revolved around confusion about the purpose of the Site Collection Permissions section in the Permission Policy dialog box in Central Administration. In Central Administration, in the Web Application Management section, there are two ribbon buttons that let you define web application scoped permissions: Permission Policy and User Policy. These are typically used to deny something from everyone or grant something to a few special users. These always win over any permissions changes done by a Site Owner.

Creating a Super User

A super user might be an auditor who needs read-only access to everything in a web application, or a super administrator who needs Site Collection Administrator permissions to everything in a web application.

Steps:

1. Go to Central Administration, click Application Management and Manage Web Applications.
2. Click in the line (but not on the hyperlink) for the web application to change. This wakes up the ribbon.
3. Click Permission Policy.
4. Click Add Permission Policy Level

Here's where it gets a little confusing… there's two ways of creating a policy, check each individual Grant or Deny, or click one of the two shortcuts: "Site Collection Administrator" or "Site Collection Auditor". Is it clear from the descriptions below that these are shortcuts, right?

It's even more confusing when you check one of these two options and then click Save:

There's a bug! The Save button has some validation JavaScript that is checking to see that at least one checkbox has been selected. The fix? Select a checkbox. I click "Open" in the Grant column because that is the minimum permission needed to open a site. Now you can click Save.

 

If you check Site Collection Auditor…

The "Site Collection Auditor" shortcut checkbox grants these permissions to the user:

View Web Analytics Data
Browse Directories
View Items
View Pages
Enumerate Permissions
Open Items
View Versions
Browse User Information
View Application Pages
Use Remote Interfaces
Open

Actually clicking Save will grant the above permissions when "Site Collection Auditor" has been checked, and include any other Grants or Denys you have clicked. (Deny always wins over Grant!)

 

If you check Site Collection Administrator…

The "Site Collection Administrator" shortcut checkbox grants all 33 permissions to the user, minus any Denys you have checked. (Deny always wins over a Grant!)

Manage Permissions View Web Analytics Data Create Subsites Manage Web Site Add and Customize Pages Manage Lists Apply Themes and Borders Apply Style Sheets Override Check Out Manage Personal Views Add/Remove Personal Web Parts Update Personal Web Parts Add Items Edit Items Delete Items Create Groups Browse Directories

View Items Use Self-Service Site Creation View Pages Approve Items Enumerate Permissions Open Items View Versions Delete Versions Browse User Information Create Alerts Manage Alerts View Application Pages Use Remote Interfaces Use Client Integration Features Open Edit Personal User Information

All of the above would have been a lot clearer if when you clicked on of the "shortcuts" the page automatically checked all of the related permissions.

 

Testing

1. Create a user, such as domain\allieauditor (or ask a coworker to help).
2. Go to a site collection and click Site Actions, Site Permissions.
3. Click the Check Permissions button in the ribbon and click Allie's permissions. You should see "none".
   
4. Go to Central Administration and add a Permission Policy.
1. Name it "Corp Auditor".
2. Check "Site Collection Auditor".
3. also check one other permission such as "Open" to make the Save button happy.
5. In User Policy:
1. Click Add Users
2. Click Next
3. Add domain\allieauditor and check "Corp Auditor"
4. Click Finish
6. Go the test site click Check Permissions and check Allie's permissions.
   The following are displayed (all "read" type permissions) for Allie:
     View Web Analytics Data
     Browse Directories
     View Items
     View Pages
     Enumerate Permissions
     Open Items
     View Versions
     Browse User Information
     View Application Pages
     Use Remote Interfaces
     Open
7. Go back to User Policy and remove Allie as "Corp Auditor"
8. In the test site check her permissions: None
9. Create a new policy
1. Name it "Super Administrator".
2. Check "Site Collection Administrator".
3. Also check one other permission such as "Open" to make the Save button happy.
4. Click Save.
10. Return to the test site and check Allie's permissions. She now has all 33 permissions.

 

Tip… Is a user a "normal" user or a "super user"?

When you use Check Permissions and you see a permission level, then you have found a "normal" user who was granted permissions by the Site Owner. As you can see below, Sam has the Contribute permission level.

If you see all 33 permissions, then you have either found a Site Collection Administrator or a "super user" created by the server administrator. Stella is a Site Collection administrator, but could also be a "super administrator" created though User Policies.

If you see any "Allow" or "Deny" entries, then you have found a user who has been granted or denied permissions using Central Admin's User Policy button. In the example below Sam is a Full Control site owner, except… he has been denied Create Subsites in User Policies. (Deny always beats Grant!)

.