Tải bản đầy đủ - 0 (trang)
SharePoint Groups vs. Active Directory Domain Services Groups

SharePoint Groups vs. Active Directory Domain Services Groups

Tải bản đầy đủ - 0trang

Managing Access in SharePoint

❘ 275


It is possible that you could have various AD DS groups that do not work within

SharePoint. In many cases this has to do with the groups having references that

cross multiple AD DS structures. It is a best practice for you to work with your

organization to determine which approach will be best for you within SharePoint.

Understanding how your organization manages AD DS will help determine if you

should be using AD DS groups or SharePoint Groups.

Navigating the User Permissions Pages

Managing permissions can often be a difficult task, especially if you are a new site administrator.

As you completed the preceding Try It Outs, you probably noticed that you

were navigating between several different pages. So far, all the examples

have been focused on specific scenarios. This section switches the focus

to each of these pages that exists for managing Users and Permissions. By

reviewing these pages, you should gain a high-level understanding of how

to navigate as you complete additional scenarios for managing permissions.


The pages that you review in this section are in the Users and Permissions

section of the Site Settings page, as shown in Figure 9-14.

People and Groups

The People and Groups pages provide a way to view all of the groups that

exist within the site. By selecting one of the groups in the Quick Launch

bar, you can view all of the members of the group. From this screen you

can also add and remove members from the group. By default, the most

common groups are listed in the Quick Launch bar and the top group

listed is selected when the page loads. To see a group that is not displayed

on the Quick Launch bar, select the More option below the groups

(see Figure 9-15).

Selecting this option takes you to the People and Groups listing. From this

page you can create new groups using the

New menu, and modify what groups are

displayed by default on the Quick Launch

bar by using the Settings menu. Figure 9-16

shows an example of the Settings menu

with the option to display groups that are

displayed on the Quick Launch bar.



Site Permissions

The Site Permissions link on the Site Settings page takes you to the central hub for managing

permissions within your site collection. If you are new to managing permissions within SharePoint,


c09.indd 275

1/28/2013 7:24:00 PM



it is recommended that you start with this page fi rst. In most cases, as you select items from the

menus on this page, other pages discussed in this chapter are opened for you. By having separate

links, you have the option to quickly go right to the location you know you need. However, if you

are new to managing a site collection it will likely be easier for you to work with this page and let it

help you navigate to the other pages. An example of this page is shown in Figure 9-17.


From this page you can complete the following administrative tasks:

Grant permissions

Create new groups

Edit user permissions

Remove user permissions

Check permissions

Manage permission levels

Manage access request settings

Manage site collection administrators

You have completed many of these tasks in the Try It Out exercises within this chapter. Although

this page provides a summary of the most common actions for managing permissions, you will

realize that as you start to navigate from this page it is just directing you to the other management

pages that exist for permissions. For instance, if you select one of the groups listed on this page,

you will open the Users and Groups page with the group you selected as the default group. From

that page you can then complete the required management tasks. This is just one of many examples

within SharePoint of how navigating through two different options can still lead you to the same

settings page. At the end of the day, it doesn’t matter how you navigate to the page; it only matters

what you do once you are on the page.


c09.indd 276

1/28/2013 7:24:01 PM

Items That Can Have Permissions Applied

❘ 277

Site Collection Administrators

From this page you can manage all of the users who are Site Collection Administrators. These users

have full control of all content within the site collection. You can give multiple users this level of

access; however, it is important that you understand the implications of granting this access level.

If you give many users full control, it will quickly become difficult to manage and maintain any

structure within the site. If everyone has full control, they have the ability to use the site as they

please without limitations.

Site App Permissions

This page exists so that you can set the permissions for the various apps that you install from the

SharePoint Marketplace. When you install an app, specific permissions are granted to that app,

based on how it is designed. If you need to remove those permissions at a later date, you would do

so from this page.


Everything you have done so far has applied to the entire site collection. By default, this is how

permissions work for each site collection. Items are managed at the site-collection level (the parent),

and then all the contents below (the children) inherit the permissions. SharePoint supports a unique

permissions configuration in which the child item stops inheriting from the parent and takes on its

own permissions. This means that you can have a site collection (parent) with multiple document

library apps (children), each of which has its own unique permissions. Although a user may

contribute to his team’s collaboration site, he may have read-only rights for a particular document

library or even a single document in a library. This section discusses the different levels of access

that you can have on a SharePoint site.

Site Permissions

Site permissions apply to the subsites that you create within your site collection. With the creation of

each new subsite, you will need to choose if you would like the subsite to inherit the permissions

of the parent site or if you would like to configure unique permissions. Your decision generally

depends on your requirements:

Inheriting permissions: When you allow a subsite to inherit permissions from a parent site,

you create a scenario in which any user who has permission to the parent site will have

the same permissions and rights on the child site. This cuts down on the tasks and effort

associated with managing permissions and creates a consistent access experience for all


Creating unique permissions: Creating a site with unique permissions enables you to

manage permissions and access to your child site, independent of the settings specified for

the parent site. Therefore, a user who can add content on the parent site may not necessarily

