There are numerous ways of setting up and securing your MOSS environment from server hardening to IPSEC and SSL. Going through all of these are not the focus of this article. However this article will go through an overview of Moss. Next I will go into the security model, give an overview of the permissions and how they operate, including touching on what’s new. I will provide you with a matrix of the permissions, permission levels and groups to help you plan your security options. Then I will give you details on how to customize permissions and break free from the default permission inheritance. Then I will go into how all that we have gone over will affect workflow, including starting, participating and reporting. Then I will provide some wrap up and summary to ensure a complete picture is had.
So What is MOSS
“Microsoft Office SharePoint Server 2007 is the successor to SharePoint Portal Server 2003 which provides server capabilities such as comprehensive content management , enterprise search, and collaboration. MOSS also provides professionals and developers with a solid platform to take advantage of and build MOSS based applications or extensions.
What’s new in MOSS from a security perspective?
Good
1. Better 3 Tiered security Model
2. New more extensive permissions.
Better
1. Central administrators no longer have full access to content. (however they can take ownership, but then would be audited and logged)
2. Rights Masking. Administrators can remove certain rights from even being available to site administrators to grant. Such as “Manage Alerts”
Best
3. Security Trimmed user interface. If you don’t have rights you don’t see it!
4. ITEM LEVEL GRANULAR ACCESS
To better understand security in MOSS let’s talk about the basic security Model that makes up MOSS. MOSS now has a true 3-tier administrative model. This is going to make things easier for organizations to separate portions of administration and roles. The 3 tiers are 1. Farm Administration 2. Shared Services administration and 3. Content administration. As shown in (figure 1)
Overview of MOSS security Model

Figure 1.
The Layers
Farm Administration
Those who are in this role are responsible for the maintenance of all servers that make up a designated farm. Members of this group have the rights to perform all tasks in the Central Administration website. It is important to note that this group will not have access to the sites or the content inside them by default. However it is possible for members of this group to obtain these rights through the administrative interface by adding themselves as a site collection administrator. However this action will be audited and logged and provide for a evidence trail if this access was inappropriately used. Another important note for farm administration is that by default the local administrators group can perform all administrative tasks and more including deploying new applications, or web parts, and, creating additional web applications. However as with Farm Administrators they have no access to content without explicitly taking action.
Shared Services and Shared Services Providers(SSP):
First off what is SSP?
- SSPs are for managing a set of services such as searching and indexing, my site hosting, Usage Reporting, Excel Services, and Business Data Catalog Configuration
- The SSP administration interface is a Site
- An SSP by default is a separate web app from the other web apps extended with SharePoint Technology
- SSP administration is not available with WSS
SSP administrators can control which services are included in a Shared Services Provider (SSP) and configure settings for those services. Example tasks can include
· Configurable portal usage reporting
· Configuring permissions for specific services such as search, Excel services etc.
Content: These are all your site collections, sites, lists, document libraries etc.
Administration at this level is made up of Site collection administrator and Site Owners:
Site collection administrators: Members of the site collection administrators group will have full Control permissions on all web sites within a site collection. This means that they have access to content in all sites in that site collection, even if they do not have explicit permissions on that site.
Site owners: By default, members of the Site owners group has the full Control permissions on that site. They can perform administration tasks for the site, and for any list or library within that site.
Keep in mind that every site collection is an island of security. What I do in my site collection will not affect your site collection. By default a child site will automatically inherit the permissions of its parent. Unless the permission inheritance is stopped and that site “breaks free” which I will speak to shortly.
For general site content the site administrator should assign appropriate permissions within the site to various document libraries, lists, wiki’s etc. If the security model is such that there are people who maintain specific lists it would be their job to further restrict and maintain permissions for their various list items. By default all lists and libraries will inherit the site permissions, however the list owner can then further restrict or open up access based on need.
Another aspect of administration and rights is the Web Application. While the web application level does not have a dedicated “Web Application Administrators” group however Members of the “Farm Administrators” in addition to those local administrators do have the ability to define a “Web application policy” to grant people access at this level. Be careful with granting this because adding in people in at this level does give them access to the content contained within that web application.
So how do permissions work in MOSS? Lets Identify some common security terms and concepts.
Permissions: These individual permissions (of which there are 33) will grant a certain ability to perform specific actions. As an example Edit Personal User information, this right once granted will allow the granted user to modify their own user information such as updating their picture. In addition the list or possible permissions that can be granted can be “masked” so that they are unable to be granted to any user.
Permission Levels: These are essentially a defined set of permissions to perform related actions. For example the contribute level contains many rights such as Add items, Edit Items, Delete items and others. For a complete matrix see figure x. Similar permissions can be included in numerous levels and the existing levels can be customized to meet the needs of the environment. However I would recommend creating new levels rather than editing the default out of the box levels. Each of these permissions levels are also inheritable to child sites.
User: This is a person that can be authenticated through whatever authentication provider that is available, in MOSS you are no longer restricted to AD. These users can be assigned permissions levels by themselves or they can be part of a broader group that gets assigned certain permissions levels. Going the group route is a far better choice.
Groups: This is a collection of users. A group in the SharePoint context can be a SharePoint group such as “Site Owners” or can be an Active Directory group such as “Accounting Department”
Securable Objects – The above mentioned users and groups are going to have certain permissions levels for a specific securable object: such as a document library, a task list or any SharePoint item. By default these permissions are automatically set to inherit from their parent site. This can be changed however be very careful when doing this as it adds more administrative overhead. There are some new securable objects available to administrators in MOSS they are
· Website
· Lists
· Libraries
· Folders
· Documents or files
Getting into the permissions themselves in detail, hopefully the permission matrices in the following sections help in planning your strategy. There some additional new permissions available to be used.
New Permissions:
|
Permission |
Comments |
|
Approve Items |
|
|
Delete Versions |
|
|
View Versions |
|
|
Open Items |
|
|
View Forms Pages |
Turned off by default for publishing features in Office “12” Server. |
|
Create Alerts |
|
|
Use Remote API’s |
Turned off by default for publishing features in Office “12” Server. |
|
Manage Alerts |
(was manage Subscriptions) |
|
Browse User Information |
|
|
Create Groups |
(Was create cross site groups) |
|
Manage Permissions |
(Was manage Website) |
|
Open Container |
Allows users or groups to open the parent site of a list/library or the parent list/library for a folder or item/document so that they can view the list/library or folder or item/document to which they have been granted access. Required for fine-grained permissions |
Permissions to Permissions Level Matrix
|
Permission/Permission Level |
Full Control |
Design |
Contribute |
Read |
Limited Access |
Approve |
Manage Hierarchy |
Restricted Read |
|
List Permissions |
|
|
|
|
|
|
|
|
|
Add Items |
X |
X |
X |
|
|
X |
X |
|
|
Approve Items |
X |
X |
|
|
|
X |
|
|
|
Create Alerts |
X |
X |
X |
X |
|
X |
X |
|
|
Delete Items |
X |
X |
X |
|
|
X |
X |
|
|
Delete Versions |
X |
X |
X |
|
|
X |
X |
|
|
Edit Items |
X |
X |
X |
|
|
X |
X |
|
|
Manage Lists |
X |
X |
|
|
|
|
X |
|
|
Open Items |
X |
X |
X |
X |
|
X |
X |
X |
|
Override Check Out |
X |
X |
|
|
|
X |
X |
|
|
View Application Pages |
X |
X |
X |
X |
|
X |
X |
|
|
View Items |
X |
X |
X |
X |
|
X |
X |
X |
|
View Versions |
X |
X |
X |
X |
|
X |
X |
|
|
Site Permissions |
|
|
|
|
|
|
|
|
|
Add and Customize Pages |
X |
X |
|
|
|
|
X |
|
|
Apply Style Sheets |
X |
X |
|
|
|
|
|
|
|
Apply Themes and Borders |
X |
X |
|
|
|
|
|
|
|
Browse Directories |
X |
X |
X |
|
|
X |
X |
|
|
Browse User Information |
X |
X |
X |
X |
|
X |
X |
|
|
Create Groups |
X |
|
|
|
|
|
|
|
|
Create Subsites |
|