A Practical Guide for SharePoint Site Collection Security

As your Administrator may or may not know, security in SharePoint 2010 is ‘typically’ guided by Global Groups and User accounts from within Microsoft Active Directory (AD) domain infrastructures. These are in turn ‘typically’ made members of SharePoint Groups which govern the hierarchical elements of SharePoint. This hierarchy has a ‘flow on effect’ or ‘trickle down approach’ of inheritance by default. Therefore, if you set security at one level of the SharePoint tree, any elements beneath it will inherit those security values. This allows for simple allocation of users and groups to resources by centrally maintaining your core directory services and SharePoint resources. The great thing is we can vary this inheritance by disabling it at many levels within the tree and starting inheritance from scratch.

The issue you can experience here is that by following the methodology above, many SharePoint administrators will allocate the Default Domain Users or Authenticated Users group which is populated with every user account in your Active Directory domain to Default SharePoint Groups like the Visitors group at the Site Collection level. This SharePoint group has read access to any and all SharePoint resources it is associated to within the SharePoint hierarchy starting from that site collection and trickling down to all of its associated child elements.

The question posed here by the client was what if there was a group of people within our organisation who we do not want to view and read the Site Collection but we still want to maintain their use within the traditional Active Directory Global Group ‘Domain Users’ for ease of use?

How do we solve this?

Typically for a SharePoint site, we should only add SharePoint groups and groups/users from our Active Directory domain to that Site with a corresponding permission level assigned for that Site and any subsidiary elements. If there is an element below the site that we need to restrict further then we need to break inheritance and assign permissions uniquely at that level as mentioned previously. This top-down approach to security is essential to good SharePoint security and one to pass on to all SharePoint object creators. In my own words, ‘Put security in-place at Creation’.

As it is quite likely that some of the SharePoint groups for many SharePoint Portals would include the Domain Users AD groups, all user accounts you want to restrict from your SharePoint infrastructure would need to be removed from these default groups. This is generally not feasible as other systems would be dependent on these accounts being in the ‘Domain Users’ group. Another method would be to list all departmental groups – IF and only IF these groups covered the entire organisations SharePoint portal audience. Therefore, a heavy reliance upon a well maintained AD environment is essential (it is in general as well).

Solution:

Well how can we solve this? Glad you asked. Rather than modify the SharePoint group membership from the Central Administration site in SharePoint we can specify a DENY ALL policy at that level for any user or AD group.

I recommend that you create a ‘ Deny Access’ AD security group populated with the users and\or groups who should not have access.

After this the SharePoint Administrator can use this procedure to modify the web application policy which sits above the Site Collection hierarchy as its parent:

1. Make sure the above Deny Access ad Group is created and populated in AD.

2. Open Central Administration

 

3. Under the Application Management section, click on Manage Web Applications

4. Click to highlight your Web Application, e.g.. portal.synergy.com

5. Click User Policy from the Web Applications Tab in the Ribbon.

 

6. Click Add Users, leaving (All Zones) as the default drop down box, click next.

 

7. Add the ‘ Deny Access’ AD security group that you would like to deny access to this Web Application.

8. Choose Deny All as the permissions that will be assigned to them. Note: this can be varied.

9. Click Finish.

These users will now be shown ‘Access is Denied’ from any sites contained in this web application even though they have permissions wherever their group membership is defined as Deny permissions override Allow permissions.

After this has been setup you can control who is denied access to your SharePoint Portal by maintaining the membership of this group. As a tip remember that AD Security Groups can be nested. Granting access to the areas of the Portal is controlled by the membership of the SharePoint groups.