Some days ago, I wrote an article about the alleged superpowers of the built-in administrator account. As it turned out, the local administrator has more or less the same privileges as the other administrator accounts, but this doesn’t mean that it doesn’t require extra care. In this article, I will share some tips on how to handle the built-in administrator account in a corporate environment. These are partially based on an article by security expert Jesper Johansson, although our opinions on some points differ.

Disable the built-in Administrator account

On Vista machines the built-in administrator account is disabled by default. This is a good a thing. Of course, it is the primary target of all hackers (I don’t distinguish between hackers and crackers; it is all the same to me). I also recommend disabling the built-in Administrator account on all XP machines.

Set a password for the built-in Administrator account

In Vista, the built-in admin account has a blank password by default. I feel this is dangerous, even if the account is disabled. Johansson argues that this is not a problem, because an account with a blank password can only be used locally. However, if an attacker manages to enable the admin account (for example, if he has physical access to the machine), he can just set a password which will enable him to manage the machine remotely. Setting a strong password for the built-in admin account provides an extra level of security. You can also use tools, such as AutoAdministrator, to set the administrator password on multiple machines.

Rename the built-in Administrator account

Johansson advises against this common practice. His argument is that “no attacker worth his salt will be fooled by those tactics.” Well, that may be true, but your job as admin is not just to lock out the smart hackers. The majority of all attacks are performed by wannabe hackers. A renamed administrator account is an extra hurdle and doesn’t cost you much. However, I wouldn’t use this account, even it is renamed, as it has a well-known RID. It is safer to disable it.

Create a new local administrator account

Johansson recommends that every admin should have their own account. It makes sense for every admin to have their own domain administrator account, but, in my experience, this just isn’t practical for local accounts. It is quite time-consuming and dangerous to work with multiple local admin accounts. Having no local admin account isn’t practical either. If a machine is not able to log on to a domain, for example, you need a local admin account to find the problem. To re-install the OS every time you can’t fix a machine without an admin account (as Johansson recommends) is certainly not feasible.

Never share the local admin password with end users or external consultants

If an end user needs temporary admin privileges on a machine, you can just add their domain account to the local administrator group. Don’t forget to remove it as soon as the job is done. For external consultants, you should always create a new account.

Change the password of all local administrator accounts regularly

This is easier said than done. From my experience, it is essential that you have a fixed schedule for this. It is not enough to just decide that you will change local administrator accounts “regularly” because there will always be other things that you have to do first. How often you do this depends on how much you value security, but once a month would already be considered. I recommend choosing a fixed day. Basically, there are two methods for changing the password on multiple machines: you can run a startup script or you can change the password remotely, using a tool or script. The advantage of the startup script is that it runs automatically. The disadvantage is that machines that are offline for a long time will be excluded. Changing the password remotely is even more time-consuming because you have to make sure that all your computers are online when you run your script or your password management tool. Using a Wake-on-LAN tool can be helpful here, but in large networks this is often not practical. Of course, if you are in this situation, you will probably have a professional systems management solution that allows you to run scripts on your clients. I don’t even have to mention how essential it is to use a sufficiently complex password for the administrator account.

Try to a use unique passwords for the local administrator account

Using the same password for the local administrator on all computers is a common practice. I fully agree with Johansson that this is quite dangerous. If an attacker gets physical access to even one of your computers he can use the stored password hash to attack other systems in your network. It goes without saying that you should never ever use a domain administrator password for local accounts. Using a unique admin password on all machines is easier than you might think. Johansson offers a free tool, passgen, which allows you to generate a unique password for every desktop in your network. I will review passgen in my next posts.