Monday, August 22, 2005

Windows Remote Administration Options

This morning I worked with several remote administration tools on my Windows Server 2003 system. First I enabled the native Remote Desktop (aka Terminal Services) capability via My Computer -> Properties -> Remote

At this point I am only letting administrator connect remotely. Since administrator can connect remotely by default once the service is activated, I didn't need to make any other changes. Once Remote Desktop is listening, it will appear active on port 3389 TCP.

To access the Windows server remotely from Unix using the RDP protocol, I use Rdesktop. It's available in the FreeBSD ports tree as net/rdesktop. I like the option to change screen geometry, e.g., 'rdesktop -g 80% 192.168.2.2'.

To access the RDP server from my Windows 2000 laptop, I installed the MSRDPCLI.EXE package.

Next I tried RealVNC. This program has client and server components. I installed the entire package on the Windows server. Setup is fairly simple, and the server should be configured to accept clients that enter a pre-defined password. RealVNC starts two listening services. One can access a Web page with a Java-enabled VNC service on port 5800 TCP. The default native VNC server listens on port 5900 TCP.

To access the Windows server remotely from Unix using the VNC protocol, I use vncviewer, packaged with RealVNC. It's available in the FreeBSD ports tree as net/vnc. To send ctrl-alt-delete through VNC, I like to hit the F8 key to bring up a VNC menu, through which I select "Send ctrl-alt-del".

There is an importance difference between using RDP and VNC on Windows Server 2003. RDP is a Terminal Services application, which allows multiple users to remotely interact with the server. VNC takes control of the physical desktop. For example, I was able to run one RDP instance and then use VNC to connect to the server. Neither session was interrupted by the other. Also, RDP seems to be more efficient and responsive, although I have not sought to tweak VNC.

Note that (thanks to comments from Blog readers), I found Rdesktop allows one to "attach to console" if passed the -0 command, like this:

rdesktop -0 192.168.2.2

This eliminates the need to use VNC, in my opinion.

I noticed that I could not get VMWare to start a guest OS when I was logged in to the Windows Server 2003 box using RDP (not attached to the console). I could start a guest when logged in using VNC. I typically set a screen geometry because VNC doesn't appear to have a menu option for it, e.g. 'vncviewer geometry="1024X768"'.

With rdesktop -O, I can attach to the console and hence start VMs properly over RDP.

inally I installed OpenSSH. I considered installing the SSH for Windows package, which is a stripped-down Cygwin version. Since that program had not been updated in over a year (i.e., 3.8.1), I decided to use the complete Cygwin version. Nicholas Fong's guide was extremely helpful.

I followed all of his instructions. Remember to add a new environment variable where 'variable name' is CYGWIN and 'variable value' is ntsec tty. Also add ';c:\cygwin\bin' to the PATH.

I noticed a different set of prompts when I ran 'ssh-host-config', so here is how I proceeded.

$ ssh-host-config
Generating /etc/ssh_host_key
Generating /etc/ssh_host_rsa_key
Generating /etc/ssh_host_dsa_key
Generating /etc/ssh_config file
Privilege separation is set to yes by default since OpenSSH 3.3.
However, this requires a non-privileged account called 'sshd'.
For more info on privilege separation read /usr/share/doc/openssh/README.privsep.

Should privilege separation be used? (yes/no) yes
Warning: The following function requires administrator privileges!
Should this script create a local user 'sshd' on this machine? (yes/no) yes
Generating /etc/sshd_config file

Warning: The following functions require administrator privileges!

