One particularly handy feature of recent Terminal Server (MSTSC) clients is the capability to redirect drives to the remote TS / RDP server for use in the RDP session. This is the mechanism by which you can go to \\tsclient\<driveletter> and access your data over the RDP session, without having to try and map a drive back the computer hosting the session via SMB or the like.
Although this capability is convenient, in its present form it is limited to just mapping entire drive letters; there does not appear to be a way to limit the scope of the filesystem that is redirected to a remote system to anything less than an entire drive letter. This is unfortunate, as especially with RDP-TLS, drive mapping over RDP presents a simple, secure, and attractive file copy mechanism for computers that that you want can RDP into.
The unfortunate part is more that if you don’t trust the computer that you are remoting into completely, then it’s rather dangerous to give it unrestricted access (within the confines of the user account mstsc.exe is executing as) to local drives; there’s a lot of damage that a malicious RDP server could do with that kind of access. Even if you’re a limited user, the RDP server could still steal and/or trash all your personal documents (which are again usually the most valuable data on a computer anyway).
There is, however, a little trick that you can use to try to limit the scope of RDP drive mappings. Recall that mstsc redirects drives based on drive letters; this would at first glance seem to prevent one from using any finer granularity of access than entire volumes with respect to which portions of the filesystem are made available to the RDP server. This is not actually the case if one is a bit clever, however, because RDP can also remote drive letters that correspond to mapped network drives, and not just local volumes that have a drive letter associated with them.
With this trick, one can, say, map a drive letter to localhost at a directory under a particular drive, to be the “root directory” that is presented to the remote RDP server. From there, it’s possible to just redirect the mapped drive letter over RDP and restrict what portions of the local filesystem are accessible to the RDP server.
Note that until Vista, plain users cannot arbitrarily map to \\localhost\c$ (or other built-in shares). As a result, if you’re in the pre-Vista boat (on the client side), an administrator will need to create the share for you (since you are running as a limited user, right?) so that you can map a drive letter to it.
Edit: Hyperion points out that you can use the “subst” command to achieve the same effect as mapping a drive letter to localhost. This is actually better than what I had been doing with drive mappings, as in downlevel (pre-Vista) scenarios, you don’t have the extra headache of having to get an administrator to share out a directory for you to be able to map it as a plain user.
Why not use good old “subst”? Doesn’t even need admin rights, in Windows XP at least.
http://en.wikipedia.org/wiki/Subst
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/subst.mspx
Good catch – completely slipped my mind. Tested it and that works, which is more convenient than the drive mapping solution that I’ve been using thus far.
This is good factor as pointed. Setting discretionary rights
for large databases of users is somewhat complex especially
where resources have to be made centralized.
Its good to set mapping directly on resources which is to
be made available.
Any ideas on how to selectively map drives using rdp? We have a terminal server with about 6 substed drives and the xp pro clients have network mappings to the same 6 drives. When an RDP client connects from an XP Pro client they get the 6 substed terminal server drives, their own C: D: E: etc and 6 more mappings to their network drives that are the same as the substed drives. Sigh
Well, client-side, the RDP 6 client (also available as a download for XP) lets you pick drives to map to the terminal server by drive letter. (See Options -> Local Resources tab -> More button.)
The \\tsclient redirection works even on XP Pro over remote connection … surprise! :)
Good stuff. Does anyone know how to limit the access to drive redirection to certain users, i.e. allow some users to redirect their drives but not others?
A Group Policy can be applied to the Term Server so that it either allows or disallows drive redirection, but this appears to be global for all clients.
there’s a lot of damage that a malicious RDP server could do with that kind of access.
What kind of damage? Is there any documentation about what a rogue process on the RDP server could do to the client through the mapped local drives? Could malware on the server infect the client computer through this tunnel?
ToddP: Anything you can access via \\tsclient in your TS session, code on the server can access. This means (if you have the partition with your user profile shared) all of your user profile data, and if you’re an admin on the box running mstsc, even more things. Essentially, you are giving the RDP server full filesystem access as the user you are running mstsc.exe on your local machine as to all drive letters shared out via \\tsclient.
I am running FC 9, and I do not see an option on my TSclient window to map drives, there is only options for Remote Computer Sound and Keyboard in the Local Resources tab. How do I add this ability?