After a user is authenticated, you then can authorize that user to view or modify existing content in addition to creating content. SharePoint technologies authorize users at the site collection level, including the Central Administration site collection. For example, you might authorize a user to read documents in a document library, but not grant him or her the ability to change documents. Within a site collection, authorization can be specified on a per-object basis, such as a document or folder.
Site collection administrators are assigned when a site collection is created. There must always be at least one site collection administrator, and this account cannot be an Active Directory group. For reasons such as Unused Site Confirmation and enabling administration in the event that the administrator leaves, it is always best to define at least two site collection administrators. You can view site collection administrators from two different management interfaces:
Central Administration From Central Administration > Application Management > SharePoint Site Management > Site Collection Administrators, select the site collection to manage. The selection menu for the site collection isn't intuitive at first, so be careful when selecting site collections to modify.
If several content databases are associated with a single Web application, the Select Site Collection interface shows the database that a given site collection is in, as shown in Figure 7-6.
Site Collection Settings If you want to add more than two site collection administrators, you must do so from the Site > Site Settings > Permissions > Site Collection Administrators Web page.
Figure 7-6: The Select Site Collection Web page shows the association of content databases and Site Collections.
Permission levels are the building blocks for authorizing users to access or modify objects in a site collection. Permission levels should always be named the same across multiple sites, and you should never modify an existing permission level. Modifying an existing permission level could cause a document, list, or page owner to accidentally grant access to unauthorized users. Always create a new permission level, create a correlating group with the same name, and populate that group with users. Doing this assures you of an easy-to-use permission level and group environment. To create a new permission level, do the following:
Open the site to manage in your browser.
Select Site Actions > Site Settings > Users and Permissions > Advanced Permissions.
From the Settings tab, select Permission Levels, as shown in Figure 7-7.
Select the Add A Permission Level tab.
Enter a name for the permission level.
Enter a description.
Select the required permissions for this permission level and associated group.
Figure 7-7: Select Permission Levels from the drop-down menu.
Remember, the only available permissions are those that are defined in Central Administration > Application Management > Web Application Security.
You should develop a consistent naming convention for permission levels across all site collections. Otherwise, users will not know what permissions are associated with each permission level. For example, if you modified the default View Only permission level and granted the Edit Items permission, users would falsely assume they were giving read-only access to a user or group.
Although you can add users directly to almost any object, this process becomes very difficult to manage and can make it nearly impossible to manage security in a site. Use the following guidelines when granting rights, and only assign permissions directly to single users if required, such as online presence:
Create an Active Directory group (when using Active Directory for authentication).
Create a matching permission level (if custom permission levels are required).
Create a matching new site group, and grant it the previously created permission level.
Grant the new site group access to an object, such as a document, list, or Web page.
By default, there are three site access groups in a site. You can add additional groups as you wish, but the default site access groups are added by default and can be modified by doing the following:
Open Site Settings from the Site Actions menu.
In the Users and Permissions column, select People and Groups.
From the Settings menu, select People and Groups from the drop-down menu, as shown in Figure 7-8.
Figure 7-8: You must select People and Groups from the drop-down menu to manage the default site groups.
Each of the following groups can be changed to an existing site group, or you can create a new group from this interface.
Visitors The Visitors group should grant read-only access to members of this group. Adding additional permission levels is inadvisable because users could mistakenly grant escalated permissions to members. The Visitors group is also the only group to which you can add all authenticated users. This is done by selecting Create a New Group and choosing the Add All Authenticated Users hyperlink, as shown in Figure 7-9.
Members The Members group grants contributor rights by default, but can be modified to meet your organizational standard for contributors. Unique to this site group when creating a new group is the option of creating an e-mail distribution list. This option is not available to the Visitors or Owners site groups.
Owners The Owners site group should not be modified in most circumstances. You can, however, create a new site group and use it for the Owners site group. This action is usually taken after the creation of a subsite, when wishing to break the inheritance from the parent site.
Figure 7-9: You can only add All Authenticated Users to the Visitors group.
You can modify Site Access Groups in a subsite, but by default, the changes will have no effect. You must break the inheritance from the parent site before the changes will take effect.
The new versions of Windows SharePoint Services and SharePoint Server allow the granting of permissions to an individual object, such as a folder or document. By default, objects inherit the permissions of their parent. For example, a document library would inherit the permissions of the site, whereas a document would inherit the permissions of the document library or folder in which it was contained. To break permissions inheritance, select Manage Permissions from the drop-down menu, as shown in Figure 7-10.
Figure 7-10: Select Manage Permissions from the drop-down menu to view object permissions.
From the following screen, you can choose to Manage Permissions Of Parent or Edit Permissions. By selecting Edit Permissions, you break the permission inheritance from the parent, copy all parent permissions to this object, and have the ability to assign permissions on the item.
If you wish to re-inherit parent permissions at a later date, you can do so from the Actions > Inherit Permissions drop-down menu. Be cautious when doing so, as all custom permissions not contained in the parent object will be lost. These changes and deletions are not sent to the Recycle Bin.