Locking Down SharePoint Designer
Hello all, Stephen here again – I’m a writer for SharePoint Designer. As you know, SharePoint Designer 2007 is a powerful tool for editing SharePoint sites — so powerful, in fact, that you likely have scenarios in your organization where you want to control where and how people can use SharePoint Designer 2007.
With this post, I’ll try to answer a very common question: “How can I lock down SharePoint Designer in my organization?” And I’ll try to answer the flip side of this question, which arises in an environment where SharePoint Designer has been locked down and the user asks: “Why do I see this message when I attempt to edit a site in SharePoint Designer?”
Options for locking down SharePoint Designer
The following table outlines the various ways in which you can lock down SharePoint Designer in your organization. Some of this information has been previously published in various venues (Office Online, TechNet, MSDN, Knowledge Base, etc.), but I thought it would be helpful to pull it all together for you.
|SCOPE||OPTION||PERMISSIONS REQUIRED TO ENABLE OR DISABLE|
|At the server level per site definition||ONET.XML — Prevent all users from opening all sites created from a specific site definition (such as all team sites or all publishing sites) by modifying ONET.XML for that site definition.||Server administrator — You must have an administrator account on the server to modify this file.|
|At the Web application level for all users||Permissions in Central Administration — Prevent all users from opening or editing all sites in a Web application by removing the permissions in Central Administration.||Site Collection Administrator — You must be a Site Collection Administrator to add or remove permissions in Central Administration.|
|At the Web application level per user or group||Policy in Central Administration — Prevent specific users and groups from opening or editing all sites in a Web application by removing the permissions in Central Administration.||Site Collection Administrator — You must be a Site Collection Administrator to manage permission policies in Central Administration.|
|At the site level per user or group||Site permissions — Prevent specific users and groups from opening or editing sites at the site level by removing the permissions from their permission level. Site permissions cannot override permission settings in Central Administration.||Site owner — You must have the Manage Permissions permission to configure site permissions. In SharePoint Server 2007, by default only the Full Control and Manage Hierarchy permission levels include this permission.|
|At the site level per user or group
(not a security feature)
|Contributor Settings — Guide trusted users toward performing the right tasks in the right place by disabling features and UI in SharePoint Designer 2007. Contributor Settings cannot override permission settings at the site level or in Central Administration.||Site owner — You must have the Manage Permissions permission to turn Contributor Settings on or off. In SharePoint Server 2007, by default only the Full Control and Manage Hierarchy permission levels include this permission.|
|Per computer or per user||Group Policy — Use policy settings to disable menu commands and their corresponding toolbar buttons in the UI of Office programs, including SharePoint Designer. You can also disable keyboard shortcuts. Settings can be applied to a specific computer or user.||Windows administrator — You must be a member of the Domain Administrators security group, the Enterprise Administrators security group, or the Group Policy Creator Owners security group.|
For a visual overview of the various levels, see MSDN: Server and Site Architecture: Object Model Overview.
For the above options that use permissions, whether at the site level or in Central Administration, there are three permissions that you need to consider.
|PERMISSION||DESCRIPTION||EFFECT ON EDITING WITH SHAREPOINT DESIGNER|
|Add and Customize Pages||Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services-compatible editor.||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.|
|Browse Directories||Enumerate files and folders in a Web site using SharePoint Designer and Web DAV interfaces.||Without this permission, you cannot open a site in SharePoint Designer.|
|Manage Lists||Create and delete lists, add or remove columns in a list, and add or remove public views of a list.||Without this permission, you cannot delete libraries, lists, or list forms or views (such as AllItems.aspx) in SharePoint Designer. However, if a list does not inherit permissions from the site, the list permissions apply to that specific list. Note that by default, the Workflows document library does not inherit permissions from the site; you must manage these permissions separately.|
Option 1 — Disable the Add and Customize Pages permission
If you are concerned about users editing files in a site, you can clear the check box for Add and Customize Pages. Doing this also clears the check box for one dependent permission, Manage Web Site.
When you remove these permissions, users can still open a site in SharePoint Designer, and they can open and edit pages that may be at the root of the site, such as default.aspx. But when they try to save these changes, they see this message.
Without the Add and Customize Pages permission, a user cannot save the edited page to the root of the site or to any folders in the site — for example, a user cannot save changes to default.aspx at the root of the site. But they can save the edited page to any library in the site to which they have permissions or to a location outside the current site. Remember that list permissions are separate from site permissions — in fact, these two sets of permissions have separate sections in the list of permissions. So preventing users from saving changes to files that reside outside of lists or libraries does not prevent them from opening the site in SharePoint Designer and doing things like deleting workflows from the Workflows document library or deleting an entire list. Permissions for these lists and libraries are managed separately (see the next section).
Here’s another consideration: If you have all of the permissions (the default Full Control permission level), you see all options on the Site Settings page (below, top image). If you do not have the Manage Web Site permissions (dependent on Add and Customize Pages), many options on the Site Settings page are trimmed away (below, bottom image). So take this into account when managing user permissions, especially at the level of Central Administration, because you may be preventing many people from performing key administrative tasks in their site.
Option 2 — Disable the Manage Lists permission
As mentioned above, if users can open a site in SharePoint Designer, they can — depending on their list permissions — delete content in lists and libraries such as workflows, list forms, or even entire lists. To prevent this, you must disable the Manage Lists permission.
After you remove this permission, when a user opens a site in SharePoint Designer and tries to delete a list (or a file in the list) that is inheriting permissions from the site, they see the standard “Access denied” warning message.
Note that this permission can be overridden at the level of a specific list or library if that list or library breaks inheritance. For example, the Workflows document library is a hidden library in the site that by default does not inherit permissions from the site. When you create a site, the Workflows library gets the same permissions configuration as the site, but any permissions changes that you subsequently make at the site level — such as disabling Manage Lists — do not automatically trickle down to the Workflows library.
To manage permissions for the Workflows library, open the site in SharePoint Designer >> right-click the Workflows library >> click Properties >> click the Security tab >> click the link “Manage permissions using the browser”.
Note that disabling Manage Lists for users also prevents them from adding columns to a list or creating public views.
Option 3 — Disable the Browse Directories permission
The previous options prevent users from editing or deleting objects in a site after they open the site in SharePoint Designer. You can also prevent users from opening a site in SharePoint Designer in the first place by disabling the Browse Directories permission.
Disabling this permission also disables four dependent permissions: two discussed above (Add and Customize Pages and Manage Web Site) plus two more, Manage Permissions and Enumerate Permissions.
When a user who does not have the Browse Directories permission for a site (or Web application) tries to use SharePoint Designer to open that site (or any site in that Web application), they see this message.
Then they are presented with the prompt for new log-on credentials. If the new credentials fail, they see this message.
Not an option — Disable 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.
For example, if you disable Use Remote Interfaces, you’ll notice that the Edit in Microsoft Office Word option disappears from the item menu in a list or library.
Or when you try to view the version history of a document in Word (Office button >> Server menu >> View Version History), you see this message.
And all sorts of other cool features like workflow integration get disabled, so disabling Use Remote Interfaces is not the way to control access with SharePoint Designer.
At the server level per site definition — ONET.XML
If you are a server administrator, you can prevent users from opening sites in SharePoint Designer 2007 by modifying the ONET.XML file on the server. Every site definition includes an ONET.XML file, and changing this file will affect all sites based on that site definition. For example, you can modify ONET.XML for the “sts” site definition, which will prevent all users from opening in SharePoint Designer all team sites created from this site definition. There is no “uber-ONET.XML” file that controls all site definitions.
Changing ONET.XML is a global change that affects all sites on the server.
1) On the server, open Windows Explorer and browse to the folder that contains the site definition:
<Drive:> \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\ <site_type> \XML
Some of the folder names are a bit cryptic – for quick reference, this table maps them to site names.
|BLANKINTERNET||Publishing Site with Workflow|
|MPS||Includes the site definition configurations for:
|OSRV||Shared Services Administration|
|SPS||SharePoint Portal Server Site (legacy - this template is obsolete)|
|SPSCOMMU||Community area template (legacy - this template is obsolete)|
|SPSMSITEHOST||My Site Host|
|SPSNEWS||News Site (legacy - this template is obsolete)|
|SPSPERS||SharePoint Portal Server Personal Space|
|SPSTOC||Contents area template (legacy - this template is obsolete)|
|SPSTOPIC||Topic area template (legacy - this template is obsolete)|
|SRCHCEN||Search Center with Tabs|
|sts||Includes the site definition configurations for:
2) Right-click the ONET.XML file for the site definition and open it with Notepad.
4) Save the file and close Notepad.
5) On the server, do an iisreset.
(Click Start, click Run, type cmd, click OK. At the command prompt, type iisreset computer_name /restart, then press ENTER.)
For more information
At the Web application level for all users — Central Administration permissions
In Central Administration, you can enable or disable permissions for all users and groups in a Web application. Managing permissions centrally like this can be convenient because a Web application can contain 150,000 site collections. When you clear the check box for a permission in a Web application, that permission cannot be assigned to any user or group in any site in any site collection in the Web application.
Browse to the Central Administration site. On the Application Management tab, click User Permissions for Web Application.
On the next page, you see the same list of permissions that you see when you manage the permission levels for an individual site (with one exception: in Central Administration there’s an additional permission named Use Self-Service Site Creation).
The effects of disabling specific permissions are discussed above, but in Central Administration the simplest way to prevent uses from editing sites in SharePoint Designer is to disable the Browse Directories permission so that they cannot open sites at all in SharePoint Designer — with the caveat that these people therefore won’t have access in the browser to all options on the Site Settings pages and won’t be able to manage permissions for any site in the Web application.
For more information
At the Web application level per user or group — Central Administration policy
The option covered in the previous section — permissions for the Web application — is a blanket setting that covers all users and groups for all site collections in a Web application. If you need finer granularity, you can set permissions for specific users or groups in a Web application. You do this by creating a policy for the Web application. Joel Olson’s blog has some good examples of when a Web application policy is useful.
And as Joel mentions, policy for a Web application is a way to centrally manage permissions and is different from an information management policy — auditing, expiration, labels, barcodes — that you use to manage data in a list or library.
Browse to the Central Administration site. On the Application Management tab, click Policy for Web Application.
Managing permission policies in Central Administration is much like managing permissions in a SharePoint team site. You can add users, configure permission levels, and then assign users a permission level.
Except the trick with setting permissions in a policy is that there are two check boxes for each permission — Grant and Deny. If youleave both check boxes blank, this means the policy does not explicitly grant or deny this permission, so it’s up to the discretion of site owners in the Web application whether users have this permission. If you explicitly grant a permission as part of a Web application policy, that user has the permission and this cannot be overridden by a site owner at the site level. Likewise, explicitly denying a permission prevents users from ever having this permission.
Your choices here for using permissions to lock down SharePoint Designer are the same as noted above. For quick reference, this table shows which default policy permissions levels grant or deny these permissions. The simplest path here to locking down SharePoint Designer would be to add a new permission policy level that explicitly denies Browse Directories (with the caveats about dependencies noted above), and then assign that policy to specific users or groups.
|PERMISSION POLICY LEVEL||ADD AND CUSTOMIZE PAGES||BROWSE DIRECTORIES||MANAGE LISTS|
|Full Read||Blank(neither grants nor denies)||Grants||Blank(neither grants nor denies)|
|Deny Write||Denies||Blank(neither grants nor denies)||Denies|
For more information
At the site level per user or group — Site permissions
A site owner can set permissions on a per user and per site basis.
If the site is not inheriting permissions:
· Click the Site Actions menu >> Site Settings >> Advanced Permissions >> Settings menu >> Permission Levels
If the site is inheriting permissions:
· Click the Site Actions menu >> Site Settings >> Advanced Permissions >> Actions menu >> Edit Permissions >> click OK >> Settings menu >> Permission Levels
At the site level, the same permissions are available to you, and they have the same dependencies noted above. For quick reference, this table shows which default permissions levels in SharePoint Server 2007 include these permissions.
|PERMISSION LEVEL||ADD AND CUSTOMIZE PAGES||BROWSE DIRECTORIES||MANAGE LISTS|
|Full Control (Owners group)||Yes||Yes||Yes|
|Contribute (Members group)||No||Yes||No|
|Read (Visitors group)||No||No||No|
|View Only (Viewers group)||No||No||No|
The simplest guidance here is:
· To prevent users from opening a site in SharePoint Designer, add them to the Visitors group. Note that Visitors also cannot edit items or files in lists or libraries in the browser.
· To prevent users from editing a site in SharePoint Designer, add them to the Members group. Members can edit items or files in lists or libraries in the browser. They can also open (but not edit) a site in SharePoint Designer.
· To allow users to edit a site in SharePoint Designer but not perform site owner–type tasks (such as managing permissions), create a Designers group and assign that group the Design permission level. Users with the Design permission level can open and edit a site in SharePoint Designer, but they do not have the Manage Permissions permission.
Remember that permissions at the site level are overridden by permissions at the Web application level. Even if you assign a user the Full Control permission level for your site, that user will get denied access if the required permissions have been removed or denied in Central Administration.
For more information
At the site level per user or group (not a security feature) — Contributor Settings
You can use the Contributor Settings feature to enable and configure Contributor mode, which is a limited access mode in SharePoint Designer 2007. Users who open a site for editing in SharePoint Designer 2007 have access to different commands or features, depending on which Contributor group they belong to and what editing restrictions have been assigned to that Contributor group.
On the Site menu, click Contributor Settings.
Contributor Settings provides fine-grained control over which users can perform which tasks in SharePoint Designer 2007. But keep two important points in mind:
· Unlike permissions, Contributor Settings is not a security feature. Contributor mode is designed to be used in an environment where site owners are confident of their users’ intentions. Contributor mode helps to guide users in a particular direction to carry out their tasks, and this guidance prevents accidental changes to the Web site.
· A user’s Contributor Settings cannot override what their permissions allow them to do. Permissions are a security feature; Contributor Settings are not a security feature; if the two conflict, permissions always trump Contributor Settings.
To turn Contributor Settings on or off, you must have the Manage Permissions permission. In SharePoint Server 2007, by default only the Full Control and Manage Hierarchy permissions levels include this permission. So by default, only people in the Owners group can turn off Contributor Settings.
Finally, if a user tries to save a file to a location that is disallowed by their Contributor Settings, they see the usual “Access denied” message.
Contributor Settings can only be configured on a per-site basis, and these settings are stored in an .htm file. However, you can configure these settings on a temporary site, save the .htm file, and then include this file in a site definition by using the File element. This way, all sites created from this site definition will share the same Contributor settings.
For more information
Per user or per computer — Group Policy
In a Windows-based network, administrators can use Group Policy settings to help control how users work with the 2007 Microsoft Office system, including SharePoint Designer 2007. Administrators can use Group Policy settings to define and maintain an Office configuration on users' computers. Unlike other customizations — for example, default settings distributed in a Setup customization file — policy settings are enforced and can be used to create highly managed or lightly managed configurations. For example, administrators can use policy settings to disable user-interface menu commands and their corresponding toolbar buttons, and keyboard shortcuts.
You can create policy settings that apply to the local computer and every user of that computer, or that apply only to individual users:
· Per-computer policy settings are applied the first time any user logs on to the network from that computer.
· Per-user policy settings are applied when the specified user logs on to the network from any computer.
Group Policy is completely separate from both a permissions policy in Central Administration and an information management policy applied to a list or library. Group Policy does not control access to objects such as sites or site collections in a SharePoint deployment. Instead, Group Policy can disable commands and button in the user interface of SharePoint Designer 2007. For example, if you don’t want users performing resource-intensive tasks such as backing up sites during peak operational hours, you can use Group Policy to disable the Backup Web Site command in SharePoint Designer for specific computers or users.
Disabling UI requires that you specify the toolbar control ID (TCID) for the 2007 Office system controls. For Office 2007 programs that use the Ribbon, this download provides a list of TCIDs.
In SharePoint Designer 2007, you can get control IDs using the same VBA that worked in Office 2003. You can find steps and VBA code snippets at Office Online: Managing Users' Configurations by Policy.
For quick reference, the spreadsheet attached to this post lists the TCIDs for all of the menus and commands in SharePoint Designer 2007.