have access to the child site. Users perform different roles from site to site. This means


c09.indd 277

1/28/2013 7:24:01 PM



that you’ll have to spend more time setting up and managing the site, but you will have

greater flexibility in meeting the access requirements of each individual team. Sometimes it’s

beneficial to give users greater access rights on a subsite than they have on a parent site. For

example, in a sales proposal workspace, members of the sales team may be able to create

lists and libraries to aid in their production of the proposal, whereas on the sales team site

they may only have permissions to add content to existing lists.


Stop Inheriting Permissions from a Parent Site

You may have created a site and selected the option to inherit permissions from the parent, but at a

later time, realized you needed to manage the site’s permissions independently of the parent site. The

following example uses the project site that you created in Chapter 2, “Working with List Apps,” and

assumes that the site has different usage requirements than your main intranet site. You change the

permissions settings on the existing site, which copies all permissions settings from the parent into the

project site so that you can manage them separately.

Remember that if users have permissions on the parent site and you do not want them to have access

to the project site, you must remove them after breaking the inheritance because SharePoint copies the

permissions, groups, and users from the parent into the child. You wouldn’t have to do this if you had

opted to create unique permissions when you fi rst created the site. In that case, once the site is

created, it has a blank set of permissions, and no users of the parent have access to the site unless

explicitly given access. The exception, of course, is a site collection administrator or site owner on the

parent site.

NOTE If you did not complete the exercises from Chapter 2, you can create any

subsite on your site collection that inherits the permissions of the parent. The

same steps apply regardless of what site template you use.


From the main page of the subsite site, select Site Settings

from the Site Actions menu.



Select Site Permissions.

Click the Stop Inheriting Permissions option on the ribbon,

as shown in Figure 9-18.



You receive a warning message. Click OK to confi rm your



A page is displayed prompting you to set up the groups for the site. You can choose to use existing

groups from the site collection or create new groups. In this example, choose to create three new

groups, as shown in Figure 9-19. Click OK.


c09.indd 278

1/28/2013 7:24:01 PM

Items That Can Have Permissions Applied

❘ 279




Using the Site Actions menu, navigate to the Site Settings page.

Notice that the site now contains the new groups that you created in step 5, along with all the

permissions from the parent site. You can now delete the permissions that came from the parent

site without impacting the parent site.

How It Works

Once you selected the option to stop inheriting permissions, the users, groups, and permissions from

the main intranet site were copied down into the project site. You can now make additional changes

such as removing groups or adding users. Any changes you make to the project site will not have any

impact on the main intranet site.


c09.indd 279

1/28/2013 7:24:01 PM



List or Library Permissions

Sometimes a list or library on a team site requires a different set of permissions than the rest of the

site. For example, a document library containing sensitive fi nancial performance reports should

not be shared with everyone who has access to the site. You could create a separate site to store this

information, but it’s easier to simply adjust the permissions on the library so that a subset of users

can access it. Another example is where only certain users can edit a specific list or library in which

team members can only view content. For example, only a manager can create new items on an

Announcements list for a team, but team members can contribute to the other lists and libraries in

the site.


Assigning Unique Permissions to a List

In this Try It Out, you modify the permissions on a Site Pages library so that only members of the

Owners group can create new content. Even though all other site members can add content to other

lists, it is important that you restrict the pages to allow only members of the Owners group to add new

items. To accomplish this, you must stop inheriting permissions on the Site Pages list from the site.

Similar to the scenario in the previous Try It Out, when you stop inheriting permissions for a list from

a site, all rights are copied from the site into the list, so you must update the settings to reflect your

requirements. For this exercise, you use the subsite from the preceding Try It Out, which has unique

permissions from its parent.







From the main page of your subsite, select the Site Contents link from the side navigation menu.

Open the Site Pages list by clicking the icon next to the title.

Select the Library Settings option from the Library tab of the ribbon.

Select the “Permission for this document library” link. You are redirected to the Permissions

management page for the list.

Select the Stop Inheriting Permissions option from the ribbon.

You receive a warning message. Click OK to confi rm your action. The page refreshes, and a

yellow message bar appears at the top of the screen indicating that the list has unique permissions,

as shown in Figure 9-20.



c09.indd 280

1/28/2013 7:24:01 PM

Items That Can Have Permissions Applied


Select all groups except the Owners group, and click the Edit User Permissions option on the




Select the Read permission level.

❘ 281

Click OK. You are returned to the library permissions page, and you should see that the

permissions for the different groups have been updated. Figure 9-21 is an example of

the updated permissions settings.


How It Works

When you disconnect from the permissions of the site, all rights and users are copied to the permissions

scheme for the Site Pages library. Therefore, you must edit the rights of each group and user so that they

can only read items. You selected every group except Owners and changed their rights to read-only.

Item Permissions

By default, access to an individual list item is inherited from the list or library in which it resides.

However, you may need to better defi ne this. For example, storing a policies and procedures

document within a team’s shared Documents library means anyone can contribute to it by adding

items or modifying existing items; however, for legal reasons, only certain managers should have the

