Fixing Access Denied Errors With SharePoint 2010 Timer Jobs

It is important to realize before we get started that this error was also present within SharePoint 2007. When creating timer jobs, it is important to understand the relationships between the SPSecurity.RunWithElevatedPrivileges method and the associated SPWebApplication object. When using SPSecurity.RunWithElevatedPrivileges, it will not allow modification of the SPWebApplication since it is persisted to the configuration database. However, other proxy objects are exempt from this such as SPSite ‘s and SPWeb ‘s. SPSecurity.RunWithElevatedPrivileges allows the elevation to just the content database, NOT the configuration database (which has the SPWebApplication property bag) which is generally more locked down.

The easiest way to fix this is to impersonate the user account for proxy objects (assuming you are using a current context to reference the application property) with an account that has the wss_content_application_pools database role for the config database since this will have elevated rights for stored procedures and what not. This will allow you to modify your timer jobs easily. If you want to be really lazy, just use the same account as the central admin app pool which inherently provides the required access to the configuration database.


Best Practices For Designing SharePoint 2010 Site Permissions In Plain English

A friend, after a conference call this morning asked me to write this out since the client was still all confuddled.

Planning access control designs for the multitude of SharePoint assets available in the 2010 version is vital to implement during the planning stages of your SharePoint implementation. This includes incorporating both permission inheritance schemes as well as more fine grained permissions in order to procure the most effective scheme for relating permissions to particular scopes.

As in previous versions of SharePoint, in order to grant access to both sites as well as content within SharePoint containers permissions are applied in an orthodox manner. There are several things to take into consideration when beginning the designing process. Firstly, you have to consider how strongly security should be applied. For example, some SharePoint instances can simply lean on heavy inheritance schemes, others may have various restrictions on pieces of sensitive content and their respective containers. Secondly, permission design must heavily consider how groups and users are going to be leveraged. A group is simply a container, this is important to remember. As a container, the group really has little relevance until there is permission levels attached to the groups.

Before getting started, there are a couple pieces of inbuilt security objects in SharePoint that must be considered throughout the designing process. Firstly, there are the individual permissions and their associated permission levels. By assigning permissions to a user, you are essentially saying that a user can perform a specific action. Developers will recall these as the members of the SPBasePermissions enumeration. For example, the SPBasePermissions.BrowseDirectories and SPBasePermissions.AddDelPrivateWebParts permissions, etc. etc. etc.. Therefore, when designing the permission levels it is essential to consider the predefined permissions in SharePoint that coordinate to the related tasks that the user can perform. Since individual permissions can contain multiple permission levels, it is important to consider all the relevant actions for each user and group. In order to manage permission levels, a user must have the Manage Permissions permission, or the SPBasePermissions.ManagePermissions member.

Users and groups have to be seriously considered when designing permission schemes. Groups in SharePoint are contained and administered at the site collection level, and can either be a Windows security or SharePoint group. Groups in SharePoint have an associated default permission level, but the default permission levels are easily modified. Similiar to how managing permissions requires the SPBasePermissions.ManagePermissions member, creating groups requires the SPBasePermissions.CreateGroups member. Groups only contain utility when users are placed within the group. It is considered a best practice to use groups whenever possible and in only particular circumstances assign individual permissions to particular content.

In terms of the “things” that a user wants to access, each object is considered to be a securable object or an ISecurableObject object. This can be a list, library, document, list item, etc. By default content within the site will natively inherent the site permissions but there is lower level assignment that is always available, such as list level (container level) or item level (content level).

Understanding and designing the SharePoint security relational assignments is crucial when considering the holistic SharePoint environment. Particular securable objects can have a user or group assigned a permission level for it. On securable objects within the site, as stated before, will by default inherit the permissions from the site by default. This design can be extended by implementing unique, fine grained permissions for each securable object in SharePoint in order to more finely tailor user actions for particular content. This approach needs to be approached with the aggregate design in mind, since assigning a multitude of individual permissions can natively cause a very, very complex design. This paradigm of complexity means that the implemented design must mutually consider the permission inheritance scheme as well as the individual permission assignment scheme. As a best practice, when breaking inheritance you should try to use groups as much as possible in order to decrease the complexity of the security designs. Individual accounts, for individually assigned items can be very, very difficult to track and can cause highly visible maintenance problems.

Managing sites, as a best practice, should use inheritance as much as possible due to the trickle-down inheritance that happens by default with the permissions of all the associated items within the site. It both lessens security design complexity and makes push down changes much more effective and impacting. Under this design however, the persons with the rights to manage sub site permissions must be strongly controlled since the sets are shared. This can natively cause problems with users accessing content and both site and the sub site level. As a best practice, commonly accessed content should use a shared inheritance scheme as much as possible while sensitive content that has few associated users and groups can be broken.

From what we have talked about thus far, it is clear that determining the balance between the simplicity of managing the security for an instance as well as performance versus the need to separate sensitive content. There are a few takeaways to consider as best practices. Firstly, always follow the principles of least privilege where a user only has the required minimum permissions to execute their assignments. Since several of the inbuilt functions of SharePoint as well as the API has hooks that use the standard groups, it is best to exploit the default groups as much as possible. As stated previously, it is best as much as possibly to lean on inheritance schemes. Always carefully choose whom you elevate about the permissions of members of visitors since these correlate to the common actions of limited contribution and view rights on objects. Furthermore, members of the Owners group should be tightly controlled and monitored since they have elevated rights to execute actions such as modifying the site structure. It is important to remember that permissions and permission levels are flexible in SharePoint, permission levels for particular objects can be customized as required.