Control Access to SharePoint Designer

You will often want to control who has access to use SharePoint Designer on your site.  There are a number of ways to control who has permission, you will need to determine the combination that applies to your intended use of the site and your governance policy.

Determine Your Information Architecture

Inside Microsoft’s intranet, there are a huge number of SharePoint sites available for just about everything I could ever need.  There are sites to access my HR information, fill out expense reports, schedule vacation, log my billable hours, read news about the company, participate in discussion boards, learn about upcoming product releases, and a slew of other sites.  Some, such as the HR and corporate intranet news site, are completely read-only to me.  I have no ability to contribute information, I can only read what’s available.  On others, I might be part of a select group that is able to write information, such as participate in discussion lists or enter timecard and vacation information.  Still others, I might own a web site and control who has access to the web site, but I do not control other sites within the same site collection.  And the last scenario is similar to a MySite where I own the entire site collection and everything in it.

In this example, there is a defined information architecture.  I do not universally have permissions to edit any site that I visit within the farm.  Many sites are read-only to me.  On sites where I am allowed to write information, I am typically restricted to write information only in certain areas of the site, for instance a particular list, I am not allowed to change the look and feel or grant others permissions to the site.  As a concrete example, the Premier organization of which I am a part of has a number of different sites within a site collection.  I can fill out a form on one site, but otherwise the site is read-only to me.  My team has another site where we can add documents and links and sample code, but otherwise the site is read-only to me. The point is that your information architecture should help structure appropriate use and govern who has access to various capabilities and features depending on business need.  This is not a blanket decision across the board, users are granted access and various permissions based on what they need to do with the site.

How Microsoft’s Internal Information Architecture Implies Governance

The policy within Microsoft’s intranet is pretty simple: some sites are managed, and some are not. 

There is an HR site, for example, that tens of thousands of people access regularly.  This site is on dedicated hardware and isolated from the shared resources farm.  Only a handful of people have write permissions, while tens of thousands of people have read access and visit the site regularly.  This site is business critical to the entire organization and was purposefully architected due to its importance.  This wasn’t support by accident, but rather its storage and isolation was carefully planned when the site was being created.  The site is architected to handle the number of users that access the site, including peak periods such as open enrollment, and is architected with high availability in mind.  To get a site like this means I have to pay for it because it requires dedicated resources (SQL storage, disks, backups, etc).  Since I am paying for a dedicated environment, I get to do pretty much whatever I want with it, such as deploy server-side custom code.  The main point to note is that it is critical to the business and therefore budget is applied to ensure it is available. 

On the other side are the unmanaged resources.  I can request a team site in a shared resources farm, and I will be the site collection owner.  There are a number of things that aren’t available to me in the shared resources farm.  I cannot add custom code, and a number of services are unavailable to me such as analytics and PerformancePoint.  While there are a few limitations, generally it’s pretty open, and I am able to use SharePoint Designer and grant others permission to use SPD.  I can create workflows and lookup lists and a whole bunch of stuff that makes SharePoint admins typically shudder.  The reason that I can do this is because it was planned and architected to allow self-service creation.  The environment has disk space allocated to accommodate the growth, and not everything is lumped into one giant database.  Site quotas are strictly enforced: if you need more than what is provided in the shared resources farm, then you need to purchase a managed solution from the IT group.  Large list throttling is strictly enforced, and a number of other checks and balances are enforced that limit what I can do.  If my site is unused for a period of time I have to renew it before it is deleted.  If my site in the shared resources farm uses too many resources, the IT group will make me purchase a managed solution.

You can use this to your benefit in choosing whether to allow SharePoint Designer or not.  In one part of your farm, you probably don’t want to enable it, while in another part (where everyone keeps their team sites), you want to let the site collection owner decide if they want to use it or not.  Further, it’s not an all-or-nothing scenario, you can selectively choose what users can do with SPD if they have access to a particular site.

Control Access to SharePoint Designer

A nice feature in SharePoint 2010 is the ability to limit where SharePoint Designer can be used.  Open Central Administration and go to General Application Settings / SharePoint Designer Settings.  Here you can configure SharePoint Designer settings for an entire web application.

You may have a site that is highly branded, and all branding and configuration is created through Visual Studio and managed through code releases.  In this case, you might want to completely disable SharePoint Designer for the web application.  You might use this in a publishing scenario where nobody has access to use SPD in the production farm.  Content is created in an authoring farm, possibly using SharePoint Designer, and then pushed to the production farm using content publishing.  What may not be immediately evident is that you can use this same approach within the same farm and publish content from one web application to another.  

The settings above apply to the entire web application.  If we disable SharePoint Designer, we will see the following when we try to open the site in SPD:

If you have multiple site collections within a web application, you may want to choose whether to allow SPD for each site collection.  Go to the Site Settings page at the root site of the site collection and you will find the link for SharePoint Designer settings for each site collection.

If SPD were enabled at the web application level, then we would have a screen that looks very similar to the page above.  However, since we disabled SPD at the web application level, here is what it looks like if we try to override the settings at the site collection level.  You’ll see that the web application settings overrule any settings at the site collection level, and use of SPD is disabled for all site collections in the web application.

Notice there are additional options besides turning SPD on or off.  A common issue that customers have with SPD is that a user can detach a page from its definition and completely customize the page.  Clearing the checkbox removes that permission, so users will not be able to detach from the site definition.  Another common request is to restrict users from being able to make changes to master pages.  By clearing the option, you can restrict if users can change master pages using SPD. 

What if you want something more granular other than turning features of SPD on or off for everyone in a web application, or everyone in a site collection?  SharePoint 2010 provides a more granular permissions model that lets you restrict what users can or cannot do.

Control Permissions to SharePoint Designer Features

By default, SharePoint 2010 provides 33 permission levels and six default groups.  They are provided in the following table.

	Limited Access	View Only	Read	Contribute	Design	Full Control
List Permissions
Manage Lists
Override Check Out
Add Items
Edit Items
Delete Items
View Items
Approve Items
Open Items
View Versions
Delete Versions
Create Alerts
View Application Pages
Site Permissions
Manage Permissions
View Web Analytics Data
Create Subsites
Manage Web Site
Add and Customize Pages
Apply Themes and Borders
Apply Style Sheets
Create Groups
Browse Directories
Use Self-Service Site Creation
View Pages
Enumerate Permissions
Browse User Information
Manage Alerts
Use Remote Interfaces
Use Client Integration Features
Open
Edit Personal User Information
Personal Permissions
Manage Personal Views
Add/Remove Personal Web Parts
Update Personal Web Parts

One of the interesting things about SharePoint is how it security trims the user interface based on what permissions you have.  For instance, as a site collection administrator, I have full permissions to the site.  The site actions menu shows all of the commands, including Edit in SharePoint Designer:

To contrast, as a member of the Visitors group, I am given Read permissions.  The site actions menu looks very different because the UI is security trimmed based on my permissions.

A user with Contribute permissions has the ability to create and edit site pages in a team site.  Notice in the permissions grid above, we show that users with Contribute do not have the permission to add and customize pages, yet the UI shows that they have permission to add and edit wiki pages in the menu.  This permission name is a little misleading, because you can still add new content in the form of new wiki pages, and can edit those pages, even add web parts to wiki pages as you see in the following screen shot:

What the Add and Customize Pages permission means is that without this permission, you cannot edit files at the root of the site (such as default.aspx in a team site) or files that reside in folders outside of lists and libraries.

While I can add and edit wiki pages, notice there’s no link to Edit in SharePoint Designer as there is with a user who has Full Control.  I cannot add arbitrary pages (such as my own .ASPX or a new web part page).  Additionally, if we try to open the site in SharePoint Designer 2010, we receive the following error:

Let’s create a new permission group called Page Creators that only grants the Add and Customize Pages permission.

I grant this permission to a user that already has Contribute permissions.  The permissions are cumulative, meaning if something is checked in one permission group but unchecked in others, the user will have that permission.  You can see that the user retains Contribute permissions and is additionally granted Add and Customize Pages, which now lets them open in SharePoint Designer.

Where a user with Contributor access only has the Edit Page, New Page, and View All Site Content options, a user that is granted the Add and Customize Pages now has a link to Edit in SharePoint Designer as well as access to Site Settings.  If we go to Site Settings, we can see that it, too, is security trimmed with only a few options available.

If we open the site in SharePoint Designer 2010, our options are security trimmed.  We cannot access the site master pages, cannot create new lists, and cannot manipulate workflows.  About the only thing we can do is to add a new web part page to the site.

By manipulating permissions, we can control what users are able to do with our site using SharePoint Designer and limit their capabilities to only those activities that they need to have for a particular site.

Do NOT Remove the Use Remote Interfaces Permission

Looking at the list of permissions, you may be tempted to disable the Use Remote Interfaces permission because it mentions using “SharePoint Designer interfaces to access the Web site” — a reasonable conclusion, but just don’t do it! This permission has a dependent permission, Use Client Integration Features, and removing this permission disables all SharePoint integration with Office programs like Word, Excel, and PowerPoint.  It also has the unintended effect of disabling your ability to access SharePoint’s web services.

[via https://blogs.msdn.com/b/sharepointdesigner/archive/2008/11/25/locking-down-sharepoint-designer.aspx]

 

For More Information

Governance features (SharePoint Server 2010)

Locking Down SharePoint Designer