Our security department has identified some SharePoint 2010 site collections need to restrict to users of some security groups. The requirement is to restrict the users belong to some security groups to access selected site collections with sensitive information even these users have been granted the permission through individual account, any AD groups, or email list groups.
After extensive research and testing, we have found that there is no out of box solution on SharePoint 2010 we could exclude a security group to access some selected Sharepoint site collections. Here are some possible options I would recommend to try to resolve this issue.
1. Siteminder policy configuration to exclude any users belongs to selected groups to access the SharePoint site URL identified.
If you have already integrated the siteminder with SharePoint, you could modify the policy to restrict the groups to access site URLs. As long as you have the groups needed to be restricted and the site URLS, it should be a quick configuration changes.
Since you could provide the root URL and all sub sites will be blocked, the pros of this approach is clean and simple. The sites need to be controlled or protected can be in any webapp. Even users have been added to the SharePoint site, they will not be able to access the site. However, current version siteminder SSO does not support multiple domain AD SharePoint. We have more than FIVE AD domains in our company and it was NOT a solution at this time for us.
2. Configure ADFS Identity provider or other gateway such as Vordel to deny certain group of users to access selected URLs.
If you have implemented ADFS identity provider or other gateway tool such as Vordel to work with with SharePoint, you might work with the team to configure on ADFS or Vordel side to deny group of users to access certain selected sites. The pros and cons are same as described using siteminder.
Since we have identified many issues for SharePoint with ADFS, we have on hiod the SharePoint ADFS implementation early February 2011. ADFS approach is NOT a solution at this time for us. At same time, we are evaluate the Vordel approach and may move to this solution whenever it's available.
3. Configure IIS URLscan tool to block user agents for SharePoint sites
Microsoft strongly recommends that all users upgrade to Microsoft Internet Information Services (IIS) version 7.0 running on Microsoft Windows Server 2008. IIS 7.0 significantly increases Web infrastructure security.The URLScan tool can be used to protect your Web server from attacks and exploits. When a client requests a page from a Web server, it typically sends over some HTTP headers that contain additional information about the request. You mighht use the [DenyHeaders] section to restrict some user groups to access to certain SharePoint sites. You may refer to the discussion for more details.
Based on our observation, this approach may be useful but we may have difficult time to identify the method to filter the certain users. This may not the solution at this time for us.
4. Configure Microsoft Internet Security and Acceleration (ISA) to restrict access
In this session we will use ISA to accomplish this task to restrict the users belong to some security groups to access selected site collections. Here are the steps.
* Create a security group and add users to that group
* Create a new Firewall Policy and a Domain Name Set
* Verify your Firewall rule and fine tune settings.
Please refer to Microsoft TechCenter on ISA for details.
5. Configure user policy at web application level to deny them access to SharePoint sites inside the webapp.
If you do not have siteminder integrated with SharePoint, you may consider to group or migrate all sites need to be controlled or protected to a separate webapp. Then creating a user policy at web application level which denies them access to SharePoint. Here are the steps.
- Click Manage Web Applications
- Click the Web Application you wish to set a deny policy on
- Click User Policy in the Ribbon bar to display the Policy for Web Application dialog
- Click the Add Users link
- Leave the Zones prompt as (All Zones) and click Next to display the Add Users dialog
- Enter the AD group into the Users prompt
- Click the Deny All check box
- Click Finish
This is also very clean process and same as the previous approach the users will not be able to access the site even they have been added to the SharePoint site. This approach is extensible to add aaitional groups need to be blocked to the webapp. However,there are two major issues need to be planned for this approach.
- You may need to migrate sites identified to be protected to the new webapp. This will break the URLs or bookmarks published to other applications. You may implement redirect or alternate access mappings to minimize the impact.
- You may change your site provisioning process so future sites need to be controlled will be provisioned inside controlled webapp.
This may be a good long term solution for us and we may plan to implement this approach.
6. Customize SharePoint access
You might intercept the out of box SharePoint authentication or authorization package to exclude the groups of users to access selected SahrePoint sites. One suggestion provided by Allen Wang is to apply custom master page for this site collection and insert a custom user control near the top of the master page to perform security trimming, or check in the user control. If the user is in one of these group, then redirect it to another page or something....
You will see this might work for the users to access the site directly. However, it may not block users to access the files directly. This is not safe since the users could modify the master page or remove the code from the page.
7. Customize SharePoint Policy Feature
Since we could manage Information Management Policy in SharePoint Server 2010, I'm thinking whether we could implement a policy and apply the policy feature on the SharePoint site to exclude certain users. If anyone think this is feasible, please let me know.
As a result, none of the above options are perfect as we could see at this point. We are exploring other options in Part II and if you have any good suggestions, please let me know.
Thanks for your input.