Do you want to install sshd as service?
(Say "no" if it's already installed as service) (yes/no) yes

You appear to be running Windows 2003 Server or later. On 2003 and
later systems, it's not possible to use the LocalSystem account
if sshd should allow passwordless logon (e. g. public key authentication).
If you want to enable that functionality, it's required to create a new
account 'sshd_server' with special privileges, which is then used to run
the sshd service under.

Should this script create a new local account 'sshd_server' which has
the required privileges? (yes/no) yes

Please enter a password for new user 'sshd_server'. Please be sure that
this password matches the password rules given on your system.
Entering no password will exit the configuration. PASSWORD=obscured

User 'sshd_server' has been created with password 'obscured'.
If you change the password, please keep in mind to change the password
for the sshd service, too.

Also keep in mind that the user sshd_server needs read permissions on all
users' .ssh/authorized_keys file to allow public key authentication for
these users!. (Re-)running ssh-user-config for each user will set the
required permissions correctly.

Which value should the environment variable CYGWIN have when
sshd starts? It's recommended to set at least "ntsec" to be
able to change user context without password.
Default is "ntsec". CYGWIN=

The service has been installed under sshd_server account.
To start the service, call `net start sshd' or `cygrunsrv -S sshd'.

Host configuration finished. Have fun!

Administrator@moog ~
$ net start sshd
The CYGWIN sshd service is starting.
The CYGWIN sshd service was started successfully.

Using SSH to access Windows is the most bandwidth-efficient remote access system possible.

ssh administrator@192.168.2.2
administrator@192.168.2.2's password:
Last login: Mon Aug 22 06:20:58 2005 from 192.168.2.5

Administrator@moog ~
$ df -h
Filesystem Size Used Avail Use% Mounted on
C:\cygwin\bin 9.8G 5.1G 4.7G 53% /usr/bin
C:\cygwin\lib 9.8G 5.1G 4.7G 53% /usr/lib
C:\cygwin 9.8G 5.1G 4.7G 53% /
c: 9.8G 5.1G 4.7G 53% /cygdrive/c
g: 60G 53G 7.3G 88% /cygdrive/g
h: 70G 50G 20G 73% /cygdrive/h

Administrator@moog ~
$ who
sshd_server tty0 Aug 22 06:20 (MOOG)
Administrator tty1 Aug 22 06:56 (192.168.2.5)

It appears the 'who' command is not aware of an existing RDP session.

I was hoping I would find an easy way to configure Windows through a serial port. Unfortunately, Windows is not Unix. The closest approximation I found was Emergency Management Services (EMS), which requires motherboard support. EMS is definitely not as simple as modifying /etc/ttys.

I'm concerned with remote administration because this Windows server is in my lab. Also, I am trying to imagine the best way to change the system's IP address remotely, or at least in a headless situation. For example: I bring my Shuttle Windows server to class. The box has no monitor. I decide I need to change the system's IP address to use DHCP in a classroom setting, or to set a new static IP address. Using my laptop, I connect to the server (using on of these methods) and change the IP.

I plan to use one or more of these netsh commands. I can run these as a batch file or through the scheduler.

netsh interface ip show config

netsh interface ip set address name="Local Area Connection" static 192.168.0.100
255.255.255.0 192.168.0.1 1

netsh -c interface dump > c:\location1.txt

netsh -f c:\location1.txt

netsh interface ip set address "Local Area Connection" dhcp

netsh interface ip set dns "Local Area Connection" static 192.168.0.200

netsh interface ip set dns "Local Area Connection" dhcp

These are not the actual commands I would run, only examples of what is possible.

From a Windows system, one other option exists: PsExec. For example:

C:\Program Files\pstools>psexec \\192.168.2.2 -u administrator -p "password"
cmd.exe /c cmd.exe

PsExec v1.58 - Execute processes remotely
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS\system32>cd
C:\>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.2.2
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.2.1


Does anyone have any suggestions?

17 comments:

Anonymous said...

It's best encrypt VNC traffic using SSH port forwarding. I believe there are programs with which you can sniff and basically watch a VNC session stream. I know there have been security issues with it in the past to include brute forcing. Plus, if memory serves correctly there was also an issue with a constant password encryption seed - I've not used VNC in about 3 years, so these issue may have been solved. It does make remote admin easy since it is cross-platform.

Anonymous said...

Q: What's the best Windows remote administration tool?
A: A car.

Joao Barros said...

I admin 100+ Windows machines and since Terminal Services Advanced Client is not that advanced (can't even rearrange connections) I looked for an alternative and have been happy since: RoyalTS from code4ward.

RoyalTS: http://www.code4ward.net/CS/blogs/c4w/articles/royalts.aspx
Terminal Services Advanced Client: http://www.microsoft.com/downloads/details.aspx?FamilyID=33AD53D8-9ABC-4E15-A78F-EB2AABAD74B5&displaylang=en
The new version of tsmmcsetup.exe can be found in the Windows Server 2003 Administration Tools Pack: http://www.microsoft.com/downloads/details.aspx?FamilyId=C16AE515-C8F4-47EF-A1E4-A8DCBACFF8E3&displaylang=en

chuck said...

Richard,

Yet another great post. Thanks for sharing the info that you do!

I don't necessarily like this solution however in your case it might be helpful. PCAnyhwhere has a direct connection via null modem capability:
(instructions)
http://service1.symantec.com/SUPPORT/pca.nsf/docid/2001021513251112?Open&src=&docid=2001041212035112&nsf=pca.nsf&view=docid&dtype=&prod=&ver=&osv=&osv_lvl=

OR, add another NIC to the box and use that as a management network that will never be changed (typically private address space, since your using 192.168.x, try the 10.10.x.x network). With that solution you could just use the apps you've already installed.

Hope that helps.

Take care,
Chuck

Richard Bejtlich said...

Great comments. I think the extra NIC idea is the easiest to implement. Thank you!

Joe said...

You might want to take a look at Microsofts Services for Unix. Although it doesn't come with a native SSH server, you can get one (plus several other packages) from InteropSys -- all for free, of course.

I personally like this approach better than the Cygwin one since it has a more native-as-in-microsoft-built-it-themselves feel.

Great article, by the way!

J_Kenpo said...

Rich,

Depending on what kind of "remote administration" you intend on doing, you may not need physical access to the server. The MMC provides quite a few additional tools for remote administration of things like services, users, IIS, remote startup and shutdown, etc. The admins here use a modified VNC client that authenticates through AD. There is also another product called DameWare that local tech support seems to be fond of. And if thats not quite as robust as you need, you might try looking into a remote KVM card (Ive been wanting to try one of these myself), such as http://www.techland.co.uk/index/eric , http://www.techland.co.uk/index/lara , or http://www.minicom.com/kvm.htm . (A Google search for Remote KVM or KVM over IP should return similar products). If you get a chance to try one of these products out, lets us know :)

Ipslore said...

I concur with the suggestion for a second NIC. In the "unorthodox" way that you're using this server[1], that is the easiest to implement. And, bonus besides, you can restrict traffic to administrative services to only this admin interface.

[1] Really. By and large, Windows servers are given static network configurations. Moving around is not part of their design.

Joao Barros said...

Apart from the need to connect to a Windows 2000 console (ex: some "stupid" applications don't even install through TS), which is not Richard's case as it's using W2K3 and has Remote Desktop, I don't see any advantage of VNC or DameWare (which some security products see as 'malicious') over RDP/TS.

Anyone has good selling arguments that say otherwise?

Over the remote administration issue, and considering Richard's needs, I second the 2nd NIC idea: easy to restrict access to and all around bang for the buck.

Bryan said...

Just a comment on RDP - with the newer terminal services client in XP, you can also connect to the 'console' session similar to what you mentioned with VNC.

This RDP client can be installed on Win2k systems by getting the Win2003 or XP adminpak.msi from MS, or following the instructions at http://www.petri.co.il/download_rdp_5_1.htm

Also, linux rdesktop/tsclient can connect to the 'console' rdesktop as long as you have tsclient > version 0.140 and rdesktop > 1.3, if I remember right.

Bryan said...

Oops, I should have made clearer in prior post-

Win2000 terminal server never serves the console session (and I don't beleive it can be upgraded to do so), but with the right (rdp5.1 or above) client Win2000 can view the RDP console session served by WinXP and Win2003.

The more recent versions of Windows serve a console session, probably because so many of us Windows admins complained about the lack of one in Win2k!

I know all this probably sounds backwards to X11 users here. In Windows world the server is the one exporting a desktop and the client is the one viewing a remote desktop.

Richard Bejtlich said...

Bryan,

I am missing something -- how can I connect to the "console" using RDP and MSRDPCLI.EXE (version 5.1)? I don't see any option to do so.

Thank you!

Anonymous said...

I would have to concur with three posts above mine:
1) Windows is not meant to be moving around, especially if you're switching DHCP and static at any time in that move.
2) Second NIC is your best option.
3) Tunnel VNC through an SSH connection.

I think you'll be happiest with this setup in the long run. Combine that with netsh and psexec to shovel you a cmd window or some quick batch files with variables and you should be good!

-LonerVamp

Bryan said...

Richard:

from commandline, do

mstsc /?

... and all will become clear.

Example connection to win2003 server:

mstsc /v:192.168.0.10 /console

it's possible to connect to the same machine three* times simultaneously from the same system. Once to the console, and 2x to non-console desktops.

*If terminal services is in administrative mode. More than three if in full user mode.

Bryan said...

...as long as I'm being technically correct ...

I'm surprised some here think that Windows server somehow 'needs' a static IP. Richard-the-human may want one, so he doesn't have to query whole broadcast ranges to find a system, but Windows-the-OS has no real need of a static IP other than in certain limited roles, like DNS server for instance. It's outside the scope of this discussion, but certainly possible to run most of a server room via DHCP addresses!

One NIC would be fine, /if/ you always returned it to the known IP address before shutting down and moving on to the next site. As for the problem of knowing what IP the system is going to get, if you get the Resource Kit's 'dhcploc.exe' you can issue a fake DHCPREQ and see what the server would send you. This method might save you a PCI slot you might be able to put to better use (like wireless)!

A nice download roundup of the various Resource Kits can be found at http://www.dynawell.com/support/Reskit/win2k3.asp

Anonymous said...

Check iShadow Desktop - supports RDP, VNC and even ICA. Probably the best tool when supporting 50+ win. servers.

http://www.ishadow.com/tabid/88/Default.aspx

John

buy said...

Cat5 extender allows you to extend using regular & inexpensive Cat5e or Cat6 UTP cable. These extenders include local & remote units. Cat5 Extender allows you to extend to long lengths over Cat5/6/7 and you no longer need to run long bulky coax cables. The available options are audio extenders, RS232 extenders,
DVI-D fiber optic cable Extender
, firewire optical extenders, USB extenders, USB KVM extender, Video Splitter extender via Cat5

and VGA extenders.

KVM extender allows you to extend PS2 keyboard, PS2 mouse and VGA video remotely up to 1000 feet away from a computer. KVM extenders are ideal for applications like public broadcasting, banks, classrooms, tradeshows, and other mission critical locations.

We also carry a wide range of DVI-D extender products like DVI-D Single link fiber optic extension cables, DVI-D repeater, DVI-D Extender Cat5, DVI-D Splitter Extender Cat5, DVI-D Single Link Fiber optic extender, DVI-D dual link fiber optic extender and DVI-D USB Fiber Optic extender.