Protecting Windows Networks – Local administrative accounts management

There is a common problem in all environments with local administrative accounts, such as local Administrator account, root accounts or any kind of application specific built-in admin accounts set to a common password, shared across all systems.

It is a tough problem to solve at scale, because as soon as you get more than a few systems you default to a single, shared password to those accounts, because otherwise it is quickly become a huge burden to manage those passwords effectively.

Vendors ship their products with passwords shared across all clients and sysadmins use common templates for all their systems. Today it is even more prevalent with people deploying appliances and container images.

One part of this problem is default password that is set by vendors that often is not changed, which leads to people getting pwned, sometimes at massive scale. Attackers regularly brute force default credentials internet wide.

It is a well covered issue, but here is some examples for you:

  • Target hackers used default login and password of BMC product.

  • POS vendor uses the same password since 1990.

Shame on vendors who did not enforce changes of default passwords.

In Windows networks it is common to have all computers deployed from a single or few “golden” images that have a common local admin password. This password is rarely, if ever changed which make it a huge security risk. The term local here is a bit misleading, because if you have a single local admin password shared across your whole network, you essentially have domain admin equivalent account. And all attackers have to do is to pop just a single box to get that.

Attackers known to abuse this to move laterally using pass-the-hash attack.

Sure, there is some commercial enterprise password management solutions that address this problem, but they are not widely deployed in my experience.

So, what options are we have to solve this problem?

Block network access for local accounts

One of the simplest solutions would be to just block network access for local accounts, as I don’t see much use cases where you would need to allow users or admins for that matter, to use local accounts over the network.

In Windows 8.1 and 2012 Microsoft created new local SIDs:

S-1-5-113: NT AUTHORITY\Local account

S-1-5-114: NT AUTHORITY\Local account and member of Administrators group

Which basically means every Local account and any local accounts in local Administrators group.

So we can use those SIDs to deny RDP and other network access for local accounts.

For 2008 and 7 environments it was backported in KB 2871997, so you need to install it first.

Then we need to configure the following GPO settings:

Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment


Here is an RDP attempt under local admin from another box with this settings:


Unfortunately, I didn’t find a clear explanation of what is “from network” exactly mean and wasn’t able to test other channels properly since admin shares, powershell remoting and WMI already filtered with remote UAC for local accounts.

The LAPS Solution

Microsoft also addressed this problem with Local Administrator Password Solution (LAPS). This is a free, centralized local admin accounts password management solution. This solution automatically generate random passwords periodically for local admin accounts and store them securely in Active Directory attributes. You can also delegate rights to group who will need to look up passwords i.e Helpdesk, which then can use any of the following methods to look up password for computers – LAPS GUI, powershell script or directly lookup AD attribute.

Here is GUI client:


For in depth guide on how to set it up, check this link and reference section for additional information.

For a free solution it is pretty good, but there is some additional challenges as always:

  • Correct delegation and auditing of AD attributes is necessary for preventing insider abuse of this feature. Make sure you’re monitoring event id 4662.

  • Protection of privileged accounts like helpdesk users is more important than before since they have access to LAPS passwords.

Network Segmentation

If for some reason other options is not possible, you can use network segmentation to limit potential damage that can be done after attacker obtained local admin password. This is the common theme in a lot of networks, people treating their internal network as trusted and everyone can connect to anyone inside regardless if there is a business need for that or not. However, what you need to do is to stop treating your internal network as trusted and start treating it as hostile Internet. There is no reason for accounting to have access into R&D network, so start segmenting your networks based only on the business need. Network segmentation is a great practice overall and it will prevent attacker to move easily inside your network, but it is not a solution to the problem we discussing, just a limiting factor.


Password management is a complex topic and doing it right is a challenge by itself.  Fortunately we have pretty good solutions in Windows environment and taking advantage of those solutions is critical in mitigating a widely employed pass-the-hash attacks.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: