Follow me on Twitter @AntonioMaio2

Tuesday, August 20, 2013

How to Disable the Windows Explorer View in SharePoint

In working with several customers to secure sensitive information in SharePoint, we've found that there are times where some customers still want to use the Windows Explorer view in SharePoint. This is due to a couple of reasons:
  • The fact that many users are used to copying/moving files and folders through an Explorer window.
  • Its one of the only ways in SharePoint to copy multiple folders at a time into a SharePoint library.
However, we have found that the Windows Explorer view does have several inherent security holes and these holes do pose significant risk to customers in the military or DOD environments. For example, if SharePoint permissions only give a user read access to a file, often users are still able to rename the file through the Windows Explorer view. In some cases users with read access to certain files are even able to delete those files.  There are other similar holes.

As well, Microsoft has stated that when using claims based authentication with SAML security tokens that the Windows Explorer view in SharePoint 2010 does not work:  http://technet.microsoft.com/en-us/library/hh706161.aspx.  It goes on to say that this feature (and others) do not work because claims based authentication does not generate a Windows Security Token which is required for this feature.  From my experience in this situation the explorer view partially works in that it can be accessed but it does not respect ACLs correctly.

As a result, we often recommend to customers that they "turn off" the Windows Explorer view in SharePoint and force users to use the web view. With SharePoint 2013, this option is even more viable because the web view now allows users to drag and drop files from their Windows desktop into the web browser and have those files copied into the SharePoint library. An awesome feature if I may say so!

"Turning off" the Windows Explorer view is a bit of a misnomer though. There is no way, that I can find to completely turn off the Explorer View to SharePoint from the SharePoint server. However there are several methods for preventing end users from accessing these Windows Explorer view. This blog post will describe each of these methods in detail.

Method #1

Administrators can disable access to the Windows Explorer view by modifying the “User Permissions” on the web application. This is done within Central Administration:
  • Click Manage Web Applications and select your web application
  • Click the User Permission button in the ribbon
  • Find the “Use Remote Interfaces” permission in the list and uncheck it (this will also automatically uncheck the “Use Client Integration Features” permission as well)
This will disable the “Open in Explorer” button in the SharePoint ribbon for all libraries in all sites in the web application.

There is a problem with this method though - it also disables all access to open documents in SharePoint from the open dialog in MS Office applications. As well, access from SharePoint Designer and access from all client object model applications will be also be disabled. Please note that the Open Dialog, like the Windows Explorer view also does not fully respect SharePoint permissions. So, this method may or may not work for your environment.

Method #2

I have found that simply removing the “Open in Explorer” button all together from the SharePoint ribbon can be an effective way to prevent access through the Explorer view. There is a good blog post here on how to accomplish this here.

[previous link was incorrect - this is now fixed]

This method is effective because you open Windows Explorer on your desktop and paste the URL to a SharePoint library Windows will automatically open a web browser and navigate to the SharePoint web view of the library. It does not actually open in Windows Explorer. This allows the open dialog in Windows to still navigate to a file in a SharePoint library and open it, but prevents users from effectively using the Explorer view.

This method of course may not be fool proof, meaning a malicious user may still find a way around it. However it would cover 95% of cases where end users are simply trying to open documents that they are permitted to access. As well, this method still allows users to open SharePoint documents from the Open dialog in MS Office applications, SharePoint Designer and client object model applications.

Method #3

A third method that is effective and allows you to still maintain client object model access and access through the Microsoft Office open dialog is the following procedure which modifies the permissions required to access the Open in Explorer button. This procedure will result in the “Open in Explorer” button in the SharePoint web interface to still be visible and enabled, but to only be accessible by users that have the “ManageWeb” permission on the site. This would allow you to configure SharePoint to allow site owners to have access to the Windows Explorer interface, but not regular users that only have contribute permissions. Follow these steps to accomplish this:
  • On the SharePoint 2010 server navigate to the folder \Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\CONTROLTEMPLATES
  • Make a copy of the file DefaultTemplates.ascx
  • Open DefaultTemplates.ascx in Notepad:
  • Search for the following string ID=”OpenInExplorer”
  • Below that string change PermissionString=”UseClientIntegration” to PermissionString=”ManageWeb”
  • You will find 2 instances of ID=”OpenInExplorer” – you’ll need to make the change in both places
  • Save the file and issue an IIS Reset
You’ll then find that a user that is a site owner can click on the “Open in Explorer” button and still access SharePoint through the Explorer interface, but users that are not site owners (or who do not have the Manage Web Site permission) can click on the button but they’ll get an “Access Denied” message. This works even if a user tries to create a shortcut to a URL and access the Explorer view from that shortcut, or if they try to map a network drive to the SharePoint library URL - if they don't have appropriate permissions they will receive an "access denied" message:


Method #4

