Get started Bring yourself up to speed with our introductory content.

Local accounts and passwords

Client computers' local accounts are one of the most overlooked security issues in any enterprise. Locking down these accounts and passwords is the first step in securing clients.

The Definitive Guide to Securing Windows in the Enterprise The following excerpt series from Chapter 2 of the free eBook "The Definitive Guide to Securing Windows in the Enterprise" (Realtimepublishers) is written by Don Jones. To obtain all eBook chapters from this guide, go to

Local accounts and passwords

Local user accounts exist on every Windows computer except domain controllers, and client computers' local accounts are one of the most-overlooked security issues in any enterprise. For example, every computer has a local Administrator account, which has complete and total control over nearly everything on that computer -- including the profile contents for domain users who utilize the computer. Simply gaining access to the local Administrator account can therefore provide access to a great deal of domain information, even though the local Administrator account doesn't have direct access to anything in the domain.

If the local Administrator account is compromised, a keystroke logger could be installed, enabling the hacker to compromise credentials of other users that may have access to sensitive data on the servers. There are software utilities, such as PestPatrol, available that can scan for keystroke logging tools.

Some organizations will take the time to configure local account policies, governing the maximum age, minimum length, and other restrictions for the local accounts. This process is simple, as Windows Group Policy allows you to do so through Active Directory (AD). Figure 2.1 shows an open Group Policy Object (GPO) that is linked to an organizational unit (OU); every computer within this OU will be affected by the password policy configured in the GPO.

Figure 2.1: Configuring password policy in a GPO.

However, local accounts aren't used all that often in many environments. If an account -- such as Administrator -- isn't used, then its password will never be changed and it remains a security liability. Perhaps the most common way of dealing with this local account security issue is to simply ignore it, creating one of the biggest issues in client computer security. Many organizations take half the time on local account management than they spend managing their domain accounts, yet those local accounts can have access to just as much sensitive data.

Local computer accounts don't have direct rights to resources stored in a domain. But when domain information is copied to a local computer, local accounts -- especially the Administrator account -- can gain access to it, essentially bypassing domain security (from a business viewpoint, at least) now that the file is under the computer's local security.

One way to quickly deal with the issue is to write a short script. The following VBScript, for example, can be used to change the local Administrator password on a remote computer:

sComputer = "client1"
Set oUser = GetObject("WinNT://" & sComputer & "/Administrator, user")
oUser.SetPassword "[email protected]!"

Naturally, this isn't a terribly useful tool because it only changes one computer at a time. A more powerful version of this script would read all of the computers from a file, listing one computer per line, and change their local Administrator accounts:

Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oTS = oFSO.OpenTextFile("C:Computers.txt")
Do Until oTS.AtEndOfStream
   sComputer = oTS.ReadLine
   Set oUser = GetObject("WinNT://" & sComputer & _
      "/Administrator, user")
   oUser.SetPassword "[email protected]!"

However, this solution is still not ideal. It requires that you maintain a huge list of client names -- a task that makes it easy to miss one. In addition, any computer that isn't available (turned on) when you run the script won't be updated -- in fact, this script will crash on the first unavailable computer. It's possible to change the script so that it will log unreachable computers, and you can even have it read computer names from AD. However, even this solution doesn't address all the shortcomings. AD too often contains old computer accounts, and might not contain the name of every computer in your environment (standalone lab computers, for example). Smart organizations will rename the local Administrator account, but might not have done so consistently on every computer. In this situation, you need to change the password of an account whose name you don't even know -- a difficult task!

Commercial tools can do a better job in many cases. For example, Absolute Dynamics' cPWD can change passwords on multiple computers, and even target computers on which the Administrator account has been renamed. As Figure 2.2 shows, multiple computers have been targeted to have their local Administrator password changed.

Figure 2.2: cPWD makes changing local accounts easier.

Simply entering *A* for the account name will target the local Administrator account by its security identifier (SID), regardless of the account's actual name. The tool is designed to target a list of computers, but has the capability to dynamically generate that list, as Figure 2.3 shows.

Figure 2.3: Dynamically targeting computers to change local account passwords.

Like so many security issues that affect client computers, local account passwords are a problem on member and standalone servers, too, and the same solutions can be used to help solve the problem.

Click for the next excerpt in this series: Service management

Click for the book excerpt series or visit for the entire eBook, "The Definitive Guide to Securing Windows in the Enterprise."

Dig Deeper on Windows systems and network management