Administering Windows Servers through one port

A couple of months ago, I presented at a Financial Services Chief Security Officer’s forum here in Redmond about threat modeling and secure design. One question, totally unrelated to secure design, but still a great question, was how an admin can manage a bunch of Windows servers using one, and only one port.

Think Secure Shell (SSH) on *nix, without using SSH!


I answered the question as well as I could, but it got me doing a little more research – I asked some of the network ops guys I know and they all said the same thing, Terminal Services with “Disk Drive Redirection” enabled.


Let me explain, managing computers involves many tasks, as you well know, such as adding users, setting ACLs, copying files and so on on the target computer. Normally, on Windows this could use a number of ports, but in a highly constrained/restricted/secured/paranoid environment, it’s quite normal to keep the number of open ports to a minimum.


So how can you do all this over one port? This is where TS comes in. It turns out TS is not just about sharing a desktop on a remote computer, it can also be used to copy files, and rather using the SMB ports (139 or 445) it’s all done over port 3389!


All you do is connect to the remote machine, and make sure the client machine has the local drives redirected. To do this open the Remote Desktop Connection application, click the Local Resources tab, and make sure “Disk drives” is checked.


Now that this is all done, when you connect to the remote computer, you can connect back to file shares on the client using \\tsclient\<sharename> syntax. Or you can open My Computer on the server, and you’ll see the client’s shares appear like any other file share. Very cool!


I have to be honest, I really wasn’t convinced it was true, so I check it out; I ran netmon on the remote computer, connected from the client, copied some files and sure enough the only port used was 3389!


And of course, the traffic is encrypted.


Finally, for really secure environments, you can enforce a smartcard logon (let’s face it, passwords are atrocious!) to TS and restrict which hosts can access the TS port (3389) using IPSec policy or a firewall.


Comments (11)

  1. Sean McLeod says:

    How about using a VPN connection to the machine you want to administer.

    Single port open on the server and you can run any protocols over it, SMB, Terminal Services, SQL network queries, telnet, custom protocols etc.

    And enforce smartcard logon for the VPN connection.

  2. stefandemetz says:

    I heard that IPSEC itself needs several ports to run for IKE and other protocols I don’t remember now

  3. Another option – one i use – is to install SSH on a windows server ( You can then tunnel *all* tcp connections (e.g. ts) through port 22. no more open 3389s on the firewall ๐Ÿ™‚

    i wrote a paper on that topic (german)

    SSH can also be secured through password and/or key authentication…plus you get a command line terminal session from every computer that has a ssh client (google for putty.exe)….

    one question though – is it possible / and how – to enable ts smartcard logon if the server is standalone – no domain – think isolated dmz box????



  4. RichB says:

    I worked at one government department which used terminal services over an SSH connection to get added security ๐Ÿ™‚

  5. Sean McLeod says:

    What is the advantage of using SSH as opposed to standard VPN (PPTP VPN or L2TP IPSec VPN)?

    Windows 2000 onwards comes standard with the client side and server side of VPN as well, so no need to install additional SSH client and server software.

    But more on the technical side, what advantages if any are there with SSH as opposed to standard VPN?

  6. peter says:

    One problem for using Terminal Services remotely is that it isn’t same as console. It just is remote desktop. Some software, or administrative tasks require you to be on winsta (Yeah, there are methods to overcome this but still slight pain)

  7. I cannot agree with one thing here, to correlate SSH and RDP.

    Logs of the session: All of the key sequence and what server you accessed thru port forwarding. This means that you can track the usage of the SSH and other things per user, without sweat. Can Windows servers do the same thing?

    I am not saying "RDP is no good" but there is a significant difference here with two of them.

    SSH is an industry-wide, de facto standard that is used not only with *nix nodes but also appliances like firewalls and switches, not only of Cisco but avaya, Alteon, Allied-telesis, Cobalt(RaQ) and so many other manufacturers.

    I know some implementations of RDP clients for other platforms but the core is still Windows specific… Not in other platforms, you know.

    So I think they should not be aligned in the same line, and we should combine them… IPSec may do the similar thing but the quality of related logs may not be the same with that one of SSH…

  8. Klemens Kolb says:

    How do you enforce smartcard logon on TS?

  9. Michael Royer says:

    Jumping back to Peter’s issue of the winsta issue…under Windows Server 2003 getting an actual console desktop on the server is as easy as adding "/console" to the command line when you launch the RDP client. In other words, "c:>mstsc.exe /console" will get you to a place where you are quite literally at the winsta session.

    In fact, if you administer a number of servers using the Remote Desktop MMC snap this is done by default (