Practical Protection: Limiting the Damage from Local Admin Accounts

In a previous column, I wrote about the dangers of reusable user account passwords.  Those are bad, but do you know what’s worse? Reusable account passwords on privileged accounts. Thankfully Microsoft has some solutions to help, and if you’re not using them, now’s a good time to start. In this episode, I’ll talk about local admin accounts on Windows machines, and in the future, we’ll talk about other types of privileged accounts and how you can better protect them.

The History of Local Admin Accounts

Before Windows NT, Microsoft didn’t really have a concept of separating administrative privileges from ordinary users. You can thank Dave Cutler’s experience with the VMS operating system for the privilege model introduced with NT, which we still have and use today. This model provided a way to define both privileges (defined as “the right to perform specific operations”) and permissions (defined as “the scope of what operations a given account can perform on a specific object”) and enforce them throughout the OS. One key part of this was the introduction of a privileged account named Administrator. This account had complete control over every part of a Windows NT machine, which meant that you could set up an NT server or workstation with unprivileged user accounts. This was a big security improvement because it allowed for an enforced division between privileged and unprivileged users. When coupled with the concept of domain- and forest-level administrator accounts, admins had a nice granular model that allowed for multiple scopes of control.

However, local admin accounts had several significant weaknesses, the biggest of which is still with us today. Every computer had to have its own password, and there was no way to centrally manage password assignments, updates, strength, or expiration. This led to a whole laundry list of bad behavior: accounts with blank passwords, reused passwords across multiple machines, passwords written on sticky notes, and so on.

Over time, Microsoft started to chip away at some of these problems, but the fundamental problem remained: every Windows server or workstation had a local admin account, which needed a password. Whether or not a device is joined to some kind of central management service, there is still a need for a local-only account for cases when you need to manage the device and the central service isn’t available or can’t solve the problem.

Enter LAPS

One of the strengths Microsoft enjoys is that they have lots of different products and services that they can combine to make new things—sort of like having a giant container of fancy Legos. In this case, they built the Local Administrator Password Solution (LAPS). The word “solution” in the title implies that LAPS solves all the problems with local admin passwords, which is pretty close to true; LAPS provides two-way synchronization between Active Directory and that pesky local admin account password.

LAPS actually has two flavors: “legacy LAPS,” first released in 2016, only works with on-premises Active Directory. You have to install and deploy it for it to work. “Windows LAPS,” released in April 2023, is built into Windows. More specifically, the April 11, 2023, Windows update adds Windows LAPS to Windows 11 (22H2 and 21H2), Windows 10, Windows Server 2022, and Windows Server 2019. There’s nothing additional to install. Although you can run both legacy and Windows LAPS side-by-side, but (as you might expect), Microsoft recommends that you plan to move from legacy LAPS to the native implementation. For that reason, I’ll focus on Windows LAPS in the rest of this column.

What LAPS does

Windows LAPS has three main capabilities:

1. For devices that are joined to Azure AD, it backs up their local admin passwords to Azure AD. LAPS support for Azure AD is officially in public preview.
2. For devices that are joined to on-premises AD, it backs up their local admin passwords to on-premises AD.
3. For domain controllers, it backs up directory services restore mode (DSRM) passwords to on-premises AD.

You may notice one key omission: devices that are not joined to Azure AD or to on-prem AD. If you have computers for things like meeting rooms, kiosk-mode use in break rooms, etc. then you will need to join them to a domain in order to manage their passwords with LAPS.

Each of these capabilities is separate;  that is, you can’t back up local passwords from a machine joined to on-premises AD to Azure AD, and vice versa. (For hybrid-domain-joined machines, you must choose either to store backed-up passwords in Azure AD or on-prem AD; you cannot do both).

These capabilities can be controlled using a CSP for Microsoft’s endpoint management solutions, through PowerShell, or with Group Policy. For example, you can set password length, strength, and age requirements to apply them automatically to the passwords LAPS generates.  All LAPS operations are audited, both in the Azure AD audit logs and also in the local-machine event logs, where they are stored in a separate channel.

Besides just backing up passwords, Windows LAPS lets you change (“rotate”) passwords on demand. You can do this with PowerShell, which is an incredibly useful capability to have when you suspect a breach. If you’re storing passwords in Azure AD, you can also use role-based access control (RBAC) to limit who can manage LAPS, and, perhaps best of all, you can then define conditional access policies that apply specifically to people who hold LAPS-capable roles.  

Getting started with LAPS

The simplest path to getting started with LAPS is enabling it for devices that you’ve joined to Azure AD. Microsoft’s documentation describes the process in detail, but the basics are simple:

1. Sign into the Azure AD portal and go to Azure AD > Devices > Device Settings.
2. Find the “Enable Local Administrator Password Solution (LAPS)” setting and enable it.
3. Create a policy with the LAPS settings you want to use, using either GPO or Intune.

LAPS and the future

Because of the way the Windows security model works, it’s not currently possible to eliminate the use of passwords for local administrator accounts. Given that fact, the next best solution is to remediate the biggest problems with passwords for these local accounts, including weakness, reuse, and tenure. LAPS helps with all of those, and you should plan on using it.