A 4th and probably more extreme method is to in fact disable WebDAV itself on the IIS Web Server. To accomplish this follow these steps:

  • Click the Windows "Start" button on your Web server, and select "Administrative Tools." Click "Internet Information Services Manager" to open the configuration utility.
  • Click the Web server name in the left panel. A list of websites expands. Click the website name you want to edit, and click "Web Services Extensions" in the website directory.
  • Right-click the WebDav entry in the list of extensions, and click "Prohibit," then click "OK" to confirm that you want to disable WebDav.

Please note: I have not tested this last method myself so your mileage may be different. Ensure that if you go this route that you fully test the SharePoint server and determine if access to files through other mechanisms (MS Office Open dialog, SharePoint Designer, client object model applications) is also affected. As well, these instructions may vary slightly depending on your version of IIS.


- Antonio

13 comments:

  1. Good post, thank you!!
    The link on Method #2 is wrong, is the same link you mention with SAML and SP Explorer View. Can you fix it? I'm intrested in implementing that method.

    Thank you and keep up the good work!

    ReplyDelete
    Replies
    1. Thanks for pointing this out. This is now fixed.

      Delete
  2. Hello Antonio,

    Excellent post!

    I'd really like to implement #3. In my SP 2013 environment I managed to get #1 working but not #3 (which does change any behavior). Wondering if this was written for SP 2010, since the folder structure in #3 refers to version "12" of sharepoint. I tried it anyway on my version "15" with not luck. Any suggestion to make #3 work for SP 2013?

    Thanks!

    ReplyDelete
    Replies
    1. #3 Works. But make sure there are no duplicates or copy(Even if you rename the copy) in the same folder.

      For me it worked in different ways when I have copy in the same folder ControlTemplates

      Did not work in this scenario. Have DefaultTemplate-copy.ascx (Original) and DefaultTemplate.ascx(Applied the change in this to ManageWeb)

      Worked in this scenario. Have DefaultTemplate-copy.ascx (Applied the change in this to ManageWeb) and DefaultTemplate.ascx(Original)

      Worked in this scenario. Have CustomDefaultTemplate.ascx (Applied the change in this to ManageWeb) and DefaultTemplate.ascx(Original)

      Worked in this scenario. DefaultTemplate.ascx (Applied the change in this to ManageWeb) without any copies in the ControlTemplates

      Make sure you do the iisreset after the change

      Delete
    2. #3 doesn't work for me either. I don't have any copy in the same folder, but still it makes no difference as I can still map a drive to the site. It does however disable the 'open in exlorer' button for users without ManageWeb permissions.

      Any suggestions?

      Delete
    3. I used #3 and it worked for me, thanks very much! However,, I just wonder is there a similar way of getting 'Connect To Outlook' hidden, from ordinary users? When I log into the SharePoint site, as a Restricted Reader' I still can see 'Connect To Outlook', appearing, under the actions menu and I would really like to have it hidden, also.
      Thank you, for the informative and very helpful post.

      Dan

      Delete
    4. Following my post above, further experimenting with that file, which is suggested in method 3, enabled me to hide 'Connect to Outlook', also. However, ensure you have a backup of DefaultTemplates.ascx, before making any changes to it. I made a backup of it, and stored the backup, on a completely different drive, to keep it safe. Method 3, solved the problems I was having, in hiding 'Connect to Outlook', 'Export to Spreadsheet' etc....

      Delete
  3. Hello Antonio,

    This post was a good idea!

    I implemented the method # 3. Earlier work the way I expected. However, the user can still access the folders if it finds the network path. Eg: \\ sharepoin2010 \ Files.
    If he clicks on the file, the error message is displayed. If it drags the file to the desktop, sharepoint allows the copy of the file to the user, so he can access the file.

    Is there any other lock it?

    Applying the method # 1 is lost very feature.

    Thanks!

    ReplyDelete
    Replies
    1. Hi Oliveira,

      The post was good, but I believe there is a small mistake/correction while implementing Method#3.

      As per my understanding you don't need to change the template file - you can still keep the same template file. The only thing you need to look at here is the permission on the library. If the user has the permission "Design" he/she will be able to move or copy the file but soon you revert the said permission - user won't be able to copy/move the files.

      Hope the solution works for you.

      Delete
  4. Method #5: Create a custom permission level at site collection level and disable all WebDav related permissions. It works for me.

    ReplyDelete
  5. method #5 works for me too! thanks for posting.

    ReplyDelete
  6. Is there a way to implement method #3 on SharePoint online?

    ReplyDelete
  7. So how would you utilize Easylifeapp and when is it useful to you? The appropriate response is basic. It permits you to multitask on the web with the goal that you can finish a few things at the same time.https://how-to-remove.org/malware/adware-removal/yx0-pw-removal/

    ReplyDelete