Adding users to a group

For people to access your site, you must share it with them by adding them to one of these default groups. For example, to add users to the Site Members group, follow these steps:

1. Log in to the site as a Site Owner, and then click the Share button in the upper-right corner of the page.

   The Share dialog box appears, as shown in Figure 14-1.

   Alternatively, you can add users to groups on the Site Settings page by clicking the People and Groups link in the Users and Permissions section.

2. Enter the names of the users you wish to add to the site.

   You can enter names or email addresses of users that SharePoint can add to the site.

   Type the names in the form of domainaccount. For example, if your domain name is PORTALINTEGRATORS and the name is Rosemarie Withee, type PORTALINTEGRATORS osemariewithee. You can also just type Rosemarie Withee, and SharePoint will try to resolve the name to the account.

   If you don’t know the names of user accounts, you can type the email addresses. SharePoint tries to map the email address for the account. For example, the email address [email protected] resolves to PORTALINTEGRATORS osemariewithee in our domain. Chances are that you can use the email addresses from your address book in Outlook.

3. Include a personal message that will be included with the invitation.

   This step is optional. If left blank, users will be emailed a generic welcome message.

   If you don’t see a dialog to enter a personal message, then email has not been configured for the SharePoint environment.

4. Decide if you want to send the users a welcome email message by selecting or deselecting the Send an E-mail Invitation check box.

5. Click Show Options to select the group where you want to add the users.

   By default, the dialog box adds users to the Site Members group.

6. Click the Share button to add the users to the SharePoint group and thus share the site with them.

With Office 365, you have the ability to invite people to use your site who are outside your organization. We discuss using this functionality to create a client extranet in Chapter 23.

Understanding the permission structure

Members in the Site Owners SharePoint Group create the permission structure for a site. The Site Owner should have a pretty good understanding of which users need to access the site and what that access should be. This means that members of IT usually shouldn’t be Site Owners. Instead, you want members of the business departments to take responsibility for site ownership.

Permissions are contained within a site collection. Therefore, all the people, groups, and permission levels defined for a site collection are available to every site and app within the collection. Permissions inheritance is in place by default, so all the content and subsites in SharePoint inherit permissions from their parents.

Web sites, apps, folders, and list items are all securable with permissions in SharePoint.

When a subsite is created, all the content structures within the site inherit permissions from the site collection. For example, when you create a new site using the Team Site template (see Chapter 4), all the apps in the site inherit permissions from the site collection. The default permissions configuration for a site collection is as follows:

• The Site Owners, Site Visitors, and Site Members groups are created.
• The primary and secondary site collection administrators are added to the Site Owners group. These administrators are specified when the site collection is created.

The site collection administrator takes responsibility for planning the permissions. If desired, the site collection administrator can delegate the responsibility of implementing the permissions to the Hierarchy Managers group in publishing sites. In team sites, the owner has to create a new permission level that confers the Manage Permissions permission to those individuals and groups assigned to it.

SharePoint also provides the following set of specialized administrative groups for sites based on publishing templates that enable the site’s owner to delegate responsibility:

• Approvers: Enables Approve permissions, which allow users to approve items and override document check-outs.
• Designers: Grants permission to change the look and feel of sites with style sheets and themes.
• Translation Managers: Grants permission to change the translated text of a page. This role works in conjunction with the translation features, which are part of the Publishing Infrastructure Feature.
• Hierarchy Managers: Enables Manage Hierarchy permissions, which makes it possible to manipulate the site’s hierarchy and customize lists and libraries.

In addition to providing several kinds of administrative roles, SharePoint 2016 provides the following groups for restricting access:

• Everyone: Enables access for every SharePoint user.
• Excel Services Viewers: Enables users to view Excel documents in a page. This is required so that the page they are viewing can read the Library app where the Excel document is located.
• Quick Deploy Users: Moves content from one server to another, such as from a staging server to a production server. Available only when Publishing Infrastructure Feature is active.
• Restricted Readers: Enables users to view only items and pages but doesn’t show any item history.
• Style Resource Readers: Enables users to read from the master page gallery and style library. Available only when Publishing Infrastructure Feature is active.

There are a number of other specialized groups to choose from in addition to the primary groups mentioned here. You can view all of the groups in your site by clicking on the People and Groups link in Site Settings. You will see a list of groups in the left hand navigation. Clicking the More link at the bottom loads all of the groups into the main page so you can read about the group. Figure 14-2 shows common SharePoint groups, their permission levels, and their permissions.

Securing a site collection

