Sharepoint 2013 : Security and Policy - Web Application Policies

Site collection security, provides nice granular control of user access to the site collection, sites, lists, and even list items. However, sometimes an administrator needs to grant access to users for an entire web application. SharePoint provides this capability via the Central Administration web site.

1. Open Central Administration.
2. Click the Security heading from the home page.
3. From the Users section, click Specify Web Application User Policy.
4. SharePoint shows a page like that in Figure 1.

   

   Figure 1. Web application security policies

The page, shown in Figure 1, displays a list of current user policies for the selected web application in the drop-down on the far right. Notice the strange user names, like i:0#.w|robdev\sp_admin, which is how SharePoint stores user identity as part of the Claims-Based-Authentication model.

1. Ensure that you select the correct web application (top right).
2. Click Add Users from the sub-menu.
3. From the next page, choose the desired zone or all zones if you want the new policy to apply to all security zones for the application.

   Note  SharePoint maintains four zones for each web application: Default, Custom, Intranet, and Internet. The labels are not important but help administrators assign policy for typical purposes. The drop-down that appears in step 3 shows only those zones in which the administrator has configured an authentication scheme (Windows, Kerberos, or Claims-Based).

4. Click the Next button.
5. Enter the users or AD groups in the Users box; then click the tick icon to validate the entered text, or click the book icon to choose users via the people picker dialog (Figure 2) .

   

   Figure 2. People picker dialog in the Web Application Policies page

6. Select the appropriate permissions—this is the only place in the SharePoint security model where an administrator may deny access rights. This feature comes in handy if an administrator needs to revoke access for users in the web application, without editing the permissions in site collections.
7. You may choose to operate the account policy as System, meaning the account does not show up in user information lists (it’s effectively hidden).
8. Click the Finish button to enact the policy.

Returning to the web application security policies, shown in Figure 1, you see a big bold message at the top of the page about search crawling. Changing the security policy for a web application instructs SharePoint to execute a full search crawl—this is to ensure security trimming of content per the policy and permissions assigned to all users. For example, if you create a new security policy to deny a user access to content in all site collections hosted by the web application, then that user should not see this content in search results. Making multiple changes to the web application security policy might add strain on your environment if these changes cause a search crawl during busy usage periods. The information message recommends applying web application policies to security groups; thus, adding users to and removing users from the group avoids a full search crawl.

Also on the Web Application Security Policies page are some links (top left) to change policy for anonymous users and to change the permission levels for policy. Similar to how you grant or deny access to specific users for the entire web application, you can perform these actions for anonymous users. Thus, if you want to deny access to all anonymous users without turning off anonymous access, you can add a policy to deny access at the web application level.

The link to manage permission policy levels takes you to a page that lists all permission levels for web application security policy (Figure 3). Similar to permission levels for site and site collections, the available permission levels for web application security policies reflect typical groupings of permissions for a specific role. You can add your own permission levels to apply as policy to the web application, and change the existing permission policy levels, but this is not recommended; it is always best to create your own permission levels.