SharePoint Troubleshooting: Drive Mapping Security Test Bug
At some point, you probably used Explorer View on your SharePoint site to move data in bulk.
Many times I’ve seen this taken one step further, and a drive mapped to the SharePoint Library. Interestingly enough, I’ve encountered several issues with this recently, and it took quite a while to actually confirm what was happening. There is a bit of a “bug” in this process, not so much with SharePoint but in the drive mapping protocol itself, that can lead to improper security elevation and false test results among other things. While this sounds scary at first, it is actually fairly innocent as long as you know what you are looking for and how to prevent it.
Let me provide a real-world client example. In one recent case, the Admin had utilized Explorer View and Drive Mapping on their SharePoint site. When the client contacted our SharePoint Support Team, they reported an issue where the Drive Mapping was not properly permission trimming, and so wished to disable this due to possible security problems that could result. Since they had combined drive mapping with Explorer View, this was not an easy request because disabling one disables both, (done by turning off WebDav). They were willing to give up the ability to Map Drives, but not Explorer View, so I dug into what the problem with the security trimming could be.
When you map a drive to SharePoint, you are immediately prompted for credentials. So I mapped a drive to the Library in question and used the “Connect using different credentials” option available as seen below:
I then used their Admin User to login. This allowed me to map the drive accordingly, (and view all Documents), and so far so good. I then disconnected the drive, and mapped it again, only this time using a restricted User that should not have access to particular Documents in the Library.
I was able to access the Library however, and more disconcerting, all the Documents within it, even though the User should only have had permissions to view a few of these Documents. At first glance, I thought that SharePoint was not security trimming, and as far as access goes, it was not.
This seemed like a rather large security problem to me, as anyone with the know-how could map a drive to a resource they did not have permissions to. (In this case permissions were secured to certain Documents within the Library which were shown even when mapping with the restricted User).
I won’t go on about all the troubleshooting I did – I’ll just get straight to the point. The problem is how we were creating the mapped drives, and how we were testing it. Here was the problem:
When initially mapping the drive, we started by testing with the Admin User for the environment, using the “Connect using different credentials” option. When we accessed this resource, we were provided with a security token specific to the WebDav protocol that is used for both Drive Mapping and Explorer View. This token persists much longer than normal when the SharePoint resource is accessed in this manner. So, what was happening is that we authenticated as an Admin, but even after disconnecting the drive and remapping, this authentication was still present. So, when we attempted to remap these drives with a restricted User, it accepted the restricted Users’ credentials, but we still had the authorization for the Admin User present on the workstation.
On a high level, by connecting first with the Admin User, we were authorized to access and view anything we wanted. When connecting with the restricted User afterwards, this access “carried over”. The only way I found to “clear” this authorization, was to log out of the workstation completely, then log back in. After “clearing” the authorization, I tested with the restricted User FIRST, and permission trimming worked exactly as expected, (by only showing Documents in the Library that the User had permissions on the site to view).
This is a slight bug in my opinion. However, most Users will not be mapping a drive with the Admin User first, then their own account second. You would only typically do this when testing, which would give you false results. Also, if you’re an Admin, keep in mind that when you map a drive using your Admin account from another User’s workstation, you should completely log out of said workstation before turning it back over to the User. Otherwise you may inadvertently give them elevated access to sensitive information.
I hope you find this helpful as it was a very strange issue to troubleshoot, (not to mention time consuming). As rare as this instance may seem, it has occurred several times to various clients and therefore is not as “rare” of an occurrence as I would have initially believed. Be aware: this is NOT a SharePoint problem per sé. It is more in the protocol used for Drive Mapping and Explorer View then anything inside SharePoint, but the issue still remains to date. Microsoft will most likely rectify this as they move away from this antiquated protocol in the future. As always, please leave a comment below if you have any questions and thank you for reading!