A look inside the Microsoft Local Administrator Password Solution

Windows administrators have a problem — passwords. Specifically, administrator passwords that lurk out there, identical across machines, just ready to be compromised. But there is finally a solution at the right price that mitigates this problem almost completely. Interested? Let’s dive in.

The scenario

The issue at hand is simple: Every Windows NT-based box, as far back as Windows 2000 and up to Windows 10, including all of the server releases, has a local administrator account. This account, sometimes called the “500” account after the group ID number it has within the bowels of the Windows operating system, has full control over the machine on which it is located. It does not by default have any domain privileges. (Domain administrator accounts, of course, also have by default full control over local machines that are members of the domain — but this can generally be scoped to a more limited set of permissions if necessary.)

Once you join a machine to a domain, the local administrator account does not go away. It stays there, enabled in most cases unless you explicitly disable it or rename it or engage in other some such method of obfuscation.

[ ALSO ON CSO: Passwords continue to be a security problem ]

Since it is a local account, however, you do not get the benefit of being able to synchronize passwords and centralize them among domain controllers. Each local administrator account password just sort of sits there. This creates an uncomfortable situation where out of a lack of other resources, most automated installations and deployments (hello Windows Deployment Services) simply put in a secure but identical password for each and every single system they touch.

It is not ideal, but you might be thinking at least the password is secure. Or maybe you actually try to keep track of multiple different local administrator passwords in a spreadsheet.

Managing these local administrator accounts has been a problem for as far back as I can remember, even back when I was part of the administrator team at a major research university in North Carolina. It has been over a decade, so I do not remember exactly how we managed the different passwords, but as I recall it was done with a massive spreadsheet and a regular password change interval for all of the local administrator accounts across the hundreds of machines in the department.

The problem

A new element, though, has emerged in the past few years. What is different these days is automated pass-the-hash attacks. What once was a sort of esoteric attack that was not a huge remote threat has become basically a standard operating procedure for crackers once they get access to a compromised Windows box. And those cracked Windows machines are widely available, even inside large organizations with generally decent security and IT practices.

Essentially, within Windows, passwords are converted by Windows into a “hash” — a fixed-sized string of cryptographically transformed data — every time they are created. This way, your passwords aren’t sitting in plain text anywhere on your machine, nor are they transmitted in clear text when the authentication happens over the wire.

When authentication does need to happen against one resource or another, Windows hashes the password you provide and then submits that hash to the host. The host then compares it with the hash it has on record; if it’s the same, you’re granted access; if not, of course, you’re turned away.

But what if you were able to access the hash database for privileged accounts — like an administrator — and pass that hash directly to a resource? Remember, Windows never transmits the passwords themselves. The only computation that is done is matching the transmitted hash to a hash that’s stored in a database of valid authentication data. If you connect and pass an administrative username and an administrator’s hash, that’s all you need to gain privileged access to a system. You don’t need to know the password; you just need the hash.

This whole scenario transforms from theoretical to probable and practical with the advent of tools that are freely available and downloadable from the Internet. For example, here is a quick narrative of how this would work: Log on to your member server with the local administrator account. Then log off, and then log on to your member server with the domain administrator account. Next, log off there, and then log back into the member server with the local administrator account.

Google around and find the lslsass64.exe utility and run it with the dump option to dump the hashes currently stored in memory. Look for things like DOMAINadministrator or DOMAINadmin. Google around again and find the runhash64.exe utility, and then run that to pass the hash.

The resulting new command prompt that opens has the hash of your domain administrator account injected, so you can run privileged commands against your domain controller from this command prompt. Windows will faithfully execute them as if you were logged in directly with the admin account.

Voila, you have passed the hash. You are now a cracker. Hopefully you are white hat.

Now picture this attack scenario where a cracker compromises a domain-joined Windows machine — and all of the domain-joined Windows machines have identical local administrator accounts. The cracker uses the tools above, or some others that are even easier and more oriented toward launching remote attacks on multiple compromised machines, and thus already knows the right hash.

In doing so, he or she basically owns all of the computers in the enterprise. Game over, do not pass Go, do not collect $200 — in fact, you might be collecting unemployment.

The solution

We now have an elegant solution available: the Local Administrator Password Solution, which may take the award for “Most Obvious Product Name Microsoft Has Ever Allowed Out Of Redmond.” Essentially, the LAPS uses Group Policy client-side extensions to generate a random password on each individual domain member, and then it sets that random password for the local administrator account.

It then puts that randomized password into a confidential, secure (although not encrypted) attribute inside the computer’s Active Directory computer account. The proper permissions are granted so the computer itself can change its own local administrator password data that is stored inside the Active Directory computer object, and domain administrators or delegated administrators can grant read permissions on this special attribute to workstation administrators, the help desk or anyone else that legitimately needs to be able to access the local administrator account on domain-joined machines.

