We see many instances in which the SQL DBA for SharePoint is the same as the SharePoint administrator, which also happens to be the same person as the security admin, and the support staff, and the etc., etc., etc.

Even though we see these roles blended for various reasons (lack of understanding of the importance of having role separation, not enough money to hire people, not planning the production deployment completely), SharePoint does actually have strong role separation by default. “Role Separation” means that administrators of one piece, tier, or component of the system may not necessarily need administrative access to other pieces, components, or tiers.

This is a valuable consideration for security and for stability. For example, you likely don’t want your enterprise domain administrators to have access to the CEO’s mail. For stability, your SQL DBAs probably don’t want the windows administrators manipulating SQL configuration settings. The same is true for SharePoint… having access to administer the SharePoint farm doesn’t necessarily mean a user should have access to the content within that farm.

So, if you were to design a team with complete role separation (assuming you have enough people to cover each role discretely), what might the team look like and what roles would they have? Here’s my list…

  • Platform Administrators – This group has “Local Administrator” access to your Windows machines. They likely own all patching and general system stability. They may potentially own additional elements such as platform security (managing the windows firewall) and antivirus maintenance.
  • SQL Database Administrators (DBA) – This group has “SysAdmin” access to your SQL server, but may not necessarily have or require administrator access to the underlying Windows installation. This person is responsible for ensuring SQL is configured optimally, and likely contributes to investigation of any errors or difficulties in the environment.
  • SharePoint Farm Administrator – This group is listed in Central Administration in the “Update Farm Administrators Group”, and has complete management rights to manage the logical architecture of the SharePoint environment. This person may not necessarily have administrative rights on the underlying Windows OS, though this would not be unusual. This group is also responsible for managing any SharePoint updates, service packs, or hotfixes, and investigating and resolving SharePoint based errors in the environment.
  • SharePoint SSP Administrator – This group can manage settings in an individual SSP, particularly search and business data, that may be confidential or may be specific to web applications that have specialized or independent needs. This person may not necessarily have access to the overall Central Administration website, and will almost certainly not have administrative rights on the underlying Windows OS
  • Web Application Policy Members – While this may not have a specific “role”, people with these rights set have the ability to override site collection level settings throughout the application. For example, having “Full read” on the web application means that you have the ability to read content in any of the site collections within that web application, even if you have no specific rights listed in the site collection itself.

All of the roles above are System or Application roles… that is, none of them necessarily have a direct impact on content (with possible exception of web application policy)… but more importantly, none of the roles above are stored with content. If your farm needs to be rebuilt, the above permissions would all need to be rebuilt also.

The roles below are arguably content roles… that is, roles that have a direct impact on content, are visible in the users/groups lists in site collections, can and frequently are managed directly by users, and most importantly, are stored in the content database. Though it may be tempting to attempt to rigorously control these (and there are good reasons to do so), these are more likely best distributed throughout the organization and are frequently managed by people outside of the farm administrators group.

  • Site Collection Administrators – These people have overall rights within a given site collection, including certain very specific settings that might otherwise be handled by the Farm Administrators, but make sense to distribute more widely. These people should also be a primary escalation point for SharePoint users (they have certain abilities to override the user activity), and should be included in the governance strategy for SharePoint (since they see user difficulties and needs most).
  • SharePoint Group Managers – These people have been listed as owning a SharePoint group, meaning they can add and remove users from those groups. This implies that they also have the ability to grant group members access to things the group itself has been granted permissions to, but do not have the ability to impact permissions directly. This can be very useful in maintaining coherent and manageable permissions while still giving others the ability to provide users with access without needing to call the Site Collection Administrator or create a support request.
  • Everyone Else - Below this, we have the permissions that most people are familiar with… groups and users being granted access to SharePoint resources (sites, lists, items), which are again managed directly in the content by various people that have been given the ability to manage those permissions.

The most important points in the above lists are that the roles can be very, very discrete. For example, being the DBA does NOT mean you have access to content in the UI. Yes, it is possible for you to override this… but such an override would generally be visible in the system, either to farm administrators or to users.

As with most security systems, there is (by design) a mechanism for overriding security. For example, it may be reasonable for farm administrators to add themselves to the web application policy for specific investigation purposes… but in a well managed environment, these rights would generally not be required. However, this possibility means that regularly auditing those roles to ensure they haven’t been misused is an excellent activity. Such audits should NOT be scheduled, but should at random intervals, but should still occur with some amount of regularity.

Technically, there are many more distinct roles. For a complete list, look here: Plan for security roles (Office SharePoint Server)