IT tutorials

Sharepoint 2013 : Security and Policy - Granting Permissions (part 1) - Granting Permissions at the Root Site Collection, Permission Inheritance

11/27/2014 8:33:53 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

I have established how SharePoint handles groups of related permissions within permission levels, reviewed basic user identity, and discussed security groups and best practices in using them. In this section I discuss granting of permissions (via permission levels) to groups of users for specific securable objects (sites, lists, pages, list items, and so on) in a site collection.

Granting Permissions at the Root Site Collection

The following steps detail granting permissions at the root site in the site collection:

  1. Click the gear icon from the root site in the site collection.
  2. Click the Site Settings menu item.
  3. Click the link for site permissions, under the Users and Permissions heading.
  4. Click the Grant Permissions icon on the ribbon.
  5. SharePoint displays the share dialog (remember, sharing and granting permissions to users or groups are synonymous in SharePoint 2013).
  6. Provide the name, username, or e-mail address of users to assign permission.
  7. Click the link to show options.
  8. Select the group or permission level to assign for the specified users—selecting a group adds the users to that security group; selecting a permission level assigns the users this permission level for the site collection.

Note  SharePoint treats AD groups or ASP.NET role provider identities as users. Thus, you can assign an AD group or ASP.NET role provider role a particular permission level or add it to a SharePoint security group, and all users of the AD group or role provider role have access to the site collection based on the permission level assigned or SharePoint group they belong to.

Permission Inheritance (and Breaking It)

Granting permissions to users or AD groups for a subsite is identical to the procedure shown in the previous section, “Granting Permissions at the Root Site Collection”—as long as the subsite breaks inheritance. Permission inheritance is an important topic and worthy of a mention here.

Every subsite belongs to one parent site, and the root site of the site collection is special because it has no parent site. Every list or document library resides within a site or subsite. You can quickly see that nested subsites chained together create a tree hierarchy: your site hierarchy. Your site hierarchy is analogous to that of a folder structure in a file system, where sites are synonymous with folders. Similar to file and folder structures, you can assign default permissions for users or groups of users to the top-level site (the root site) and all subsites in the tree inherit the permissions from the parent site. For example, if all subsites inherit from their parent, and I assign my user identity collaboration access via the collaboration permission level, then I have collaboration permissions across the entire site collection hierarchy.

Permission inheritance does not stop at the site level—lists and libraries also inherit permissions from their container site (by default). Thus, in the previous example, I have collaboration access to all lists and libraries in each subsite.

If you can simply grant permissions at the top of a site collection, why bother with permissions for subsites, lists, and libraries? The situation may arise in which the default permissions do not work at a particular level in the hierarchy. For example, you might grant collaboration access across the site collection, but the accounting subsite requires special consideration and only members of the accounting SharePoint group have access. In this case, you would “break” inheritance at the accounting subsite and then assign discrete permissions for the accounting security group.

As a general rule of thumb, it is a good practice to assign permissions at the site collection level that reflect the general populous, and then break inheritance for specific circumstances. For example, if your site is an intranet then perhaps you want generalized read-only access for all users across the site collection (except site collection administrators who have full control) and then will grant specific Write or Collaboration permissions for certain subsites. Contrary, if your site collection represents a collection of project sites, to which everyone has collaboration rights, then it makes sense to grant collaboration rights to the site collection and then restrict rights to particular subsites that do not fit the generalized rule.

The following steps demonstrate how to break inheritance for a subsite:

  1. Navigate to the subsite where you wish to assign unique permissions (break inheritance).
  2. Click the gear icon and then choose the Site Settings menu item.
  3. Click the link for Site Permissions under the Users and Permissions heading.
  4. SharePoint displays a page like that in Figure 1.


    Figure 1. Site permissions

  5. Notice the helpful information panel in yellow—SharePoint 2013 tells you if you have any lists, libraries, or list items that have unique permissions (i.e., broken permission inheritance further down the chain).
  6. In my example, my subsite inherits permissions from the parent, but I have a micro-feed list in the site that has its own unique permissions. (Click the link in the yellow information box to see content with unique permissions.)
  7. Click the icon on the ribbon to stop inheriting permissions.
  8. SharePoint now copies all the permissions of the parents and assigns them as copies to the current subsite.
  9. You may now change the existing permissions of the subsite and/or grant new permissions.
  10. To revert back to inheriting permissions, click the icon to Delete Unique Permissions.

Note  If you find yourself breaking permission inheritance often, to prevent user access, then this suggests that you have too many permission rights applied further up the hierarchy. The best practice is to apply restrictive permissions higher up the chain and less restrictive permissions in specialist sites deeper down the chain.

- Windows 8 : Networking with Other Operating Systems - Internetworking with Windows 7, Vista, and XP (part 3) - Using Windows Vista and XP with a Homegroup
- Windows 8 : Networking with Other Operating Systems - Internetworking with Windows 7, Vista, and XP (part 2) - Password Protection and Simple File Sharing
- Windows 8 : Networking with Other Operating Systems - Internetworking with Windows 7, Vista, and XP (part 1) - Setting TCP/IP as the Default Network Protocol
- Windows 8 : Networking with Other Operating Systems - Mix and Match with Windows and Macs
- Using the Debugging Tools Available in Windows Server 2012 : Windows Memory Diagnostics Tool
- Using the Debugging Tools Available in Windows Server 2012 : System Startup and Recovery
- Using the Debugging Tools Available in Windows Server 2012 : Other Useful Troubleshooting Command-Line Tools
- Using the Debugging Tools Available in Windows Server 2012 : TCP/IP Tools (part 3) - Route, Nslookup, DCDiag
- Using the Debugging Tools Available in Windows Server 2012 : TCP/IP Tools (part 2) - Pathping, Ipconfig, ARP , Netstat
- Using the Debugging Tools Available in Windows Server 2012 : TCP/IP Tools (part 1) - Ping, Tracert
Top 10
Technology FAQ
- Microsoft ebs security server configuration
- IIs7 on Windows server 2003
- How to Configure Failover Clusters With Win 2008 Server R2?
- Windows 2008 Network Load Balancing
- Windows Server 2008 - Group Policy Management - Remove Computer Management
- Remove shortcuts possibility in a web page or to put in favorite
- HTA Dynamic Drop Down List
- IIS host header and DNS
- VMware or MS Virtual Server?
- Adobe Acrobat 9 inserting tab pages
programming4us programming4us