I took a quick look at "Remote Administration for Windows Server" and was a bit disappointed. I'm taking a Windows Server 2003 class right now and have discovered that I can administer my domain remotely with very little tinkering. While the first step in the article ("Secure Those Servers") is very good, the second step is unnecessary (and I don't know about the third because we don't have/allow remote access) if you're talking about basic administration (not more advanced stuff like installing software on the server).

Depending on the version of Windows on your client and server, you should be able to install the adminpak.msi file onto a client computer. Here I did this today with a downloaded file from the MS website on my WinXP Pro SP2 machine to administer my Windows 2000 Server, the domain controller. Confusingly (for me, anyway), I had to download the adminpak for Windows Server 2003, but so far, it seems to work fine. I simply logged on as admin, installed the adminpak, and can now administer the server as though I were there (the only small thing is I have to log off and re-log on because my regular account isn't an administrator account). While I imagine the steps are probably a little different depending on your server/client OS combo, I can't imagine that most folks are unable to do the same thing.

I intend to do as much administration work remotely, here at my desk, as I can. Our server room is a closet, with an uncomfortable stool and even less space. It's also poorly ventilated, so we keep it dark and scary to minimize heat.

econlon, you're absolutely correct that confirming the security of the Administrator group may be unnecessary--if the reader does not intend to open terminal services to the public Internet.

I put those instructions in there because I see nonprofit organizations with a very weak (or even blank!) password for the Administrator account. So before I proceeded to the bit about forwarding the RDP port to the server, I figured I had better mention something about passwords. That section titled "secure those servers!" bothers me a bit, though, since it seems like someone might think that is all that is necessary to be "secure".

I'm really glad you mentioned the administrative tools. That is certainly a handy way to administer a server over a LAN, even without using terminal services. It's funny--even before I read your comment I was thinking "gee, I should have mentioned that."

For security purposes I think it's best to use the adminpak tools only in conjunction with the RunAs contextual menu (shift+right-click), so the administrator need not leave her computer logged in with an account with admin privileges. That's a little tricky to explain, so I might put the adminpak and runas in another article. Incidentally, this avoids the need to log off and log back on that you mention.

Try it: hold down the shift key and right click on one of the Administrator tools, such as Active Directory Users and Computers. Choose "Run As" from the contextul menu. When prompted enter the credentials for an admin account. Now you're logged in with a regular user account, but you're running just this one MMC with admin rights. Neat, huh?

One thing I might add to this article, though, is mention of the terminal services Web client. That allows the administrator access to the server from any Windows workstation, even if the Remote Desktop client isn't installed. And that is certainly handy.

For example, say I want to do some work for a user, and discover I need to log in to his account. I don't know his password. His computer is running Windows 2000 Professional, and neither the remote desktop client nor the adminpak are installed. No problem! I log in using my account, connect to the server using the web client, change the user's password, then log back in using his account. Before I leave I put a post-it note on his screen letting him know that he can get his new password in his voicemail.

Thanks for the comments, if you have any more I would really like to hear them.

Yours,

Zac

[added links 5/5/2005]

There is one other thing, though not directly related to the article, that's recently been suggested to me. I haven't done this yet myself, but I hope to do so soon.

It's been suggested to me to change the name of the administrator account from "Administrator" to something else, then to create an account called "Administrator" with extremely limited security rights, or even "dummy" rights. There are two main reasons for these actions: for renaming, to prevent a cracker from knowing one-half of a user logon-password combo; for the "dummy" rights, i.e., possibly to run scripts or other things which might even appear malicious, to scare off an intruder who may manager to crack into this Administrator account.

While I don't know that I'll assign those "dummy" rights, I do know I'll at least rename the account. It just seems like a real good idea.

Just to digress a little, there are also other remote admin methods people might like to investigate - particularly for remote admin tasks behind your firewall and/or through secured VPN tunnels where security isn't (as much) of an issue as administration over the open Internet.

[ UltraVNC ] is a great remote admin utility supportive of Windows Domain authentication, that especially when used in conjunction with an XP workstation driving two monitors makes administering a remote server a breeze - It's really no different to having the server monitor sitting on your desk next to your workstation.

In some circumstances VNC can offer advantages over Terminal services or remote admin tools because the server desktop and current session are 'cloned' on your desktop - This comes in particularly handy for apps that require the server to remain logged-on to run (some legacy non-service apps etc.) and do not support mutliple instances.

Another is the simple but tried and true "run_virtual path" admin share. If you only need access to the file system you often don't need any remote admin tools at all... just authenticate and open the remote server's file system using the c$ share.

Don

Renaming the Administrator account is certainly possible and it is a recommended best practice to defend against scripted brute-force attacks (automatic attempts to guess the administrator password).

Some people take the additional step of renaming the Guest account "Administrator" but since the Guest account is also a potential vulnerability I don't recommend that. Renaming the Guest account is not a bad idea, just don't name it Administrator.

I don't think it is necessary in most situations to disable the Administrator account, although it is possible to do so.

In any event, if these steps are taken, it is absolutely essential that the system administrator document the result. Be sure that the name of the administrator account (or some account with admin rights) is known by more than one person.

Incidentally, renaming accounts only stops dumb, automated attacks. More sophisticated attackers may have a means of detecting even a renamed Administrator account. For example, the SID for the Administrator account always ends in 500.

Zac
 

All the time; I rarely ever work on the local console.

OK, not a Windows server this time (RH Linux) but another tool in the remote admin arsenal worth considering...

This mornings phone-call at 5:00 was fairly typical - A major power spike at one of our facilities 100km away scrambled one of the local Linux Servers (the error was a "kernel panick attack" - great!). The server was hung so none of the installed remote admin tools were available. Fortunately the box contains a [ HP Remote Insight Card ] - This is an independently powered server management card providing a range of options, including a remote console and the ability to power-down the server and reboot even though the server itself was hung, would not return a ping response, and would deffinately not respond to a remote reboot command.

So instead of a 200km round-trip at 5am and about 3 hours downtime... 10 minutes to logon and reboot the box remotely via the Insight card brought everything back online. Happy staff (and a happy wife!).

Servers with these cards pre-installed or as an addon are a terrific remote admin tool, especially for 'nix boxes traditionally intollerant of power outages or spikes - Now Monday's job is to find out why the UPS and power filtration didn't stop the spike!

Don

Good overview of what's out there. However, larger nonprofits might find some of these tools inadequate for their organizations. Those that need more "centralized" control over all their servers, routers and power devices might want to look at various KVM over IP solutions.

I recently went to Avocent training, and wow...I was very impressed with their (pricy!) solution. With KVM over IP, one or two admins can easily administer and respond to the needs of a gigantic network of routers, switches, servers, and desktops.

One more tip for those who administer multiple W2K/W2K3 servers - if you launch the MS Management console (mmc.exe), you can create a console with the Remote Desktops snap-in, and have multiple servers available in a single application. When I worked in the Fortune 500 arena I had literally hundreds of servers to work on, and used the mmc to have them all handy in a single window.

Also there's a caveat... when working in terminal sessions, be mindful of the Windows Station identifier (aka WinSta). WinSta 0 is the physcial desktop's station identifier, and many older or poorly-written applications will only install (and sometimes only run) properly from WinSta 0, meaing that terminal sessions, which use higher winsta numbers, aren't 100% the same as being connected to the actual desktop. Using the remote desktop connection to the server and adding /console option to the end will put you in WinSta 0.

Interesting thread. Thanks to all for the great info.

As my clients have gradually upgraded their servers to Win2K or Win2003, and their workstations to WinXP, I've become a big fan of the Windows Remote Desktop since it's easy, free, fast and reliable, even over poor connections.

It's perfect for the clients who would never be willing to pay for gotomypc, pcanywhere, VPN's or formal terminal services access.

I just create a pinhole through the firewall. I'm careful about passwords and I try to reduce exposure as much as possible by methods such as blocking access during those hours when I am typically asleep or highly intoxicated.

Rather than directly access the servers, I connect to an admin workstation. That gives me immediate access to my tools and utilities and I can leapfrog via RDP to servers or other workstations.

I have just started experimenting with the exact opposite approach; accessing my home computer from client locations via Remote Desktop. It gives me access to all my invoice and reporting programs plus my drivers and patches archives, all without dragging a notebook computer everywhere I go.

-ENO

especially for 'nix boxes traditionally intollerant of power outages or spikes

Intel boxes, you mean.

Resilience to power fluctations depends more on hardware - power supply, controllers, drives - than the OS. Filesystem settings can help the box fail with some grace, and depending on your choice in filesystem, linux might have been playing fast and loose with metadata, but hardware's more than likely the culprit and the cure.

Hi Obscurant,

Unix/Linux is traditionally intollerant of hard (power outage) shutdowns - Google if you would like to know why - Back in the days when the only flavour of 'nix I looked after was SCO (before Linux was around) the problem was horrendous... even a minor spike usually meant rebuilding a SCO box. It's a lot better nowadays with Linux, but still sometimes a problem bringing the boxes back on line remotely hence the golden rule of any 'Nix admin... "Don't ever turn the computer off by just pressing the power switch!".

Unfortunately this particular facility is only a few K's from two large Power Generation Plants so when it gets a 'belt' it really gets a 'belt' (tends to melt UPS, and power filtration designed for multiple hits usually only lasts the once and needs to be replaced - it's always worse in Winter with heavy demands on power). We've been lucky so far that none of our servers have physically melted (Intel or otherwise), however within the server farm its only the Intel boxes running 'nix that have problems bringing themselves back on line - the other Intel boxes aren't a problem.