To get started with it, download the LAPS MSI file; it is available in x86 and x64 editions. Then run the MSI file to install. On the first machine you run this, you should install all components, so that you get the management user interface as well as the GPO client-side extension. On all other computers, you just need the GPO client-side extension.

[New to PowerShell? Check out our downloadable beginner’s guide here.]

You can also perform a silent install, perfect for scripting, using the following command:

Msiexec /i laps.x64.msi /quiet

Next, you have to update your Active Directory schema. While this is never a step to be taken lightly, these modifications are very minimal: Two attributes will be added to the current structure within the computer class of AD:

• ms-Mcs-AdmPwd, where the actual password is stored
• ms-Mcs-AdmPwdExpirationTime, where the time to reset the password to something different is stored

You can perform the schema update from PowerShell; open PowerShell as an administrator and then use the following cmdlets:

Import-module AdmPwd.PS

Update-AdmPwdADSchema

Next, you will need to adjust permissions for users and groups that should not have access to the password attribute. You specifically need to remove “All extended rights.” Typically users don’t have this right granted but administrators do, and if you want the limit the scope of who can actually view the password, you’ll need to remove that right.

You can find a list of users who have this right in your PowerShell window:

Find-AdmPwdExtendedrights –identity [name of organizational unit]| Format-Table

If you need to adjust, then use the following steps:

1. Open ADSIEdit from the Windows desktop
2. Right-click on the relevant organizational unit and select Properties
3. Click the Security tab, then click Advanced, and then select the users or groups that should not be able to read the password
4. Click Edit, and then uncheck All Extended Rights

Now, you need to set up permissions so that the computers themselves can update that password attribute in Active Directory for their computer objects. You do this through PowerShell as well:

Set-AdmPwdComputerSelfPermission -OrgUnit [insert organization unit name here]

Next, use PowerShell to set up which users ought to be able to view the password attribute — this is for your delegated administrators, help desk employees, and the like who need to be able to carry out their duties. Separate the users and groups with a single comma.

Set-AdmPwdReadPasswordPermission -OrgUnit [insert organization unit name here] -AllowedPrincipals [list relevant users and groups here]

Finally, give permission to those same users to force a password change on the local administrator account.

Set-AdmPwdResetPasswordPermission -OrgUnit OrgUnit [insert organization unit name here] -AllowedPrincipals [list relevant users and groups here]

You’re done with the back-end setup now. Next, you need to configure Group Policy. Set up a new Group Policy object within the Group Policy Management Console, and then edit it. Navigate to Computer ConfigurationAdministrative TemplatesLAPS. Then:

• Set the “Enable local admin password management” to Enabled.
• Configure the “Password settings” setting however you wish; this is where you can choose the required complexity of the password.
• If you have renamed a custom local administrator accounts, then enter the new name in the “Name of administrator account to manage” setting. Only use this if you have a custom local administrator account; if you have simply renamed the original inbox account, then leave this alone, as Windows will be able to detect it even through the rename.
• Depending on your security preferences, you can enable or disable (or leave unconfigured) the “Do not allow password expiration longer than required by policy” setting.

The next time Group Policy refreshes, then the passwords will be managed. How do you view them? Via the LAPS user interface, a small utility that installs itself on the management computer. You can also view the password by looking at the properties of any computer object in Active Directory.

Evaluating LAPS

I see three main reasons why you should immediately begin deploying this. The overall benefits include:

• It is free. You buy the Windows licenses, of course, but there is no additional charge for using the Local Administrator Password Solution. You can pretty well have it deployed in a day, too, so it costs very little in staff hours to get this up and running in your shop.
• It does not require additional infrastructure servers. This solution plugs right into Active Directory and Group Policy, so it uses the same domain controllers and machines you already have and presents a negligible additional load on them. And since it is using standard in-the-box features, other management tools can play right into it without requiring reprogramming. It is truly a “drop-in” style answer to this problem.
• It does not require new management software. Your existing identity lifecycle management software will work just fine. Software deployment scripts work just fine. Your processes and scripts and utilities for performing tasks on local machines that require administrative privileges will work just fine, too, because there is a password — nothing has actually changed from the authentication and authorization perspective — and once you have it, you are golden.

The last word

In some sense it is strange that we have finally found a nice, elegant way to solve a real problem that existed in a lot of deployments simply because of ignorance or inattention, or was solved in a horribly tedious brute-force way with Excel spreadsheets and lots of paid intern hours. But let us look on the bright side: The local administrator password solution is here. Overall, it is very inexpensive insurance to almost completely prevent an extraordinarily devastating attack that could take your organization down for weeks, months — even permanently. Because it is free, I cannot commend it to you enough. Take a look and make a plan to start using it today.

You can download the Local Administrator Password Solution here.