Remote Management: Top 5 Security Gotchas

Security Gotcha
Photo by Brad & Ying

Our goal at Admin Arsenal is to help administrators work remotely by getting them to unplug their sneakernets. System security can sometimes make it difficult to achieve this goal. It would be great to live in a world without the need for security, not least because of its delicious gumdrop houses, use of sparkling rainbow wishes for currency, and ruler Princess Yum-yum-tum-tum of the Rose Scented Flatus. Unfortunately, we don’t live in that world (which is a shame because the dollar to rainbow wish exchange rate is at its highest ever.)

Like most things in life there is a trade-off between the security of assets and their availability for use (or administration, as the case may be.) We’ve found that security issues tend to be the biggest roadblocks in achieving remote administration nirvana. So in that vein, I present the 5 biggest security roadblocks that we encounter regularly.


This one should be obvious. If a computer doesn’t allow inbound connections to its remote administration facilities, then it’s not going to work. With the advent of the Firewall in Windows XP more and more people are seeing their remote administration break. It’s been a while since the Windows Firewall entered the scene so this problem, and its cure, are quite well known now. The simplest fix (short of disabling the firewall) is to enable the remote administration firewall exception, the file sharing exception (for remote access to the file system) and the ICMP echo exception (for ping.)

DCOM Security

WMI (Windows Management Instrumentation) is one of the primary methods of remotely administering computers. It uses DCOM (Distributed Component Object Model) as its method of communication. If the rights for DCOM aren’t properly set, then WMI isn’t going to work correctly, if at all. WMI, for all its power, seems to be quite fragile or brittle. One of the reasons behind this is its reliance on DCOM which seems to be the target of well meaning but misguided security experts and tools. We see this problem so often that we created a tool called DCOMAcls which allows for the remote setting of DCOM security settings.

System Time

Windows security has trouble coping with computers with clocks that are out of sync. This is actually for a good reason, since security tokens use timestamps and expirations to prevent their misuse. Depending on the settings of your authentication scheme (such as Active Directory’s implementation of Kerberos) a clock that is out of sync by only a few minutes can cause connectivity problems. Usually, though, it takes clocks off by a few hours (such as reversing AM/PM or being on the wrong day.) Troubleshooting this problem can be difficult because the connectivity issues don’t usually indicate that it’s a time sync problem.


WMI’s authentication validates the host name being used to access the computer (unless a raw IP address is used.) If there are DNS or DHCP problems causing the wrong computer name to be used for connection, WMI will quite often fail. Windows DNS is notorious for stale records and it takes some effort and planning to ensure that a good DHCP setup prevents the same addresses being reused often. Then throw NetBIOS into the mix and once your name resolution is compromised then all bets are off.

The Double-Hop Problem

This problem only affects a certain type of remote administration, so while it’s not generally encountered by most administrators, those who use this type of administration will almost always run into it. The double-hop problem is, to put it simply, the inability for a security token to hop twice between machines. If you connect from computer A to computer B to execute a task (such as start a remote software install) and that task needs files on computer C then the security token can’t hop again from B to C and access to those files will be denied. There are three solutions to this problem, the first is to configure a level of trust called “delegation” between computers, but this requires some high-level settings in Active Directory and is usually discouraged. The second solution is to send a user name and password from computer A to computer B so that a new token can be created to hop between B and C, but this is also problematic because it involves sending a password over the wire (possibly encrypted, but out in the open) and there aren’t any native Windows tools that work that way. The third solution is to figure out a way to not need files on computer C, but this may not always be possible. So, while you may never run into this problem, when you do it can be a bear to deal with.

Hopefully this list will help any of you having security problems in your remote administration daily lives. Personally, I’ve filled out the immigration paperwork for the the land of gumdrop houses…