We have a support request in to both RH and HP on ways to improve this... If you are interested I'll let you know what they suggest (and if it works) when we get it all sorted out.

Eno I think you have hit on another very important aspect of this thread...

We tend to associate "remote administration" with someone sitting at home accessing a remote network for admin tasks; usually for after-hours support... But increasingly the reverse also applies (people sitting behind a large network requiring access to a remote home or otherwise isolated computer).

We are finding this more and more as Contractors come onto our sites and ask if they can use our network to access their own remote PC's or networks through a VPN tunnel. Traditionally we just handed them a phone line and said 'go for it'... but nowadays dial-up is just not good enough, and we should be able to provide better connectivity options for these people (all our sites have as a minimum a 10 meg Internet link).

We haven't enabled this as yet so I'm interested in ways people are achieving this type of connectivity. My first thoughts are to V-Lan a couple of network ports for Contractors to use, lock the routing tables in our Layer 3 equipment (switches and routers) so they can only route externally, and ensure our proxies do not allow reverse traffic on these ports (i.e. using the VPN to hit the proxy and use the proxy as a route to come back in to our network).

Has anyone played with this type of config?

Rgds, Don

"Attention system administrator your root file system is corrupt would you like me to autofix?"


Intel or Motorola doesn’t matter it's the architecture of the file system.

It happens because *nix caches the disk "directory" in ram and doesn't necessarily write it back to disk except during the shut down process. Any power glip can halt processing or scramble RAM memory and the "directory" and file buffers never get written back to disk.

Dave