Within this post, we will discuss the common question of “How do you deny access to users in SharePoint?”
A common problem for administrators is ensuring all of their users have access to the resources they need while at the same time preventing users from accessing what they should not have permission to. Below I will include an example of a bad practice that some administrators use as a solution to this problem.
In this example the administrator takes advantage of the fact that in SharePoint places “Deny” permission settings at a higher value than “Allow” permission settings. So that when they have all users set to have access to a particular site collection and only want to deny access to a select few users to one area within the collection they can just set a deny access for the users in question rather than removing them from the group and having to re-add all of their permissions to the rest of the site collection. While this may seem like a simple solution at first, continuing to use this method over time will result in a security policy riddled with exceptions as the site collection grows, new users are added and existing users move between roles.
A better solution is to increase the division within a farm from the start while never giving users access to areas where they do not need it. For example, separate site collections could be made for each department within a company with users only given access to the one for the department to which they belong. If users require access to a single page within a site collection or web application, such as a landing or new page, then permission inheritance for all subsites beneath it must be broken.
Another situation in which it is tempting to Deny a user access is if they have access to a web application through their membership in multiple user groups. While it is possible to specifically deny access to an individual user overriding their rights from user groups using the Central Administration, this again leads to a situation with a security policy full of exceptions. It is better to review whether the user in question does need to be blocked from the web application and if so why they were added to user groups that allowed permission to begin with.
In some cases, you may want to completely remove the permissions of a user account, but still keep the account in SharePoint. For example, when an employee leaves a company but you want to keep their mailbox open to ensure that anything sent to them is still received and collected. In this case you can use the check permissions function of SharePoint to find which areas the user has permission to and remove those rights. If after all of their SharePoint permissions have been removed the user still has access to some areas you should check whether they are a member of any AD permission groups.
Third party web parts, such as DeliverPoint, can help in the permissions management of SharePoint environments, especially when there is a large number of users. Such web parts can resolve the shortcomings of SharePoint’s native functions when it comes to handling permissions for multiple users at once.
<Joseph/>
