Essential SharePoint 2013: Practical Guidance for Meaningful Business Results (2014)
Part I. Planning
Chapter 12. Planning Security
Planning security for your solution is about balancing and optimizing the various security elements for all of the people who will use the solution, including content contributors, content users, and administrators who manage and maintain security groups. It also involves defining a model that works for the current business requirements but is also defined well enough to grow and be altered as requirements and content change. Planning security is also about deciding how you will “put the ‘share’ in SharePoint.” Especially for SharePoint 2013, where there are new and simplified options for sharing content, planning security involves deciding what content will be closed off all the time, but also what content will be closed off some of the time or to some users.
There is no single best way to design security and manage security groups. Each business scenario is different. Because the risks associated with getting your security model wrong are pretty big—three main issues come to mind: (1) not allowing required access, (2) allowing inappropriate access, and (3) not understanding where permissions have been broken or applied to individuals instead of groups so that granting permissions in one place does not result in the access you expect—we often find ourselves suggesting that planning security should come with the same kind of warning you see on television shows with crazy stunts: “Don’t try this at home.” In other words, if this is the first time you are implementing security for SharePoint, try to get support from someone who has in-depth knowledge of SharePoint security best practices.
In this chapter, we share as many of these best practices as we can, but it’s really important to remember that almost every planning decision has to be carefully considered from multiple perspectives to arrive at the best solution for the situation. If you delegate design privileges for sites or site collections within your solution, you need to remember that it’s not enough to train “site designers” in information architecture best practices; they must also understand how SharePoint security works and best practices for both creating and maintaining a security model or plan. In one organization, users are not given new sites or site collections until they prepare and document a security plan for their sites that can be reviewed with a senior-level solution architect. This approach is one that might be worth emulating because it ensures that a “solution analyst” working with an experienced information architect or security specialist collectively defines the security model for the site or solution. In another organization, site administrators are required to attend internal training to ensure that they understand both SharePoint site administration and specifically security best practices before they can assume full control of a SharePoint site.
One of the challenges that continues to be true for SharePoint 2013 is that it is not easy to figure out who has what privileges across your entire SharePoint environment. It is also not easy to replicate security permissions—for example, to hire a new employee into the role of a former employee and easily assign the same access privileges. In a small environment with only a couple of site collections, these actions will not be too time-consuming. However, these relatively typical transactions will be really, really difficult in large, complex environments. For this reason, most large organizations use one of the excellent third-party security management tools (such as those from AvePoint, Axceler, or Dell) to help manage and govern their SharePoint environments. Whether you are just beginning or are well into your SharePoint journey, it is worth considering this type of investment.
The discussion of security planning in this chapter is focused on the perspective of the business owner of the solution or site. Some of the implementation tasks may require support from your technical solution administrator, but ultimately, planning security is a business responsibility. This may seem like an overwhelming task for nontechnical resources who perceive security management as something IT has always owned. It’s not. While IT may own the implementation of security requirements, security decisions are the responsibility of the business. Very much like a shared folder, security management in SharePoint is about determining who should and should not have access to various types of content. However, unlike your file share resources where security is generally only managed by IT and external users generally cannot access them, business users can have a lot more access to implementing security permissions in SharePoint, and external users can also “get in” pretty easily (at least in Office 365/SharePoint Online),1 depending on how you manage your implementation. The new capability of SharePoint 2013 to more easily share content with anyone, even external users, creates a risk area that must be clearly understood—and governed, as we discussed in Chapter 4, “Planning for Business Governance.” Thus, business users have a critical need to understand how security in SharePoint works.
1. There are some security differences between SharePoint 2013 on-premises and Office 365/SharePoint 2013 Online. In this chapter, when we refer to SharePoint 2013, we mean both online and on-premises. When a capability is available only in Office 365/SharePoint Online, we will explicitly call that out. We use the term SharePoint Online to refer to SharePoint 2013 Online or an Office 365 plan that includes SharePoint Online.
What’s New In SharePoint 2013?
In general, security relationships in SharePoint 2013 work very much the same as they did in SharePoint 2010. Permissions are inherited from the root site unless you intentionally “break” them. Security can be managed down to the individual document or “item” level, though this is still not a recommended practice as we explain later in this chapter. However, SharePoint 2013 makes breaking permissions (and sharing content) easier, and because it is now so easy to do, it’s also very easy to make mistakes and accidentally share content that you don’t want to share. For this reason, you will want to be very, very intentional about what you allow users to do, especially when it comes to sharing content outside the organization.
Even if you are very familiar with how security works in previous versions of SharePoint, you will want to make sure you understand some of the new security capabilities in SharePoint 2013:
Simplified sharing of documents with both internal and external users. From a business user perspective, the most significant change with SharePoint 2013 is that it is now very easy for individuals to give access to sites, lists, or documents to both internal and external users—but only in Office 365/SharePoint Online. Office 365/SharePoint Online environments and site collections can optionally be enabled for external sharing, but this capability is not available in SharePoint 2013 on-premises.
In previous versions of SharePoint, you could not “manage permissions” on an item unless your permission set included the Manage Permissions feature. This was typically available only to Full Control users. However, in SharePoint 2013 Online, any user of your site has access to the new Share option. (Figure 12-1 shows the Share option for a document, and Figure 12-2 shows the Share option for a site.) The Share option allows that user to create a request to share the site, list, or document with someone who does not otherwise have access.
Figure 12-1 Share option for a document in SharePoint 2013
Figure 12-2 Share option for a site in SharePoint 2013
Users who do not have the ability to manage permissions do not actually get to share anything without approval, even though they have access to the Share option. All requests to share are sent to the site owner, who then can approve or deny them. Unfortunately, it won’t be obvious to your users that they aren’t really sharing, so you will need to explain this during training. (When a visitor or member of a SharePoint site initiates a sharing request, a pop-up displays that lets them know that the request has been sent to the site owner. However, the pop-up does not display for very long, so it might be missed by busy users.)
The ability to share documents and sites is different in the online and on-premises versions of SharePoint 2013. Table 12-1 summarizes the user experiences for sharing documents and sites in both types of SharePoint 2013 environments.
Table 12-1 User Experience for Sharing Documents and Sites in SharePoint 2013 On-Premises and Online
Note
In SharePoint 2013 on-premises, there is a confusing user experience with the ability to “share” documents for visitors and members unless you have set up outgoing e-mail on your farm and enabled access requests for your site. While the Share option is not available in the document ribbon for visitors and members, it is visible from the list item dialog as shown in Figure 12-13. Clicking the Share option in this scenario without access requests and e-mail enabled returns an error message: “Sorry, something went wrong. Only a limited set of people are allowed to share this content.” This is actually by design, though the error message is a little confusing. Nothing really went wrong; the user just doesn’t have permission to share a document if the site doesn’t have “Allow access requests” turned on. This capability is enabled in Site Settings β Site permissions, and when enabled, it allows visitors and members to initiate an internal document-sharing request that goes to the site owner. In SharePoint Online, visitors and members can initiate a sharing request for a document in both the ribbon and in the item dialog, but all of the requests go to the site owner for approval.
New default access groups. There are two special new Domain Groups in SharePoint 2013. The Everyone group is the new name for “All authenticated users.” It is available in SharePoint on-premises as well as SharePoint Online. It maps to “all authenticated users in the tenancy, including external users” in SharePoint Online. The Everyone except external users group is available only in SharePoint Online. This group includes all of your authenticated users plus anyone invited with a “guest” user account. In SkyDrive Pro, the default access for the Shared with Everyone folder in SharePoint 2013 on-premises is Everyone. In SharePoint Online, the default access for the Shared with Everyone folder is Everyone except external users.
Ability to share externally with or without authentication required. In SharePoint Online, you have the option of sharing content with external users. When you share a document with external users, you can require that they authenticate with a free Microsoft account or without any authentication. (The ability to do this is controlled globally and at the site collection level by the administrator.) When you share an individual document, you can also specify whether access is read-only or whether the external user can edit the document. If you do not require authentication and you allow a guest user to edit a document, the Modified By user shows up as Guest Contributor. If you require authentication, which means your external user will have to sign in with an existing Microsoft account, you will see the username associated with the Microsoft account in the Modified By field. As a best practice, it is always a good idea to require authentication if you are allowing an external user to edit a document.
Easily exchange information with users requesting access to sites. As in previous versions, site owners can use the “Site permissions” setting in Site Settings to enable access requests for a specific SharePoint site. The setting allows you to enter the e-mail address of the user who will receive access requests. When unauthorized users try to access a site for which access requests have been enabled, they get a dialog box where they can respond to the new “Let us know why you need access to this site” prompt. The completed access request is then visible to the site owner in a new area of Site Settings called “Access requests and invitations.” By opening the individual access request menu, the site owner can decide whether to approve or decline access to the site. If access is declined, the requester sees a “Sorry, your request has been declined” message the next time he or she tries to access the site along with a dialog box in which to provide supplementary information to ask the site owner to reconsider.
New Community Site template with special security features. The new Community Site template (see Chapter 15, “Planning for Social Computing”) provides an engaging concept for encouraging topic-focused discussions but also introduces some unique security concepts that site owners may find confusing. It is especially important to use the out-of-the-box security groups created with new community sites and to set up each new community site with unique permissions. Special security considerations for community sites are discussed later in this chapter.
New authentication options. SharePoint 2013 offers claims-based authentication using the Open Authorization 2.0 (OAuth) model. OAuth is an industry-standard security protocol that allows SharePoint to give applications access to SharePoint resources such as sites and lists without the app having to obtain, store, or submit the users’ credentials. This allows apps and services to act on behalf of users for limited access to SharePoint resources. For example, an application may be allowed to read or write to a calendar or newsfeed on SharePoint. The new SharePoint apps model functions very similarly to what consumers may be used to on Facebook and how Facebook applications, such as Farmville, are authorized to post messages on behalf of users after they have authorized it to do so.
Planning How Users Will Access SharePoint
The first security decisions you will make about your SharePoint implementation relate to user access. You will need to decide if you will allow people to access SharePoint from outside of your corporate network and, if so, from which devices. You will also want to determine if people outside of your organization will need access.
Historically, many organizations started by using SharePoint on-premises and set up the SharePoint servers on their internal network behind a firewall that prevented people from accessing SharePoint externally. In this scenario, people could access SharePoint only when they were in the office using a computer issued by the organization and connected to the organization’s internal network.
As people have become more mobile, many organizations have set up external access to their internal SharePoint server environments using a VPN or methods such as Microsoft’s Direct Access technologies. These enable individuals to connect remotely to the corporate network from a company-supported computer.
As SharePoint use has expanded to secure extranets, or even public-facing Web sites, organizations have been setting up SharePoint environments outside of their corporate networks to enable people outside of their organizations to access SharePoint without having to open up their networks too widely.
Setting up SharePoint externally to your organization offers the ability for people to access your SharePoint environment from their mobile devices (such as a phone or tablet device) and to use their own personal computer equipment from any location, something that has become more prevalent with the BYOD trend that many organizations have been supporting.
SharePoint Online (as part of Office 365) offers additional capabilities to securely support access to your SharePoint environment from any environment, from any device, and adds some new capabilities that are not available via SharePoint 2013 on-premises, including the new external sharing capabilities that are described in this chapter.
Planning How You Will Share
One of the reasons most organizations implement SharePoint is that they want to be able to improve and facilitate the way they manage and share content. “Versionitis,” the insidious disease that results in documents being replicated all over the organization’s file shares in different states or versions, has a potential cure with SharePoint. So clearly, we want to share with SharePoint—sometimes. From a knowledge management perspective, the organizational goal is generally to allow Read access to internal content by default, unless there is a regulatory or business reason to secure it. As you are planning SharePoint security, you may want to challenge some of the existing security models for your file shares and see if the files are secured because they need to be or because they always have been historically even though no one can remember why. Use the implementation of or upgrade to SharePoint 2013 to revisit security on your file shares and existing SharePoint sites and to make sure that you are protecting content that needs to be protected but allowing content that could benefit the organization, by preventing “versionitis” and promoting reuse, to be discovered. That said, you will still need to think about how to allow sharing of content and make sure that your site owners understand their responsibilities when it comes to content security.
You Can’t Prevent Internal Sharing by Site Owners—You Can Only Educate Site Owners about the Implications
While your administrator can prevent users from sharing content with external users with a setting at the environment or site collection level (in SharePoint Online), you cannot prevent site owners from sharing content internally. You need to make sure your training and governance plans ensure that site owners understand the responsibility with which they have been entrusted. This is not different from previous versions of SharePoint, but because the ability to share content is more “exposed” in SharePoint 2013, the risk of making security mistakes is increased.
Planning How You Will Share Internally
With earlier versions of SharePoint, only site owners (users with Full Control2 permissions) had the ability to manage security on the site or on any content within a site. In SharePoint 2013 Online, all users have access to the Share option (refer to Figures 12-1 and 12-2) to request that a site or document be shared with an internal user, but only the site owner can approve these requests. In SharePoint 2013 on-premises, the user experience for sharing is different. These differences are summarized in Table 12-1.
2. Any user with the Manage Permissions permission level can manage permissions on content. By default, however, Manage Permissions is included only in the Full Control and Manage Hierarchy permission sets.
Sharing Documents Internally
Users with the ability to share can click the Share option for each of the documents they want to share and enter the name or e-mail address of any internal user with whom they wish to share the item. Figure 12-3 shows an example of the view that users other than the site owner see when they click the Share option for a document from the document “callout” box in a document library. To see the “callout” box, click the ellipsis (...) to the right of the document name (refer to Figure 12-1). As shown in Figure 12-3, the document is already shared with Scott Jamison. To invite additional internal users to see a document, all you need to do is start typing the name or e-mail address and the users that match the typed characters will be displayed so you can select the appropriate name. If you are not the site owner, the invitation to the guest user doesn’t actually go to the user. Instead, when someone other than the site owner initiates the Share action, a request is sent to the site owner, who then has the ability to approve, decline, or engage in a dialog with the requester to discuss why the request has been made and then decide the permissions the new user will get (Read, Contribute, etc.).
Figure 12-3 Sharing options for an individual document—visitor or member view
When a site owner initiates the Share action, the view shows the permission selection option directly, since the site owner does not need to request approval to share content. The site owner view for sharing a document is shown in Figure 12-4.
Figure 12-4 Sharing options for an individual document—site owner view
Sharing Sites Internally
Sharing a site works very much the same way as sharing a document. The best way to share a site is by clicking the Share option in the upper right-hand corner of the site (see Figure 12-2), but site owners can also grant permissions from Site Settings → Users and Permissions → Site permissions. When users other than the site owner in SharePoint Online want to share a site (remember, the Share option for sites is not visible to users with Visitor and Member permissions in SharePoint 2013 on-premises), they see the share request screen shown in Figure 12-5. The share request is submitted to the site owner, who can determine the level of access to grant the new user. When site owners share a site, they see a view that allows them to specify the type of permissions the new internal user should have, as shown in Figure 12-6.
Figure 12-5 Share request options for a site—visitor and member view in SharePoint Online
Figure 12-6 Share request options for a site—site owner view
You don’t have the ability to restrict sharing internally within your SharePoint environment, so planning how you will share internally is largely a training and governance exercise. Think about it this way: Sharing is generally a good thing when you need to share. Being able to easily invite a specific person from outside your team to edit a single document without editing your other documents is a really helpful feature. However, you should consider the following:
Introducing unique permissions on individual documents introduces a security risk and adds complexity to your environment. If you invite someone to collaborate on a document, you may want to remove those permissions when the editing process is complete.
Think about the implications of allowing anyone to invite others to edit content. You will introduce some risk in situations where a busy site owner might inadvertently approve access requests that shouldn’t be approved. Another risk is that someone will share the entire site when they mean to share only one document.
Our best advice is to make sure your site owners understand that “with great power comes great responsibility.” Simplified content sharing will definitely enhance many collaboration scenarios—but this new capability is not without risk, and you should take the time to consider the implications when you grant site owner privileges.
Planning How You Will Share Externally
If your teams do work that involves collaborating with external partners, SharePoint Online provides the capability to easily invite external users to access sites or documents. There are three scenarios that you can enable:
You can share an entire site by inviting external users to sign in to your site using any e-mail address, and then Office 365 will require the person receiving the invitation to associate with an existing Microsoft account (for example, a Hotmail or Outlook address) or a Microsoft Office 365 user ID.
You can share individual documents by inviting external users to sign in to your site using a Microsoft account or a Microsoft Office 365 user ID.
You can send users a guest link that they can use to view or edit individual documents on your site anonymously.
Setting up your SharePoint Online site to allow external sharing depends on the version of SharePoint Online that your organization uses. Since inviting external users into your site introduces a security risk, you should carefully consider the implications of external sharing and make sure that the site owners and administrators who can authorize these permissions have sufficient training and time to properly administer external users. External sharing is turned on by default no matter which version of SharePoint Online your organization is using. You should consider turning it off globally before anyone starts using sites or until you know exactly how you want to use and support this feature. No matter which version of SharePoint Online you are using, only users with Full Control privileges are allowed to share sites or items with external users initially. Once these users are “in the system,” their user IDs are available in the People Picker for any site user to select. However, sharing requests for external users are always routed to the site owner for approval before access is granted.
If your organization is using Office 365 Small Business Premium, the Office 365 administrator is the only person who can enable or disable the external sharing feature for all sites. When this feature is deactivated, any external user previously invited to sites can no longer access the sites. To enable or disable external sharing, go to Admin → Service Settings → Sites and Document Sharing. You can also use this same location to remove individual external users.
If your organization is using one of the Office 365 enterprise plans, you can configure external sharing at two levels within the SharePoint administration center. First, you can turn external sharing on or off globally for the entire environment. Additionally, you can turn external sharing on or off for each individual site collection. You can also specify whether or not you want to allow sharing with only authenticated users or with both authenticated and anonymous users through guest links. Remember, if you plan to allow external users to edit documents, you should consider restricting access to only authenticated users. Note that if your site has been upgraded from SharePoint 2010, you will not be able to manage external sharing through the SharePoint admin center for sites still using the SharePoint 2010 experience. For these sites, you will need to explicitly activate the site collection feature called “External user invitations.”
It is important to think about external sharing as part of your overall security planning for SharePoint Online. You may want to create a special permissions group to which external users are assigned when they receive invitations to be sure that you do not “overshare.” You may also want to create separate site collections that are used only for collaboration with external users so that you can allow external users to access specific content without opening up the entire environment. Remember that in all cases, your goal is to balance the ease of getting work done with trusted external partners with minimizing the governance “sharp edges” discussed in Chapter 4, “Planning for Business Governance.”
Sharing Sites Externally
If you share an entire site with an external user, that person can log in and function as a full member of the site but with some limited privileges.3 Your external user will be able to see the names of other site users in the People Picker. You will want to think seriously about whether this is a good idea if you have a site that you share with multiple external partners and you don’t want each partner to know the names of the other partners. You will also introduce some risk because once your external user has access to the site, some of your existing site users may be able to grant permissions to the external user that are different from the ones you originally assigned.
3. Guest users in SharePoint Online/Office 365 will see no links on the Suite Bar, nor will they see the ability to access an “About me” page for themselves or someone else. They will not be able to follow items or access the public newsfeed. However, if the site has a site feed, external users will be able to participate but will not see other users’ photos, and there will be no entry points for following people, topics, or documents.
If you invite external users to your top-level team site, they will be able to view content on the top-level team site and all sub-sites. If you have sensitive content, it’s a better idea to create a unique sub-site (with unique permissions) where you will put content for external users and then share only the sub-site externally. (This same concept applies when you are sharing content with internal users if the content is highly sensitive.) Remember that there is no single best practice for sharing site content with external users. It is important to think about the business purpose of your site and the level of trust you have with your external collaborators and choose an approach that minimizes risk while maximizing the ability to get work done.
Sharing Individual Documents Externally
If you are going to share documents externally in your SharePoint Online site,4 you can either use anonymous guest links or links that require authentication. If you allow anonymous guest links, anyone who gets an invitation can also share that same link with others. You should never use anonymous guest links to share documents that are sensitive, and as a best practice, you should never provide an anonymous link to allow editing of a document. Remember, even though any site user can use the Share option to share a document with an external user in SharePoint Online, only site owners (users with Full Control privileges) can authorize the access request.
4. Note that unless you have implemented some form of rights management on SharePoint content, your internal users will still be able to download a document and then share it externally via e-mail. You can have a governance policy (see Chapter 4, “Planning for Business Governance”) that tells users this is not permitted, but without some form of rights management software, you will not be able to prevent this from happening. Sharing individual documents with guest users from within your SharePoint Online site provides more control over external access, but it is not completely without risk as stated earlier. As a general rule, sharing is always best if you are working with trusted partners.
You must be a site owner or have Full Control permissions to share a document with external users the first time. Once individual external users have been granted access to any internal content, however, their user IDs are available in the People Picker, so that any user can use the Share option to initiate an access request even though the request will be routed to the site owner for approval. In addition, the external sharing feature must be turned on in either the Office 365 Service Settings or the SharePoint Online administration center, depending on which Office 365 plan your organization uses. For enterprise plans, external sharing must also be turned on for your site collection.
Planning How You Will Secure SharePoint Sites
Securing SharePoint sites consists of granting permissions to people who should belong to groups and then assigning those permissions to securable objects. Simple, right? We review each of these key security elements, which are shown in Figure 12-7, in the discussion that follows. Securing or providing access to content in SharePoint comes from the combination of these three security elements, as shown in Figure 12-8.
Figure 12-7 SharePoint security elements
Figure 12-8 Access in SharePoint happens when people are assigned permission levels for a securable object
Just as with previous versions of SharePoint, only users with the permission called Manage Permissions can grant security permissions. By default, only the Full Control and Manage Hierarchy permissions sets include the Manage Permissions item, and typically only the site owner will have this ability.
Securable Objects
Securable objects consist of all of the SharePoint elements to which permissions can be applied. These include a site collection, a sub-site or site within a site collection, a list or library, a folder, or an individual item in a list or library. By default, permissions are assigned at the site level, and lower-level objects inherit permissions from their parent site. For example, security permissions for the top-level site are inherited by all sub-sites unless you explicitly “break” the inheritance. Permissions for each object in a site are inherited from the parent site, and permissions for documents or list items are inherited from the library or folder, as shown in Figure 12-9.
Figure 12-9 Permissions in SharePoint are inherited by default
As a general best practice, you always want to apply security at the highest level possible in your solution because it’s easier to manage and maintain security in fewer places. The menu option used in SharePoint to apply unique permissions depends on the type of object.
To restrict, assign, or examine permissions for a site, select the gear icon in the upper-right corner (see Figure 12-10) and then select Site settings → Site permissions in the Users and Permissions group on the Site Settings page. Alternatively, to allow users to have access to a site, you can also click the Share option in the upper-right corner (see Figure 12-11), but be sure to select the appropriate security group for each user. As a reminder, if you do not see all of these options, you most likely do not have permissions that allow you to manage security on your site (or you are not the site owner).
Figure 12-10 Access site permissions from the “Site settings” option on a site
Figure 12-11 Assign site permissions from the Share option for a site
To restrict, assign, or examine permissions for a library, select the Library tab in the ribbon and then select Library Settings and the Shared With button, as shown in Figure 12-12.
Figure 12-12 Access document library permissions from the Shared With button on the ribbon
List permissions work exactly the same way. Be very careful if you want to assign permissions to just a list or library and not an entire site. The Share option in the upper-right corner of the page assigns permissions to the entire site, not the list or library. The only way to manage permissions for a list or library is to access the list or library settings from the ribbon.
To assign permissions for an individual item or folder, click the “. . .” context menu and then use the Share option (as shown in Figure 12-13). You can also manage permissions for an individual item or folder by clicking the “. . .” context menu until you have the option to select “Shared with” from the drop-down. Then select Advanced to both examine and assign permissions for the individual item as shown in Figure 12-13. (You can also share Office documents from directly within Office 2013. This is discussed in Chapter 20, “Integrating Office Applications.”)
Figure 12-13 Site owners can access permissions in multiple ways, including navigating from the document context menu to access the Advanced options (individual document permissions) screen shown in Figure 12-14
Figure 12-14 Individual document permissions show site owners how a document gets permissions (in this case, by inheriting from its parent) and if there are any pending access requests
It’s easiest to understand how security permissions have been applied if permissions are the same for all elements of the site. This is clearly not always possible or practical, but it should be a guiding principle for your security model. Another reason for minimizing security exceptions in SharePoint is that the interface does not easily show you where permissions have been “broken” unless you examine each item or use the Check Permissions option for each individual user in every context.
Because there is no way to scroll down a list or library view and immediately determine if a specific item (or list or site) is secured differently from its peers, it can be difficult to quickly identify or change where item-level security has been applied. Site owners can, however, select Site Settings → Site permissions to see a view like the one shown in Figure 12-15 and click the link to show which content on the site has unique permissions. This capability is extremely helpful, but it still requires a lot of clicking and must be repeated in each context where you want to understand how permissions were applied. Furthermore, if you need to update security permissions for individually secured items, you will need to update each item independently. If you are the Help Desk person trying to help a user navigate a list or library, you will need to remember that your permissions may be different from the user’s permissions inside the same list or library, so you may see more or fewer documents than the person you are trying to assist. If you have a security model that contains many item-level exceptions, you may want to consider documenting the exceptions in the item metadata or using a third-party solution for SharePoint security analysis and management such as those available from Axceler, AvePoint, and Dell.
Figure 12-15 If libraries or documents within a site have been assigned permissions directly, SharePoint alerts the user
Because security permissions are shared in all documents in a document library, if you have permission to edit one document in a library, you have permission to edit all documents in that library unless security has been “broken” (managed) for an individual document in the library. By editing, we mean the ability to alter or delete those documents. If you store documents in folders, security in the folder is inherited into each document in the folder. This is one reason that you may want to use folders in a document library—to apply shared editing permissions to separate groups of documents and minimize the use of item-level permissions. This is one example of how security has an impact on your user experience and content topology. Introducing folders or document sets to manage collective security may solve authorization issues but may introduce an inconsistency in how content is managed (for example, other libraries may group documents by metadata). Consider this when balancing security management and usability.
Security Trimming
Any object that you secure in SharePoint is secure in both “browse” and “search” scenarios. If a document, list, or site has unique permissions, users who do not have access to the object will not see it in lists or search results. This is called security trimming. If an unauthorized user attempts to access this content directly via a URL link, that user will be denied access and prompted for alternate credentials. Security trimming also impacts search results. If two different users execute the same exact search, they may see different results based on their permissions. Security does not affect the relevancy of results; it only affects the number of items that are returned.
Security Exceptions
Information Rights Management (IRM), which is part of most SharePoint Online enterprise plans and can be added to and integrated with SharePoint 2013 Server Standard and Enterprise on-premises, offers another way to secure items stored in SharePoint. Microsoft IRM allows users to create a persistent set of access controls that live with the content itself as well as in the location where the item is stored if your administrator has enabled IRM for your environment. IRM services can be used, for example, to protect an individual item from being downloaded or printed. When enabled, IRM security takes precedence in a list or library. For example, if an authorized user opens a rights-managed document from a document library where the IRM protection does not allow documents to be downloaded, the user would not be able to download and send that document to another user, even if that person also has access to the SharePoint library. Instead, the other user would have to go to the library and view the document directly. For more information about IRM and SharePoint 2013, refer to http://office.microsoft.com/en-us/sharepoint-help/apply-information-rights-management-to-a-list-or-library-HA102891460.aspx.
There are several objects in SharePoint that cannot be secured. These include views, audiences, Web Parts, and list Columns. Be sure to consider the following implications about which objects can be secured and how security is inherited:
Because you cannot secure an individual view of a document library, you cannot use unique views to get around the fact that you cannot secure an individual Column in a list. For example, you may want to have a Column in a list that shows financial numbers that you don’t want all users to see. You cannot secure the financial Columns using Manage Permissions or secure a view that doesn’t display the financial Columns. In this scenario, you should consider using an alternate means of sharing the sensitive data. For example, one approach might be to use Excel to store the information and secure the Column in Excel. You can then use Excel Services to display the information in a SharePoint Web Part. (See Chapter 18, “Planning for Business Intelligence,” for a description of how to leverage Excel Services.) Another approach would be to show the protected data in a separate list and use an event handler to keep the two lists synchronized.
You cannot secure a Web Part, but you can use an audience to target a Web Part so that it shows up only for users who “belong” to that audience. (Note that the content displayed in a Web Part is always secure, but security cannot be applied to the Web Part itself.) Targeting a Web Part using an audience does not secure the content displayed in the Web Part—you must secure the object displayed in the Web Part by managing permissions on the content. This is an important distinction. Audiences are used to personalize presentation and effectively manage screen real estate with relevant content. Use audience targeting to feature or showcase information, not to protect it.
People (User or Group)
In the context of SharePoint, “people” are individual users who need access to a SharePoint site and can be defined individually or as members of a group. A group is a named collection of people (users) in SharePoint.
While individual people can be granted permissions inside of SharePoint, it is generally more desirable to first add a person to a group and then grant permissions to the group. That way, new users can be added in one place, to either a SharePoint or Active Directory Group, and they will automatically get all the permissions associated with that group. This methodology is also helpful in two other ways: (1) it is easier to replicate security permissions for new users, and (2) it reduces the amount of legacy security that accumulates over time (for example, someone has left the company but his or her name is still associated with a collection of sites across the environment).
In SharePoint, there are two types of groups that you will work with:
A Domain Group is created outside SharePoint in Active Directory. A Domain Group (also called an Active Directory or AD Group) is defined for the entire enterprise and can be used in any site collection in SharePoint or to manage access for other applications used by your organization. Domain Groups are generally created by a security administrator in your IT organization, but some organizations allow business teams to request the creation of a new Domain Group that they can manage themselves. Domain Groups are most often created to represent persistent roles or geographic groups of people inside your organization. If you can, take advantage of existing, automatically maintained Domain Groups to assign permissions for your site. For example, if there is already a Domain Group for managers and you have content or sites that are for managers only, you should use this existing group to secure your site. When new managers are added or if someone is no longer a manager, you will not need to worry about (or be responsible for) adding or deleting the person’s name from the group. If your organization allows you to create Domain Groups that are not automatically populated, you may have to manage “comings and goings,” but you will still need to do so in only one place. It is not always possible or practical to have an Active Directory Group for individual sites in SharePoint. This is especially true if you are creating highly granular, low-membership groups. You should not clutter AD with SharePoint-specific groups. You should also avoid creating AD Groups that cannot be repurposed (that is, used in multiple security applications inside and outside of SharePoint). In these instances, you are better served by leveraging SharePoint security groups.
A SharePoint Group can be defined by a site collection administrator or a user with Manage Permissions privileges and can be used to secure objects within a single site collection only. Groups created in SharePoint for one site collection can be used only within that individual site collection and must be separately created and maintained if needed in another site collection. All SharePoint Groups are created at the site collection level and are available to any sub-site or other securable object in the site collection.
SharePoint Groups can include Active Directory Groups and/or individual users. However, SharePoint Groups cannot include other SharePoint Groups. There are two types of SharePoint Groups: Default Groups and Custom Groups. There is a raging debate in the SharePoint community about whether Active Directory or SharePoint Groups are “better” for managing security. As with pretty much all things related to SharePoint, the right answer is “It depends.” There are pros and cons of each type of security group as described in the discussion that follows.
Default SharePoint Groups
SharePoint provides several default SharePoint Groups for team sites; additional default SharePoint Groups are provided in publishing sites or when publishing features are enabled. Each SharePoint Group is associated with a default permission level. (Refer to the next section of this chapter for a detailed review of permissions and permission levels.). The out-of-the-box security groups in SharePoint are essentially a combination of “role” and “permissions.”
In addition, the SharePoint model is inclusive, not exclusive. That is, you cannot define activities that users or groups are not allowed to perform. For example, the Visitors group has the Read permission level by default, so people often associate the Visitors group with Read permissions, even though this doesn’t have to be the case. For example, when you want Visitors to be able to respond to a survey, they will need Contribute permissions.
As a general rule, you always want to give a person or group the least amount of permissions to effectively achieve the required business functionality . . . and no more (the “principle of least privilege”). This may create additional administrative overhead, but it is a core tenet of ensuring the stability and security of a SharePoint environment.
Default team site SharePoint Groups and associated permission levels are described in Table 12-2. Additional default security groups and associated permission levels are created if you use templates other than the Team Site template or if you activate publishing features for a site; these groups are described in Table 12-3.
Table 12-2 Team Site Default SharePoint Groups and Associated Permission Levels
Table 12-3 Publishing Site Default SharePoint Groups and Associated Permission Levels
Caution: New Edit Permission for SharePoint 2013 Team Sites
In response to requests from some SharePoint users, Microsoft added a new Edit permission level in SharePoint 2013 to the default Members group settings. In addition to standard Contribute rights (add, edit, delete on current lists/libraries), the Edit permission level includes the ability to “Manage Lists.” This allows users to create and delete lists, add or remove Columns in a list, and add or remove public views of a list.
This is likely to catch many SharePoint administrators off guard because members in SharePoint 2013 team sites have “more powers” than they did in previous versions.
In our experience, Manage Lists permissions should not be given to users who have not had sufficient training to use the power that comes with this permission. If members can create or delete metadata Columns, lists, and libraries ad hoc, it is difficult to create and maintain meaningful site structure or prevent content fragmentation. (Note that if users with Edit permissions create a list or library, they do not get Full Control permissions for that list or library. They still have only Edit permissions, which do not include the ability to manage permissions or override list behaviors, which is granted with Full Control privileges.)
Unless both your business needs and training plans are aligned to support assigning the ability to manage lists to team site members, you may want to consider adjusting the Team Site templates in your organization to allow members to have only the Contribute permission set by default, as it was in previous versions.
If you want to allow more users than the site owner to manage lists, consider creating a new security group called Editors and assign Edit permissions to this group.
If you enable publishing features for your site but decide that you do not need any of these security groups, you can leave these groups unpopulated or delete the default groups that you are not using. It is usually better to leave only those security groups that you are actually using on your site to create a “cleaner” and less confusing experience for site owners. However, you should be thoughtful about which groups you delete because your site and business needs may evolve over time.
Special SharePoint Groups
In addition, SharePoint includes several special users and groups for administering SharePoint sites:
Site collection administrators have an “all-access pass” to every element of content and all site permissions in all sites in the collection. In addition, they are recorded as the contact for the site collection and can audit site content, enable site collection features, and monitor site and search usage. A SharePoint site can have a primary and secondary site collection administrator, and if you are the site collection administrator, you can add additional admins. You cannot hide content from a site collection administrator, so if you have content that can be visible only to members of the executive committee in your organization, you will need to designate a member of the executive committee as the site collection administrator. You need to designate individual people, not a group, as site collection administrators, with the ideal number being more than one, but no more than a handful of users. It is recommended that site collection administrators (or any administrator) be named users and not service accounts. Using service accounts eliminates auditing capabilities as you can’t track changes to specific resources.
Farm administrators control which users can manage settings for the server farm in on-premises deployments. By default, farm administrators do not have access to site content, though they can take ownership of a site if they want to view content. This group is used only in central administration; you won’t see this group in any individual site collection.
Administrators have the same privileges as farm administrators, but they can also install new products and applications, deploy Web Parts to the entire farm, create new Web applications, and start services (such as a search crawl) on-premises. This group does not have access to site content by default and is not visible in an individual site collection.
There are additional standard special security groups for SharePoint Online:
Company administrators include any user who is a global administrator for Office 365. By default, the Office 365 Company Administrators group is added to the SharePoint Owners group and the list of site collection administrators and thus has Full Control privileges. Be cautious about changing the group membership for company administrators or removing any of these special high-level groups. As an example, if you remove a company administrator from the SharePoint Owners group, you could remove permissions from the Global Admin group and eliminate the ability of this group to configure access for SharePoint Groups.
SharePoint Online administrators is a group included with SharePoint Online for Enterprises. Users in this group can configure user profile and InfoPath Forms Services, set up search and Business Connectivity Services, create a term store, or define a records management system. Users with these privileges can also monitor quotas; set up the ability to invite external users to access the SharePoint Online site; create, update, or delete site collections; and assign primary and secondary site collection owners to any site collection.
Tenant_Users include every user who is added to Office 365. These users are automatically added to the Members group on the SharePoint team site and are thus given Edit permissions by default. You should consider changing this if you do not want to provide this level of permissions for every single user. You can instead add the Tenant_Users group to the SharePoint Visitors group, which is a safer option. That means that all users will get Read permissions by default, which is probably more in line with the expected behavior in most scenarios.
Custom SharePoint Groups
There may be situations where you have groups of people who need different access permissions to various objects in your site and it may not be possible or practical to create an Active Directory Group for them. While you can add multiple Active Directory Groups to a SharePoint Group, you cannot “nest” SharePoint Groups. If the same group of people need different permissions in different sites (for example, Contribute in one and Read in another) and you can’t use an Active Directory Group, you will want to create a custom SharePoint Group.
You may also want to create a custom group because the terms visitors, members, and owners just don’t make sense in your organization and you want to use terms that will resonate better with users. As a best practice, when you create a custom SharePoint Group, choose a name for the group to reflect the people in the group and their collective role in the organization, not their security permissions. This is hard to explain without an example, so please continue reading to the section of this chapter where the step-by-step planning process is described to see an example of a situation where you might want to create custom SharePoint Groups.
Special Considerations for Community Sites
As a best practice, you should always set up your community sites with unique permissions—and use the default security groups that the template creates for you. (For more information about the Community Site template, refer to Chapter 15, “Planning for Social Computing.”) Microsoft has built in some special permissions for community sites and, unfortunately, changed the meaning of the term member in the context of sites built using the Community Site template. Actually, the term member in the context of a community site is probably closer to the generally accepted English definition of this term. As discussed earlier, the use of the term member in the context of all other types of SharePoint team sites is confusing because it is used to refer to a permission group, not the group of people who are actually members of the team. In the context of a community site, there are actually two completely different types of “members”:
Members of the SharePoint security group called [Site Name] Members. Just like other team sites in SharePoint, when you create a new community site with unique permissions, SharePoint 2013 automatically creates the default security groups [Site Name] Owners, [Site Name] Members, [Site Name] Visitors, and the new [Site Name] Moderators. These default groups have Full Control, Contribute, Read, and Moderator permissions, respectively. This is actually different from “regular” team sites, where [Site Name] Members have Edit permissions by default. You definitely do not want most community site users to have Edit permissions, so the default permissions are very helpful in this context.
Members of the community site (who will be listed in the members view in the default template). In the community site, a member also means someone who has explicitly joined the community using the join option on the community site. Until users explicitly join a community, they are not listed in the members view on the site. Even if users are in the Members security group, until they have either explicitly joined the community or made a contribution to the discussion group, they are not listed in the members view. It is fortunate that the only people who really have to understand these distinctions are the people who create community sites and your Help Desk, who will get the calls when something goes wrong. The best advice to solution planners is to be aware of this distinction and document it very carefully for your Help Desk.
Permission Levels
Individual permissions (such as view items, open items, edit items, and delete items) are grouped together into permission “levels,” such as Contribute, which allow users to perform specific actions. Permission levels are created and managed at the root site level only but inherit down for use at any sub-site. You can also create custom permission levels, but when you do this, you may make managing a site more difficult and you will also make it more difficult to audit your site’s security. That doesn’t mean that you shouldn’t create custom permission levels, but it does mean that you should carefully document all the permission levels that you create for your site. In some organizations, we have seen users set up a custom permission level that offers content contribution but not deletion rights. This allows users to create and edit content but not delete it. (Note that the Recycle Bin minimizes the need for this type of customization, but there are scenarios where site owners really want this level of control.) Since you create permission levels at the root of the site collection, you can configure this custom permission level once and it will be available for all sites in the collection.
Individual permissions are assigned to one or more permission levels, which are in turn assigned to individual users or SharePoint Groups. Remember that the preferred approach is that permission levels should always be assigned to SharePoint Groups, not individuals.
The out-of-the-box or default permission levels for team sites include the following:
Full Control provides administrator access to the site. This permission level contains all permissions and cannot be customized or deleted. As a general rule, you will allow users to have Full Control privileges only when they have demonstrated an understanding of how SharePoint works, SharePoint best practices, and, most important, your organization’s governance model. This user can give anyone else permissions, including Full Control.
Design allows the user to create lists and document libraries, edit pages, and apply themes, borders, and style sheets in the site.
Edit, a new permission level for SharePoint 2013, allows the user to create and delete lists, add or delete Columns in lists, and add or delete public views of lists in addition to all of the privileges afforded users with Contribute permissions.
Contribute allows the user to add, edit, and delete items in existing lists and document libraries.
Read allows read-only access to the site. Users and groups with this permission level can view items and pages, open items, and download documents.
Limited Access is a special permission level that is automatically assigned to users who have access to some areas of the site but not all areas. For example, users with Contribute access to a document library on a sub-site will appear in the permissions list of the home page as having Limited Access permissions. This does not allow them to view anything on the home page unless they belong to a group that has home page access. Limited Access is automatically assigned by SharePoint when a user or group is provided unique access to a specific securable object. This permission level cannot be customized or deleted.
The out-of-the-box or default permission levels for publishing sites include the following:
Manage Hierarchy allows users to create sites and edit pages, list items, and documents. This permission level does not include permission to approve items, apply themes and borders or style sheets, or create groups. However, this permission level is otherwise very similar to Full Control.
Approve allows users to edit and approve pages, list items, and documents.
View allows users to view pages, list items, and documents. Document types with server-side file handlers can be viewed in the browser but not downloaded.
Restricted Read is designed to give users access to a specific list, document library, item, or document without giving them access to the entire site. Previous document versions and user rights information are not available to people and groups with this permission level.
It is possible to create custom permission levels based on business needs. As a best practice, you should not change the out-of-the-box permission levels. Always create a copy of an existing permission level to create a new one. This can be done by going to Site Settings → Site permissions → Permission Levels and then clicking to the permission level that is closest to the new one you want to create. Scroll to the bottom of the page and click the Copy Permission Level option. Custom permission levels, like securable objects that require unique security, add complexity to the maintenance of your security model. Some individual permissions have dependencies, but in general, SharePoint will not allow you to delete an individual permission from a permission level if other individual permissions depend on it. With 33 individual permissions, youcan see that creating custom permission levels can get very complicated. If you do create custom permission levels, be sure to carefully document and describe what you have done and why you have created the custom levels. Examples of possible custom permission levels that we have seen in practice include the following:
Restricted Contributor: for users who can upload and edit documents but cannot delete documents. This custom permission level can help ensure that users cannot accidentally delete documents but still have the capability to upload and edit them. To create a custom Restricted Contributor permission level, create a copy of the Contribute permission level and then remove (uncheck) the Delete Items and Delete Versions permissions. Users without delete permissions will not be able to edit the document name (file name) after uploading the document. If the name needs to be changed, a user with Edit, Contribute, Design, or Full Control permissions will have to make any necessary changes to the document name. Users with custom Restricted Contributor permissions (add, change, but not delete) can edit other metadata properties.
Manage Permissions: for users who need to manage permissions for the site or library but not necessarily have Full Control access. By default, a user must have Full Control permissions to manage security for a site. However, you may want to delegate the responsibility for managing security to a user who should not have Full Control access to the site. In this case, create a custom permission level that starts with the Contribute (or Edit) set but adds the Manage Permissions user permission. This custom permission level will allow users to upload, edit, and delete documents and manage user access without having Full Control privileges. You’ll want to be careful about creating this type of access because in addition to allowing a group with this custom permission set to add and remove users from groups, it also allows them to create new groups and change permissions on existing objects. As with Full Control, only highly trusted and trained users should have the ability to manage permissions on your site.
Use the following best practices for creating and managing permission levels:
If a custom permission level is needed for a SharePoint site collection, always start with an existing permission level and then either add to or delete from that set of permissions to create the custom permission level.
Try to create short, meaningful names for each custom permission level, and be sure to add a description that summarizes what type of access is associated with the permission level. In some cases, it is helpful to prepend your organization’s name to customizations to have them stand out as unique and personalized.
As a general rule, do not change the “default” permission levels. Remember the saying “You touch it, you own it.” SharePoint does not offer any indicator that shows alterations to native security levels. If a similar permission level is needed and you are tempted to modify one of the default permission levels, follow this process instead:
Start with a copy of that permission level and make a custom permission level.
After copying the default permission level, make additions or deletions to individual permissions.
Defining and Documenting Your SharePoint Security Plan
A well-thought-out security model is crucial for the successful assignment of security in any SharePoint site collection. This section describes a process you can use to work through the steps required to properly secure your site (or site collection). We recommend that you complete and document your security model before actually creating groups or assigning permission levels in a site collection.
Note
As a best practice, you should save your security plan and any other administrative documents for your site in a secure document library visible only to the Site Owners group or individuals with Full Control or Design privileges.
The following steps describe the progressive design and documentation of a security schema for a corporate site with sub-sites for marketing, finance, and human resources:
Step 1. List and describe where unique security is required. Table 12-4 shows an example of the first level of a security model for an intranet site collection—where you describe each securable object and document whether it needs unique or inherited permissions.
Table 12-4 Sample Security Table
Step 2. List and describe who needs access. Table 12-5 identifies who needs what type of access to each securable object in the site collection.
Table 12-5 Sample Security Table with Access Defined
Step 3. List and describe the permission levels. Table 12-6 describes the permission levels needed for the site collection.
Table 12-6 Permission Levels for This Site
Step 4. Define and create the SharePoint security groups you need.
Step 5. Apply security permissions.
These steps are described in detail in the following sections.
Step 1: List and Describe Where Unique Security Is Required
To simplify the ongoing management of security of each site collection, it is important to partner with your business sponsor(s) to determine which parts of a site collection have common security requirements and which parts have unique requirements. As discussed in Chapter 4, “Planning for Business Governance,” you need to carefully consider the implications of “oversecuring” content. If every site is locked down for Read access, it will be hard to achieve your knowledge management objectives. Remember that SharePoint security is inclusive—you need to fully understand the requirements associated with protecting highly secured content and know what should never happen (for example, security breaches).
As you think about creating the permission structure for each site collection, you need to carefully balance the ease of maintaining and administering the security model with the need to control specific permissions for individual securable objects. As a general rule, try to manage securityat the site level. If there are particular items that contain sensitive information that must be even more secure than the site as a whole, you can apply security to individual securable objects. But remember, applying detailed security permissions at the object level can be a very time-consuming task. SharePoint includes the capability to identify how permissions have been assigned in your site collection, but “unpacking” permissions is a group-by-group, site-by-site, object-by-object process, so the more complex your model, the more complex it will be to examine and maintain security. When you examine permissions at the site level, SharePoint 2013 identifies if unique permissions have been applied somewhere in the site and provides a link to show you which lists and libraries have unique permissions (see Figure 12-15). However, you will not be able to tell just by looking at a document library or site whether unique security has been applied—you will have to examine the settings for the object or group to see how it has been secured. This is why it is easier to maintain security at the site level: you have only one place to look when you need to understand how security has been applied.
Consider each part of a site when determining the security assignments for the top-level site, the sub-sites, and document libraries and lists. Document the overall site security model and note the parts that require unique security levels. One way to initially document the security that will need to be applied is to start with the site architecture diagram and add a visual indicator to define where unique security is needed. As discussed in Chapter 6, “Planning Your Information Architecture,” there are several tools you can use to create a site architecture diagram, including MindManager, Visio, PowerPoint, or Word (if the diagram is not very complex). Figure 12-16 shows a simple site architecture diagram that includes an indicator (the word unique) to show where unique security permissions will be applied (no indicator assumes inherited permissions).
Figure 12-16 Site architecture diagram with security indicator
Notice that “Discussion Board” on the home page is displayed in bold. This is a visual cue indicating that the discussion board will have different security from the rest of the home page—all employees have Read access to most of the content on the home page, but they can contribute to the discussion board. The same would be required for surveys. You could also create a “node” in your diagram for each object in the site and use dotted lines or different colors to indicate where unique security is required. Planning security is an iterative process, and you may find that you need a more textbased approach to evolve your model. As an alternative to a site architecture diagram, you can create a table like Table 12-4 to facilitate conversation with the business sponsor(s) about the permissions types that are needed for the site. As we go through steps 2 and 3, we’ll expand the columns in the table. At the end of the steps, we will have documented our security model for this site collection. A similar approach can be used to prepare the security model for an extranet (that is, an externally accessible site for content presentation or collaboration with partners or customers), but more care would be required to define shared and exclusive partner/client areas.
Note that this example assumes a home page where a small number of individuals can contribute content but a large number can read content. The home page is a site where the primary purpose is communications. On the home page, there is a discussion board to which all users can contribute even though they have only Read permissions for the rest of the content on the home page.
When planning security, keep in mind the following:
The security of each object is inherited from its parent unless inheritance is explicitly broken. For example, by default, every object (for example, list or library) on a site has the same security as the site itself. If users have Contribute access to the site, they have Contribute access to every object on the site. Similarly, if users have Contribute access to a document library, they have Contribute access to every document in the library unless unique permissions have been applied to a document.
Permissions from the parent can be reapplied if previously broken. However, any special permission levels that were previously created at the object level will be removed when permissions from the parent are reapplied.
Given these characteristics, think about the following regarding security as the site is designed:
Try to design the site to allow assignment of permissions at the site level.
If security at the object level is required, consider security for an entire object (an entire list or library, for example) before securing individual items. This may mean creating a second document library (or a folder within a library) if you need unique permissions for a particular group of documents.
Always consider navigation. If you assign unique security to a nested sub-site, you must ensure that the user has a navigation path to it. That is, if users have access to a sub-site but do not have any access to the parent site, they will have no way to get to the sub-site. This is why it is good practice to examine your security model from the top down (that is, home page to lowest-level sub-site), then in reverse (lowest-level site back to home page).
Step 2: List and Describe Who Needs Access
The next step is to carefully consider who needs access to a site collection or part of a site collection. The easiest way to document this is to add columns to the table created in step 1 to identify who needs what type of access to each securable object in the site collection. This is shown inTable 12-5.
This step may require several iterations as the plan is reviewed with key stakeholders for the site and as the site design evolves. It should account for expected functional growth and anticipated security changes.
Step 3: List and Describe the Permission Levels
Next, evaluate the out-of-the-box permission levels to ensure that they meet your needs. As described earlier, permission levels are the collection of individual permissions that describe what users can and cannot do with the securable objects on a site. You can use a table structure like that shown in Table 12-6 to describe the permission levels needed for your site. For example, if we were to need custom permission levels, we would list those in addition to the out-of-the-box permission levels we plan to use.
Step 4: Define and Create the SharePoint Security Groups You Need
Out-of-the-box groups like Members or Visitors may not provide sufficient granularity for your permissions requirements. You can address this by creating custom SharePoint Groups for the following scenarios (among others):
A group of users in a site collection needs different permission levels in different areas of the site (e.g., Read in one area, Contributor in another).
You need to clearly identify a group of users by role (e.g., Senior Leadership Committee).
It is not possible or practical to create an Active Directory Group for these users.
When you create a custom SharePoint Group, it is best to choose a business-oriented name for the group—such as Marketing Team—rather than a permission-oriented name like Reader or Contributor. Create your custom SharePoint Groups at the top level of the site with no permissions. Then, grant the group appropriate permission levels for the specific securable objects where unique access is needed within the site collection.
For simple sites and most team sites, you can begin by using the default SharePoint Groups (which are [Site Name] Owners, [Site Name] Members, and [Site Name] Visitors) and assign permissions at the site level. In our example, by examining the security requirements, we decide that we want to create a custom SharePoint Group called Marketing Team because we want a clearly named group of people that we can maintain as a group but assign different permission levels to this group depending on the securable object within the site. As a best practice, after creating the [Site Name] Owners group, use that group as the owner of related groups. This will allow any member in the Owners group to manage the subgroups. In addition, using consistent group name prefixes will help you easily identify related groups as they will display together in the SharePoint Group directory. Using generic group names (e.g., Administrative Assistants) is helpful if the group includes all administrative assistants in the business but not if it includes only the marketing or HR administrative assistants.
Whether or not you use custom or default security groups, you will generally follow a model similar to the inverted triangle shown in Figure 12-17. In general, you should assign users only the permissions they need to do their jobs.
Figure 12-17 Assign users only the permissions they need to do their jobs
Most of your users will belong to a group with Read permissions. Fewer users will belong to groups with Edit or Contribute permissions. Do not add every user as a member of the [Site Name] Owners SharePoint Group. Instead, limit Full Control rights to a small set of well-trained users who will be responsible for all aspects of site maintenance. Because users with Full Control permissions can change permissions for themselves and others or even delete the site, it is easy to lose control of the site if too many people have this level of access.
Do not confuse business ownership of a site with the default security group called [Site Name] Owners. In most cases, the business executive who is the “owner” or sponsor of the site does not have (or need) Full Control privileges for the site.
Step 5: Apply Security Permissions
Security is assigned from the perspective of the securable object. Therefore, in the last step of the process, permissions and objects that need security are combined with any existing Domain Groups and default or custom SharePoint Groups.
In this step, extend the security table to include the securable objects requiring unique security (from step 1), the security group name (Owners, Members, Visitors from step 4), the permission level (from step 3), and the people who need access (from step 2) in a table similar to the complete security table example shown in Table 12-7.
Table 12-7 Sample Complete Security Model
In this example, two custom SharePoint Groups are created for marketing and HR because these groups of people have different levels of access in different areas of the site collection. For all other securable objects, the default groups created by SharePoint are used. In addition, we explicitly removed permissions for any security group that was initially inherited from the parent (top-level) site but should not have permissions for the uniquely secured object.
Maintaining Your Security Model
It may seem overly ambitious to expect you to keep your initial security plan document up-to-date, but if there is any documentation worth maintaining as you evolve your site design, this is the one to try to maintain. In fact, it may not be a single document but a collection of documents (if you choose to decentralize security management). If you always follow the best practice of assigning users to groups rather than assigning permissions to individuals, maintaining the document won’t be too difficult because you will need to make an update only if you add a new group or add unique permissions to a securable object. Is it realistic to assume that you can keep the security model document current in a dynamic environment? Probably not. So you will definitely want to take advantage of the ways SharePoint allows you to “unpack” your security model directly in your site. Here’s what you can do pretty easily:
Check the permissions on a site.
Check the permissions that have been assigned to an individual or group across the entire site collection.
On an individual object, display the permission levels and how those permissions were applied. Figures 12-12, 12-13, 12-14, and 12-15 show the various ways to review access permissions and requests for access for an individual document, list item, or site.
Here’s what you can’t do easily with the native interface: audit who has made security changes to various securable objects. To easily audit how security permissions have been assigned and changed over time, you will want to consider deploying a third-party tool.
Managing and checking security permissions can be very time-consuming, with or without a third-party tool. As a best practice, it is a good idea to create a test user account and use it for security validation. If you are someone with security application privileges, you automatically have access to the associated content when you change permissions. To verify that the security changes you make work as expected, add the test user as a member of the appropriate security group. Log in as that test user and validate that the content is accessible. Then, remove the user from the group and test again to ensure that the content is no longer accessible.
The concept that the “highest” set of privileges will always apply is an important one to remember. This means if a user is a member of two groups, Group A and Group B, where Group A has Read permission for a site and Group B has Edit permission, the user will have Edit access.
Checking Permissions for a Site
To check how permissions have been assigned on an individual site, you must have Full Control privileges. To check permissions for a site, navigate to the root of the site and click the gear icon at the upper right and select “Shared with ...” as shown in Figure 12-18. This will show you a list of names of people and groups with which the site has been shared. From this Shared With box, which is shown in Figure 12-13, you can click the Advanced option to see the details displayed in Figure 12-14. This will tell you if there are uniquely secured items in the site. If not, you know what you see at the site permissions is inherited to all objects in the site. If there are uniquely secured items, you will be able to see which items have unique permissions. To find out what these unique permissions are, you will need to navigate to the item and check the permissions as described below.
Figure 12-18 Use Shared With to display how permissions have been assigned in an individual site
Checking Permissions Assigned to an Individual or Group
To examine how permissions have been assigned to an individual or group across a site collection, you must have Full Control privileges. The easiest way to do this is to go to the root of the site collection and select Site Settings → Site permissions and click the Check Permissions button in the ribbon (refer to Figure 12-15). This will display the Check Permissions dialog box shown in Figure 12-19. Start typing the name of the individual or group, and you will see a drop-down list of names matching what you have typed. Click the Check Now button to see a view of the permissions for that user or group in the site collection. You will see a list that enumerates the permissions for the individual or group. The list shows the URL of each securable object and the permission level that has been assigned to each group.
Figure 12-19 Use Check Permissions to display how permissions have been assigned to an individual or group in a site collection
Alternatively, to check permissions for a group you can also go to the root of the site collection and select Site Settings → Users and Permissions, and then People and Groups. Highlight the group in the Quick Launch and select Settings → View Group Permissions as shown in Figure 12-20.
Figure 12-20 Use View Group Permissions to display how permissions have been assigned to a group in a site collection
Displaying Permission Levels for an Object
To examine permission levels for an individual object, you need to navigate to the object. From the individual object where you want to display permissions, navigate to the settings for that object.
For a site, this is found under Site Settings → Users and Permissions. Click “Site permissions” to access the Check Permissions option in the ribbon. Note that People and Groups will show individuals and site groups that are available to the entire site collection, not just the current site.
For a document library or list, click the Shared With option in the ribbon and then use the Advanced option for additional detail (see Figures 12-12 and 12-13). You can also access the library or list settings and then the “Permissions for this library or list” option under Permissions and Management.
For a document, click the Shared With option (see Figure 12-13).
Troubleshooting Security Applications
This section contains examples of reported issues and questions with security applications in SharePoint and the associated potential resolutions/answers. This list is not exhaustive but demonstrates additional learning elements associated with SharePoint security management.
“SharePoint is denying me access to a site.” First, it is very important to note that SharePoint handles authorization but not authentication. You can’t get to a SharePoint site without first being authenticated (that is, associated with valid credentials). Once a user is authenticated, SharePoint applies security to determine whether that user is authorized to see all, some, or none of the content. If users do not have access rights to a site or object for which they have a link, a page is presented so an access request can be sent to the site owner (Figure 12-21). Note that the only way users can see the message shown in Figure 12-21 is if they have been given a link to content from another user or from a page or site or object to which they have access. Search will never return objects to which a user doesn’t have access—but people can easily place hyperlinks to secured content in documents or on site pages without knowing that the content to which they are linking may not be available to all users.
Figure 12-21 Users who are denied access can engage in a dialog with the site owner to request access
“Certain users can no longer access their team site, and security has not been changed.” There is a scenario worth mentioning here. If a site contributor places an image on the site and the image is located (and secured) in a different location, that security is applied at the time of page rendering. So in this example, a user may be prompted with the security dialog box because that user does not have access to the image. This is why security must be well mapped in early stages where, in this case, an openly available image library has the necessary Read access.
“I’m the site owner and I no longer have access to my site.” Users with Full Control privileges (typically, users in the Site Owners group) have permission to manage all permissions—including their own. Even after being trained, a site owner might accidentally remove his or her own permissions from a site, usually while adding or removing other users from the Site Owners group. When this happens, the site collection administrator can add the user back to the Site Owners group.
“How do I know if I have contribution rights to a library?” If you see the “+ New document or drag files here” instructions when you are viewing a library, you have contribution rights to that library.
Key Points
Consider the following recommended actions when you think about security:
Carefully plan and document your security model before you begin configuring your site. This involves defining the security associated with the full-site topology as well as the necessary roles and security exceptions.
Try to apply security at the highest level, preferably the site. Pay attention to the concept of permission inheritance as you plan and apply security.
As much as possible, avoid giving access permissions to individual users. Always try to ensure that users will be assigned to groups and that permissions are assigned to groups, not individual people. This makes support and maintenance simpler and reduces the amount of clutter that is left behind when staff depart.
Be sure to document and justify all custom permission levels you create for your site.
Use the “principle of least privilege” to assign permissions to users. As a general rule, give users only the permissions that they need to perform their roles. Your business sponsor may be the effective “owner” of your site, but that doesn’t mean that you should give your business sponsor Owner (Full Control) privileges for the site. Think about a variation of the phrase that is often associated with the Hippocratic Oath for assigning security permissions—“First, don’t assign permissions that allow a user to do harm to the site”—as you place users into security groups.
In Office 365/SharePoint Online environments, pay attention to whether or not something should be shared with Everyone or Everyone except external users. There may be scenarios where you want to explicitly restrict access to guest user accounts. While you can, as suggested, create a separate site collection where you allow external access and have some internal-only sites where this will never be an issue, you have the option of providing even more explicit restrictions even if the site collection content would otherwise be available to be shared with external (guest) users.
Think about whether the new default Edit permissions set for members is appropriate for your users. You may want to consider changing the default back to Contribute.
If you are not using the Community Site template, be sure to use the out-of-the-box security groups and give users access via the Share option to make sure that you don’t give members the wrong permissions.
If you are using SharePoint Online and will allow access for external users, it is always a good idea to require authentication if you are allowing an external user to edit content.
If you are using SharePoint 2013 on-premises and want visitors and members to be able to initiate sharing requests for documents, be sure to enable access requests for your site and make sure e-mail is enabled for your farm.
If you need to create custom permission levels, start by making a copy of an existing permission level and then add or remove individual permissions. Don’t go overboard with creating custom permission levels or you will make yourself crazy trying to understand and maintain your security model.
Be sure to create a process or plan to monitor security as your solution evolves.
Don’t give service accounts or generic user accounts security privileges. An effective security audit includes the ability to associate any task with a specific individual.
Factor security into any navigation strategy. In traveling from site A to site B, a user must have at least Read permission to all nodes in that path or the navigation fails.
If you can, try to keep the security model document up-to-date. In addition, use the processes described in the “Maintaining Your Security Model” section to audit permissions and access for critical sites on a regular basis. At a minimum, try to document where and why you have applied individual item-level permissions in a list or library—you don’t necessarily have to document how you have secured each item, just the “method to your madness”! The third-party tools mentioned earlier can help identify where you have broken permissions, but your security model helps you understand why this might have occurred.