right to edit it. You can restrict access to one document, even if it resides in a list or library to which

everyone has access, as shown in the next Try It Out.


Assigning Unique Permissions to a Document

In this Try It Out, you create a new document and restrict the rights so that only members of the

Owners group have access to edit the document.




From the main page of the team site, select Documents from the Quick Launch bar.

Click the New Document option on the Document tab of the ribbon.

Save the document with a fi lename of Team Policies and Procedures.docx.


c09.indd 281

1/28/2013 7:24:01 PM




Select the ellipsis next to the document title and then in the information screen to open the menu.

From the menu, select the Shared With link, as shown in Figure 9-22.






The Shared With page is displayed and shows you all the users that have access to the document.

Click the Advanced option to view the manage permissions page for the document.

Select the Stop Inheriting Permissions option from the ribbon. The page refreshes and a yellow

message bar appears at the top of the screen indicating that the site document has unique


Select all the groups that you want to remove access for and click the Remove User Permissions

link in the ribbon.

How It Works

In this example, you created a new document that had slightly different requirements over all other

documents in the library. Rather than place it in a unique location, it’s far more effective to manage the rights

of this document independently of the library and make the required changes on an item-by-item basis.


c09.indd 282

1/28/2013 7:24:01 PM

Items That Can Have Permissions Applied

❘ 283


SharePoint list applications have a feature, not available within document applications, that allows users to have access only to the content that they have authored.

You configure this feature in the advanced settings for the list and it applies to all

items in the list. This is a great alternative to managing item permissions.


Customizing Item-Level Access Rights on a List

You can uniquely apply permissions to documents or list items in the same way as in the previous Try

It Out. However, lists also have a unique function that allows a site manager to determine if users can

view or edit their own items or the items of others. For example, it may be helpful to allow team members to view each other’s appointments. However, a user should not be allowed to edit appointments

that belong to a coworker. In the following example, you modify the default settings of the Calendar

list so that users can view, but not edit, a coworker’s items. You can do this on SharePoint lists but not

with documents stored within document libraries.


From the main page of your team site, select

Calendar from the side navigation menu. If

your site does not have a calendar list, you

will need to fi rst create one before fi nishing

this exercise.


Select List Settings from the Calendar tab of

the ribbon.


Select Advanced Settings. The Advanced

Settings page for the list appears, as shown in

Figure 9-23.


In the Item-level Permissions section, under

Read access, keep the default value of Read

all items.


In the Item-level Permissions section, under

Create and Edit access, select “Create items

and edit items that were created by the user.”


Click OK.


How It Works

In this example, you used some of the advanced list configuration options that allow for item permissions that can be managed at the list level. This keeps you from having to apply custom permissions to

each item in the list.


c09.indd 283

1/28/2013 7:24:02 PM



Understanding the Share Option

Within SharePoint 2013 is a new feature that allows users to easily share content with others. This

enables a more self-service type environment where users are directly able to proactively bring

others to content so that they can collaborate together. In earlier versions of SharePoint, users had

to contact the site administrators and ask them to give others permission to the site or to specific

content within the site. In SharePoint 2013, users, regardless of their permission levels, can share the

site with others, as long as the site is configured

to allow for Site Access Request. The users who

have enough access to manage permissions can

assign permissions directly from the share link,

but those who don’t have elevated permissions

are really just submitting a request to share the

content to the site admin. The site admin can

then approve or reject the request. When a site

admin approves the request, the user who was

invited to share the content will receive the

request from the initial user who requested the

share permission. Figure 9-24 shows the Share

dialog box that appears when a user selects the


share link from the homepage.

Once the share request has been submitted, the user assigned to manage the access requests will

receive an e-mail notification that a new request has been made (see Figure 9-25).


From this e-mail the request can either be approved or denied. Within the site, the request can also

be managed from the Access Requests and Invitations link in the Users and Permissions group

of the Site Settings page. From this page the site administrators can see all the requests that have

been made and, with one click, approve or decline them. If the site administrator has any questions

concerning the request, he or she can simply add a message to the request and the requestor will be

notified of the message and given a chance to respond. These features are displayed in Figure 9-26.


c09.indd 284

1/28/2013 7:24:02 PM

Items That Can Have Permissions Applied

❘ 285


Figure 9-26 shows the history for a single request and is displayed whenever the ellipsis is selected

next to the request. Figure 9-27 shows an example of an Access Request history for a site collection.

This history keeps a full record of the request comments as well as who approved the request. By

default, the History portion of the page is hidden, but you can easily show it by selecting the Show

History link at the bottom of the page.


Sharing is a concept in SharePoint 2013 that can occur at multiple levels, including sites, lists, and

list items. By enabling these features, you are empowering users to take a more proactive role in

working with others because they can quickly and easily share content. Because the requests are still

processed through the site administrator, you can be assured that best practices in site management

will still be followed. This is a great example of empowering users while maintaining control within

the environment.


c09.indd 285

1/28/2013 7:24:02 PM

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

SharePoint Groups vs. Active Directory Domain Services Groups

Tải bản đầy đủ ngay(0 tr)