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?”
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.
(not a security feature)
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.
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.
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.
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.
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.
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
Here are the site templates for a server running SharePoint Server 2007. Windows SharePoint Services has fewer site templates. Each site template has its own ONET.xml file.
Some of the folder names are a bit cryptic – for quick reference, this table maps them to site names.
2) Right-click the ONET.XML file for the site definition and open it with Notepad.
3) Add the following line inside the opening Project tag:DisableWebDesignFeatures=wdfopensite
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.)
6) If you have a site of this type open in SharePoint Designer, close SharePoint Designer.When you try to open the site in SharePoint Designer, you should see the following message.
Knowledge Base 940958: How to prevent SharePoint Designer 2007 users from changing a Windows SharePoint Services 3.0 site or a SharePoint Server 2007 site
TechNet: Special directories and storage locations (Office SharePoint Server)
MSDN: Site Definitions and Configurations
MSDN: Project Element
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.
TechNet: Manage permissions for a Web application (Office SharePoint Server)
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 you leave 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.
TechNet: Manage permissions through policy (Office SharePoint Server)
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.
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.
Office Online: Permission levels and permissions
Office Online: Manage permission levels
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.
Office Online: Introduction to Contributor Settings
Office Online: Use Contributor Settings as a site manager
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.
TechNet: Enforce settings by using Group Policy in the 2007 Office system
TechNet: Disable user interface items and shortcut keys
Enterprise Management with the Group Policy Management Console
Office Online: Managing Users' Configurations by Policy
At a recent SharePoint User Group UK meeting, the use of vti_safeeditingconfigfileurl was mentioned. Can you please expand on that?
PingBack from http://sharepointkb.wordpress.com/2008/11/26/locking-down-sharepoint-designer/
Top News Stories Mainsoft Links IBM Jazz, Microsoft SharePoint (InfoWorld) With Mainsoft Document Collaboration
Das SharePoint Designer Team hat in einem ausführlichen Artikel " Locking Down SharePoint Designer
The bottom line for me is that MOSS 2007 does not provide a good way to handle access to SP Designer. We need SP Designer access to be limited to IT staff. We can't do that without stripping away other essential rights for other users. This issue is VERY important for large organizations!
Last week the SharePoint Designer Team posted an excellent article on the options available to lock particular
We have installed WSS 3.0 on our server.
I have installed Sharepoint Designer on my computer. I am able to open the
Site in Sharepoint Designer and was also able to edit it but now i am not able to open the site for editing. When i double click on the default.aspx file i see a hourglass and then it
does nothing. I tried using right click and open with Sharepoint designer but
Note: I have a 60 days trial version of Sharepoint Designer.
Any help is appreciated.
Thank you very much for your post, I leant a lots from your post.
Above post information and contents are very useful for locking down SharePoint Designer (SPD) at various levels, good work.
But I have observed that at each level, we have some or another limitation to lock down SPD only, my requirement would be to lock down SPD for normal users and only admin users can use SPD, so If I go with giving Permission for Web Application level for specific users & group, then my problem will solve at some level, “Browse Directories” permission is dependent on other 4 permission level, I would like to see and have normal users same options into SharePoint site when they browse the site and also they should not have access to SPD, in all case, if I make any changes into permission then it's also apply to SPD and SharePoint site while browsing.
Is there any way from which I can just control locking of SPD only, not limited access options into SharePoint site from browser?
I have also tried to give contributor rights from SPD, but I didn't find place from where I can attach or link users/group to contributor rights.
Thanks once again,
SharePoint Designer is now a free tool and available for download. What does this mean really? Anybody can download it and customize their SharePoint installations which is good in some ways, but ...
Wow Stephen, thanks for compiling all this excellent information - I think many SharePoint server admins are breathing a collective sigh of relief seeing these protective methods being available.
Is there a similar summary of SPD blocking for SPS 2003 / WSS 2.0 environments ?
Although a lot of SharePoint users were really happy with the news yesterday some were not so happy.
@Robin, glad you find the info helpful.
In SPS 2003 / WSS 2.0 environments, you can still modify ONET.XML:
And the "big three" permissions discussed above can still be used both in Central Administration and in individual site collections and sites.
But I think permission policies were introduced in MOSS 2007 / WSS 3.0. And Contributor Settings is available only in SPD 2007 for use with MOSS 2007 / WSS 3.0.
SharePoint Designer No it’s not an April fools joke and yes as of April 2, 2009, SharePoint Designer
To follow up with the free release of SharePoint Designer, steps to lock it use down if you have “creative”
Hay días en que nada sale bien, y la semana pasada tuvo uno de esos días: el viernes ("Viernes