After you know how to add new users and domain groups to a SharePoint group, finish setting up security for a site collection by doing the following:

1. Add user accounts or domain groups to the Site Visitors group.

   The Site Visitors group has Read permissions, which enables this group to view the site collection’s content.

   We suggest you add the Authenticated Users domain group to the Site Visitors group. This enables all your network users to access your site collection (assuming you want to allow them, of course).

2. Add user accounts or domain groups to the Site Members group.

   Members of the Site Members group have Contribute permissions, which allow them to add content to the site collection.

3. Add users to the Hierarchy Manager and Designers groups in publishing sites.

   You may want to create a separate permission level for consultants. SharePoint team sites don’t have these groups by default, but you can create similar groups if you need that kind of role.

4. Configure unique permissions for content structures in and below the top-level site.

   You have to stop inheriting permissions from the top-level site before you can create unique permissions for subsites and apps. See the section, “Creating unique permissions for a subsite,” later in this chapter, for details.

5. Add subsites to the main site collection site.

   You can inherit permissions or use unique permissions when you create the site.

Remember that everything in the site collection inherits from the site collection by default. Make sure your site collection permissions don’t grant too many people access.

Creating unique permissions for a subsite

You must be in a subsite to create unique permissions; the following steps don’t make sense otherwise.

To stop inheriting permissions in a subsite from a parent site, follow these steps:

1. Browse to the Site Permissions page for a site by clicking the Settings gear icon and choosing Site Settings and then clicking the Site Permissions link in the Users and Permissions section.

   The Site Permissions page is displayed with a message reading This website inherits permissions from its parent (<parent site name>). If you wish to change permissions for the entire site collection, click the <parent site name> link.

2. Click the Stop Inheriting Permissions button in the Permissions tab on the Ribbon.

   A message window appears reading, in part, You are about to create unique permissions for this website.

3. Click OK.

   The Set Up Groups for this page is displayed. Choose the groups you want to use in the site. By default, the page uses the groups from the site collection.

4. If you need your own groups for this site, then you should select the Create New Group radio button.
5. Set groups for Site Visitors, Site Members, and Site Owners by selecting an existing group from the drop-down list.

6. Click OK to create the new unique groups for the site.

   The main home page for the site reloads, and your site now has unique permissions. Repeat Step 1 to return to the Site Permissions page. You see that there is now a This website has unique permissions message. Any permissions changes you make on this site are now unique to this site. No other sites in the site collection will be affected.

Be careful about adding users to SharePoint groups at the site or app level. You’re actually adding users to the entire site collection group. Individual subsites and apps don’t have their own SharePoint groups. This behavior causes a great deal of confusion. To drive the point home, do the following. When you stop inheriting site permissions and are on the page, to set up groups (Step 4 in the preceding list) choose to create new groups for the site. After you have finished, go to the Site Permissions page for the site collection. You see the groups you created in the site are in the site collection. This is because all groups in SharePoint are located at the site collection level, even if they are only used by a subsite that is set to use unique permissions.

To reinherit permissions from the parent site, choose Inherit Permissions in Step 2. Any changes you’ve made are discarded, and the site inherits the parent’s permissions.

After you stop inheriting permissions, the parent’s permissions are copied to the site.

Be extremely careful when deleting groups and permissions! If you are in a site that is inheriting permissions and you delete a group, you are actually taken to the site collection to delete the group. We have seen highly trained IT administrators make this mistake and wipe out the entire permission structure for the entire site collection. Before you delete a group, make certain that your site isn’t inheriting permissions and you’re not deleting all the permissions at the site collection level by deleting the group at the site level.

Removing existing permissions

Follow these steps to remove existing permission assignments:

1. Browse to the Site Permissions page for a site by clicking the Settings gear icon and choosing Site Settings and then clicking the Site Permissions link in the Users and Permissions section.

2. Place check marks next to the permission assignments you want to remove.

   Remember to leave yourself with permissions; otherwise, you won’t be able to access the site.

3. Click the Remove User Permissions button, and then click OK to confirm the deletions.

   All the permissions are deleted for the selected permissions assignments.

Creating unique permissions for an app or document

Allowing a site’s content structures to inherit permissions from the site is usually sufficient. Don’t try to secure everything individually. But at times, you need to secure a folder in an app or limit access to an app. You may want to delegate ownership of an app, thus pushing administrative responsibilities for the app to an app administrator.

To manage permissions, the user must have the Manage Permissions permission. You must be a member of the Hierarchy Managers group to edit permissions.

To create unique permissions for an app, follow these steps:

1. Browse to the app, click the Library or List tab of the Ribbon, and click the Library or List Settings button in the Settings group.

2. Click the Permissions for This Document Library link in the Permissions and Management section.

   The Permissions page appears.

3. Manage the permissions as you would for a subsite by breaking inheritance and managing the permissions uniquely for the list.

   Managing permissions on apps is the same as managing permissions for subsites — see the earlier section, “Creating unique permissions for a subsite.”

You can also give unique permissions for an individual document, folder, or list item. You do this by sharing the particular item with a person and selecting their level of permissions in the Share dialog box. Accessing the Share dialog box depends on the item you are sharing. For example, you can share a site by clicking the Share button in the upper right corner of the screen. Alternatively, you can share a document by using the Share button located in the ellipsis next to that document as outlined in the next procedure.

With SharePoint Online, you can even share a document without requiring the other person to log into your SharePoint site.

Follow these steps to give permissions for a document, item, or folder in an app library:

1. Browse to the app where the item, document, or folder is located.

2. Click the ellipsis next to the item and click Share, as shown in Figure 14-3.

   The Share dialog box appears.

3. Enter the name, email address, or group, and then select the permission you wish to give — Can Edit or Can View.
4. Click the Share button to give permissions.

For an item in a list app, the process is a bit different. For individual list items, you manage permissions separately in much the same way you would for a subsite. To access the permissions for the individual list item you want to manage, click the ellipsis next to the item and choose Manage Permissions from the Advanced drop-down. However, you cannot share out list items individually like you can actual documents because the list item is part of SharePoint, whereas the document is a file unto itself.

Managing permissions scenarios

Managing permissions is tricky, and the steps we outline in this section are our recommendations. These aren’t the only ways to manage permissions. Try a scenario to help you better understand permissions. Assume you have a site with the SharePoint groups we outline here.

Everything in the site inherits from the top-level site. In this scenario, those in the Site Members group have Contribute permissions, whereas those in the Site Visitors group have Read permissions.

Assume you create a new subsite, and you only want your Site Members to access it. You don’t want Site Visitors to even know the subsite exists. In this case, you create unique permissions on the subsite and remove the Site Visitors group.

Assume you have an app for policy documents, and you want John and Sally to have Contribute permissions. We recommend creating a new Policy Reviewers SharePoint group at your top-level site and then adding John and Sally as members to the group. You aren’t done here, however. You haven’t actually granted the group permission to anything yet. You have to browse to the app, break inheritance from its parent, and then grant the Policy Reviewers SharePoint group the Contribute permission level.

Why not just add John and Sally to the app and grant them the Contribute permission level? That approach will certainly work, but it’s hard to manage. That approach obscures that John and Sally have some permissions granted outside the context of a SharePoint group. We like to be able to look at our SharePoint groups and have a good idea of what the role of that group is, based on their names on the site. If you start adding users individually to subsites, apps, documents, folders, and items, it becomes difficult to get a big-picture view of how your permissions for the site are configured.

Viewing a group’s permissions

You can easily check the permissions for a given group to see everything that group has been granted access to in your site. You must repeat these steps at each site in your site collection. To do so:

1. Browse to the top-level site in your site collection.

2. Open the People and Groups page for the top-level site by clicking the Settings gear icon and choosing Site Settings, and then clicking the People and Groups link in the Users and Permissions section.

   The list of SharePoint groups appears on the Quick Launch.

3. The list of groups is truncated. Click the More button at the bottom of the listing of groups in the Quick Launch.

   The list of all SharePoint groups in the site collection appears in the main part of the page.

4. Click the name of the group for which you want to view permissions.

5. Choose Settings ⇒ View Group Permissions.

   The View Site Collection Permissions window appears, as shown in Figure 14-4. All the sites, lists, and libraries that the group has permission to access appear in the list.

Everyone who is a member of the group has the permissions shown on the View Site Collection Permissions window.

Checking a user’s permissions

Sometimes, you just want to know who has permission to do what in a given site. SharePoint 2016 provides just such a method:

1. Browse to the site where you want to check a user’s permissions.

   This command only checks permissions within a single site. You have to check each site manually.

2. Browse to the Site Permissions page for a site by clicking the Settings gear icon and choosing Site Settings, and then clicking the Site Permissions link in the Users and Permissions section.
3. Click the Check Permissions button on the Ribbon.

4. Enter the name of the user or group whose permissions you want to check for the current site in the User/Group field, and then click the Check Now button.

   The permissions appear in the bottom of the window, as shown in Figure 14-5.