kmruss
asked on
Hiding mapped remote drives on Terminal Services (\\tsclient\c)
I'm trying to use a client's remote desktop mapped drive which is normally like \\tsclient\c to copy some files from the REMOTE computer onto the server in a logon script.
However, the major problem I'm having is that I don't want that drive to then be available to the user after the logon script runs. It seems that you can't 'DISABLE DRIVE MAPPING' and still be able to map manually (through netuse).
I also can't seem to get the drives to disappear through net use \\tsclient\c /delete.
It says it deletes the drive - however they still show up and are accessible under Windows Explorer (My Computer).
Also, you can still type dir \\tsclient\c right after you delete it - and get a successful directory listing.
Have even tried hiding and preventing access to the drives through GPEDIT - however it won't hide the \\tsclient drives - only local drives (A,B,C,D,etc).
Mainly, we need to be able to copy the files remotely from their computer - but don't want a security risk with them being able to copy files from our server back to their remote computer.
Really need an answer quickly - and am awarding 500 points because of this.
However, the major problem I'm having is that I don't want that drive to then be available to the user after the logon script runs. It seems that you can't 'DISABLE DRIVE MAPPING' and still be able to map manually (through netuse).
I also can't seem to get the drives to disappear through net use \\tsclient\c /delete.
It says it deletes the drive - however they still show up and are accessible under Windows Explorer (My Computer).
Also, you can still type dir \\tsclient\c right after you delete it - and get a successful directory listing.
Have even tried hiding and preventing access to the drives through GPEDIT - however it won't hide the \\tsclient drives - only local drives (A,B,C,D,etc).
Mainly, we need to be able to copy the files remotely from their computer - but don't want a security risk with them being able to copy files from our server back to their remote computer.
Really need an answer quickly - and am awarding 500 points because of this.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
have you tried putting a dollar sign $ after the shared drive to hide it ?
ASKER
cro and tsmvp,
Both great solutions - cro: I like the second link you gave me beacuse it has all the drive letters pre-figured for you (not too hard to add but still nice to have it there for reference).
However, I also really like your solution tsmvp - as it effectively 'disables' the remote drive mapping all-together (as far as the 'normal' method people or a malicious user would know about). The only problem I see is that possibly the program only works as sending from server TO client ... and I need it to go from CLIENT back to SERVER). I may try this anyway to see if it will work with just me reversing the paths - but the description on his website acts like it may not).
mcse: This is not a drive I have 'shared' - but more so drives that are from the REMOTE client (client connecting into the Terminal Server). I NEED a way to copy files FROM the client for this project - however I don't want the clients to SEE those drives - and unfortunately with drive mapping on, there doesn't seem to be an obvious way (other than the above registry fix) to hide those drive letters - as they auto-map regardless if the option is turned on. As mentioned, even deleting them from the command line, they still show up in Explorer which is unacceptable - so hopefully one of the above methods will work.
Thanks guys for your responses - I will try them and post back.
Both great solutions - cro: I like the second link you gave me beacuse it has all the drive letters pre-figured for you (not too hard to add but still nice to have it there for reference).
However, I also really like your solution tsmvp - as it effectively 'disables' the remote drive mapping all-together (as far as the 'normal' method people or a malicious user would know about). The only problem I see is that possibly the program only works as sending from server TO client ... and I need it to go from CLIENT back to SERVER). I may try this anyway to see if it will work with just me reversing the paths - but the description on his website acts like it may not).
mcse: This is not a drive I have 'shared' - but more so drives that are from the REMOTE client (client connecting into the Terminal Server). I NEED a way to copy files FROM the client for this project - however I don't want the clients to SEE those drives - and unfortunately with drive mapping on, there doesn't seem to be an obvious way (other than the above registry fix) to hide those drive letters - as they auto-map regardless if the option is turned on. As mentioned, even deleting them from the command line, they still show up in Explorer which is unacceptable - so hopefully one of the above methods will work.
Thanks guys for your responses - I will try them and post back.
ASKER
Oh also tsmvp: I've considered ftp as an alternative - however I've used ftp for a long, long time - and as good as it is, sometimes it just seems to have 'control connection' problems - and is a little less reliable than drives that have been mapped. I'm sure some would try to disagree, but I've seen it from my experience.
Fact is, if the user is connected to the server, then that drive is mapped I'd say almost 100% of the time. However on the ftp program, it leaves room for 'timeouts' and delays that ftp is so finicky about (and even port problems) - if you've used it a lot. The logging portion of ftp is a huge plus, but with a good batch file I'm going to write, I'll have logging as well (copy errors etc. will be logged - and successful copies too) - so for me, since this is times 27 remote clients (and not just 1) - I'd rather go with the option that is almost 100% reliable and that I don't have to babysit constantly.
Fact is, if the user is connected to the server, then that drive is mapped I'd say almost 100% of the time. However on the ftp program, it leaves room for 'timeouts' and delays that ftp is so finicky about (and even port problems) - if you've used it a lot. The logging portion of ftp is a huge plus, but with a good batch file I'm going to write, I'll have logging as well (copy errors etc. will be logged - and successful copies too) - so for me, since this is times 27 remote clients (and not just 1) - I'd rather go with the option that is almost 100% reliable and that I don't have to babysit constantly.
ASKER
Update:
cro: Well, I tried all kinds of combinations - especially the disable (and hide both) ALL drive letters - which works to hide/disable local SERVER drive letters - but does not hide the user's (clients) mapped drives that have to be enabled for copying files to work. You can also however even use the command-line to allow access to those 'hidden/disabled' drives still too - which to me is still unacceptable from a security standpoint - even with 'run' disabled. Also, with the client's drives showing, I again tried net use \\tsclient\c /delete - which SAYS it deletes it - but you can still see that drive in My Computer/Explorer - and also still access it from a command-line (and still copy and file from the server back to the client).
Seems pretty crazy and amazing that Microsoft so easily overlooks this huge security hole in their software but not allowing SOME sort of transfer control on this short of fully disabling it. Thanks for your response though cro - was worth a shot for sure.
tsmvp: The first suggestion unfortunately was just for transferring from SERVER back to client - as I contacted and spoke with the author about it. He said it could be 'easily' modified - but not a programmer myself and then recommended hiring someone to custom write something - which doesn't fit our time schedule in moving forward with this project quickly.
However, did you mean the program 'TSFTP' by WTSSOFT.COM? I am currently looking at this solution to see if it would work - however you said 'WTSFTP' and not 'TSFTP' - and the link was apparently broken on that too - so I assumed you were strictly referring to the FTP program of a similar name (WSFTP). I'll update and let you know how this goes.
Thanks.
cro: Well, I tried all kinds of combinations - especially the disable (and hide both) ALL drive letters - which works to hide/disable local SERVER drive letters - but does not hide the user's (clients) mapped drives that have to be enabled for copying files to work. You can also however even use the command-line to allow access to those 'hidden/disabled' drives still too - which to me is still unacceptable from a security standpoint - even with 'run' disabled. Also, with the client's drives showing, I again tried net use \\tsclient\c /delete - which SAYS it deletes it - but you can still see that drive in My Computer/Explorer - and also still access it from a command-line (and still copy and file from the server back to the client).
Seems pretty crazy and amazing that Microsoft so easily overlooks this huge security hole in their software but not allowing SOME sort of transfer control on this short of fully disabling it. Thanks for your response though cro - was worth a shot for sure.
tsmvp: The first suggestion unfortunately was just for transferring from SERVER back to client - as I contacted and spoke with the author about it. He said it could be 'easily' modified - but not a programmer myself and then recommended hiring someone to custom write something - which doesn't fit our time schedule in moving forward with this project quickly.
However, did you mean the program 'TSFTP' by WTSSOFT.COM? I am currently looking at this solution to see if it would work - however you said 'WTSFTP' and not 'TSFTP' - and the link was apparently broken on that too - so I assumed you were strictly referring to the FTP program of a similar name (WSFTP). I'll update and let you know how this goes.
Thanks.
Hi Kmruss and gurus,
Did you find any solution yet?
I hide successfully client local drive and I want to hide the client mapped drives in Citrix and terminal service too. Therefore, client user can not browse its hidden drive during a connection.
TS has an option to hide its local drive during connection, but how can we set this setting as a fixed setting.
I do not know how to do on Citrix.
Pls help,
Thanks
Did you find any solution yet?
I hide successfully client local drive and I want to hide the client mapped drives in Citrix and terminal service too. Therefore, client user can not browse its hidden drive during a connection.
TS has an option to hide its local drive during connection, but how can we set this setting as a fixed setting.
I do not know how to do on Citrix.
Pls help,
Thanks
ASKER
The first option from user tsmvp didn't work since I needed to transfer files FROM the client to server (And not from server to client) - but I wound up using the 'TSFTP' software from WTSSOFT.COM per tsmvp's recommendation. It didn't work for me security-wise fully right out of the box - since it still allowed the regular user to run the program (if they were aware of the program .exe being available).
To combat this, I had to also get a special 'RunasSpc' program (http://www.robotronic.de/runasspcEn.html) that allowed you to make a 'script/batch' file so to speak that allowed me to run the TSFTP program in a logon script for each user AS Administrator - yet encrypted this 'script' file so the user couldn't determine the Administrator password. The 'Runasspc'
A semi-hokey way to have to do it - but it has been working very well. And the 'Runasspc' program has 'tamper-proofing' by CRC check if anyone tries to change the encrypted 'script' file.
I want to award tsmvp the points in this case - but would be grateful if someone ever comes up with a good way to still and truly 'disable' drive mapping for regular clients - however still enable it for Admins etc. On that particular server, I just had to disable drive mapping altogether and use the above solution - which keeps me from using Drive Mapping as well. I just do the Drive Mapping via our Main Server instead. I could of course throw up a private or encrypted FTP I suppose - but the less security risks the better I believe.
To combat this, I had to also get a special 'RunasSpc' program (http://www.robotronic.de/runasspcEn.html) that allowed you to make a 'script/batch' file so to speak that allowed me to run the TSFTP program in a logon script for each user AS Administrator - yet encrypted this 'script' file so the user couldn't determine the Administrator password. The 'Runasspc'
A semi-hokey way to have to do it - but it has been working very well. And the 'Runasspc' program has 'tamper-proofing' by CRC check if anyone tries to change the encrypted 'script' file.
I want to award tsmvp the points in this case - but would be grateful if someone ever comes up with a good way to still and truly 'disable' drive mapping for regular clients - however still enable it for Admins etc. On that particular server, I just had to disable drive mapping altogether and use the above solution - which keeps me from using Drive Mapping as well. I just do the Drive Mapping via our Main Server instead. I could of course throw up a private or encrypted FTP I suppose - but the less security risks the better I believe.
ASKER
The solution worked with the 'TSFTP' program - however still doesn't let us fully 'hide drive mapping' for clients and enable it for Admins, etc. This may not be possible though - and I appreciate tsmvp for putting me onto the software that he did - since I found a way to make it work.
ASKER
I also meant to mention in the above that when I used the 'Runasspc' program to run the TSFTP software in the logon script AS an Administrator, that I also of course fully locked down the TSFTP .exe to where it couldn't be run directly from a regular 'user' or even 'power user' (admin only).
Hence, by doing so, and using the 'Runasspc' program to run the TSFTP program in the regular user's logon script with Admin priveleges, it effectively let me 'lock down' the program to where any regular user couldn't take advantage of it.
It would be nice to find a solution that had built-in security like this - or even if the WTSSOFT company would update the program to have more security - but it works nevertheless as I've done it.
Hence, by doing so, and using the 'Runasspc' program to run the TSFTP program in the regular user's logon script with Admin priveleges, it effectively let me 'lock down' the program to where any regular user couldn't take advantage of it.
It would be nice to find a solution that had built-in security like this - or even if the WTSSOFT company would update the program to have more security - but it works nevertheless as I've done it.
you can try to hide drive letters in My Computer. Maybe this article help:
http://articles.networktechs.com/59-p1.php or
http://www.pctools.com/guides/registry/detail/148/
Hope this help!