Enabling and using Windows LAPS

Enabling and using Windows LAPS

Windows LAPS just recently released to Public Preview. No no, not the old one (legacy Microsoft LAPS: https://www.microsoft.com/download/details.aspx?id=46899). The NEW LAPS. LAPS is an acronym for Local Administrator Password Solution. On Windows-machines there is by default this almighty admin-account that gives you local administrative access to that computer. This can be used in case of emergency where other means of authentication isn’t available, e.g. lost contact with domain controller. But it can also be used for malicious purposes. There are several techniques where passwords can be used to take control over computers. Because managing passwords for every computer can be very tedious, even in small businesses this is often not prioritized. So what do we do? Yeah, use the same password on all the machines and close our eyes. Even though we know this is not very secure. How can you and I avoid this?

The idea is not new but there hasn’t been a good solution for Azure AD-joined machines to handle this. Until now. Windows LAPS takes care of the orchestration of all your machines’ local admin account, rotates the password, and stores it safely for you. And the best thing: it’s free! Let me show you how to set things up.

But what scenarios are supported?

The key here is where your devices are JOINED. If your devices are joined to Azure AD as cloud only devices and managed via Intune, you deploy LAPS via Intune. This will not work if you are using your home computer or any private device that are only Workplace Joined or registered only. It must be enrolled and joined for this solution to work.

Prerequisites for the OS are Windows 10 or 11(H2), and Windows Server 2019 or 2022. Additionally, they need the April 2023 update for this to work. This update includes the functionality to enable support for Windows LAPS.

If you have a hybrid environment, you are joined to the traditional Active Directory and registered to Azure AD. Azure AD Connect will sync out your device object to Azure AD and AD will make your computer aware of Azure AD and tells it to register there as well. In this scenario you can choose where you want to store the passwords. You COULD use your local AD for this, but the preferred way is clearly Azure AD. Then it will also support cloud only devices and it’s already setup for the day you remove the hybrid connection and goes all cloud.

In cases where your devices have no concept of Azure AD (Like when there is just a local AD or your machines are running an older version of Windows) you obviously can’t store your passwords in Azure AD. You need to rely on your local Active Directory for that.

If you are going the route of using Active Directory, I can only point you to this Microsoft Docs describing that scenario as I’m not going into it here. This involves e.g. updating the Active Directory Schema, so it’s another game: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory.

Turn it on!

How you turn this on depends on your scenario described earlier. In this guide I will only show you how to deploy it in Azure AD. If you need to deploy using GPO, go to Microsoft Docs here to read up on it: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-policy-settings

So… Firstly, log in with an admin account to Microsoft Entra. Se under “Devices”, “All devices” and “Device settings”. Scroll down to Enable Azure AD Local Administrator Password Solution (LAPS) (Preview). Make sure you change from “No” to “Yes”. Click “Save” at the top to save your settings.

Next, we need to create a Configuration profile in Intune. Click “Endpoint security” and “Account Protection”, then “+ Create Policy”. Platform will be “Windows 10 and later”, and Profile is “Local admin password solution (Windows LAPS)”. Click “Create”.

Basics:

Choose a fitting name and click “Next”.

Configuration settings:

Let me explain what the options means.

Backup directory: Here you will choose what directory you want to back the data up to. You can only choose one! Primarily we want Azure AD in most cases, but Active Directory can be used if needed.

Password Age Days: Quite easy. Set how old (in days) you want the password to maximum be. I like even numbers, so let’s set it to 30 days.

Administrator Account Name: enable this if you have created dedicated admin-accounts with your own name and want to target the profile to these accounts instead of the default admin-account. As standard, LAPS will target the admin account with the well known SID. The default admin account on Windows machines always has the same default SID and that’s why you always should disable that user and create a dedicated one. If you are using the default one, just leave this setting off. If you have created a new admin account, type in the name of that account here. This must match on all computers!

Password Complexity: Choose how complex your password should be. I prefer not having special characters but a longer password instead.

Password length: Self-explanatory? Here I like to bump it up to 20 from the default 14 characters.

Post Authentication Actions: Define what to to with the password if it’s been used. The default here is “Reset the password and logoff the managed account”. This will reset the account and log off any interactive sessions after a period of time. The grace period can be set in the next field.

Post Authentication Reset Delay: Here you define the time window before executing the specified Post Authentication Action. This is set in hours, and I like to set this a lot lower than the default 24 hours.

Click “Next”.

Scope tags:

This is the time to add some. If you are not using Scope tags, just click “Next”.

Assignments:

Since this is a Device-policy, you need to scope to devices and not users. If you want you can roll this out to a subset of machines in your tenant, or be brave as I am and let everyone get the policy at once by clicking “+ Add all devices”. Click “Next”.

Review + create:

If you are happy with all the settings, click “Create”.

Congratulations! You have now enabled LAPS in your tenant and enabled all your computers to rotate the local admin password every 30 days. How cool! You should be seeing this rolled out pretty quickly. But what if you need to use that account…?

Find the generated password

To read out a password from LAPS you need to either log in with a Global Admin, Intune Admin or Cloud Device Admin. No regular user can read out these passwords by default. Additionally we can create a custom role for this. The role needs to be this one:

microsoft.directory/deviceLocalCredentials/password/read

Create a custom role and assign that to your help desk agents or super users so they can read out the passwords when needed.

So, when you have logged in with a user that has the correct role there are several ways to find your passwords.

One way:

In Entra, you can go to Devices and All devices. Click “Local administrator password recovery”. Here is every device with LAPS enabled. You can search by device name or ID and click “Show local administrator password”. A blade with Account name, SID, Local admin password and rotation info appears. Click “show” to reveal the password.

Second way

This is via the intune portal. Go to https://intune.microsoft.com, click on “Devices” and on “Windows”. Search for and click on your desired device. In the Menu bar there is a button for “Rotate local admin password”. This is usually hidden under the three dot menu, depending on your screen width.

And there is of course the way via PowerShell. See further down.

If I now use this account and log on to that machine, the policy will enforce a rotation 8 hours after my first login. Even if the password is somehow snatched up and used by someone for malicious use, they will be kicked out after some time and the password will be rolled over.

Who?? When??

There is also this question of who has done what, and when. I hope your logs are working because every action can be logged in your tenant. These logs can be found in the Entra-portal under Monitoring & health and Audit logs. If there’s a lot of logs in your tenant, you can filter for Service: Device Registration Service to see only the related logs.

From there you can click on the entries you would like to investigate and see who has done what, when – and from where. If you want, you can set up alerts on these events and alert the right people when a local admin is used so the event can be monitored. But that’s another blog post for another day 😉

Why not use PowerShell?

And lucky for us geeks that want to automate and do stuff in bulk there is a lot of ways to use LAPS via PowerShell as well. So why not use it?

If you want to get a LAPS password from Azure AD via PowerShell, use this cmdlet:

PowerShell
Get-LapsAADPassword -DeviceId <Array of IDs or Device names>

There can be cases when you want to reset passwords on active accounts immediately. Let’s say you’ve set an alert for reading passwords and no trusted personnel are using it, you can trigger this command on the device in question to reset the local admin password:

PowerShell
Reset-LapsPassword

And for investigating issues regarding LAPS, you can use this one:

PowerShell
Get-LapsDiagnostics -OutpoutFolder C:\Data\LAPS

Read more about the PowerShell-module and see more examples here:

https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-powershell

Summary

I hope you find this blog useful and now want to implement LAPS in your environment. It’s easy to get going and this will increase your security posture a lot by killing one of the most hated (by admins) and loved (by hackers) security concerns out there. The Windows LAPS has a lot of improvements over the legacy solution, and you can benefit from this right away.

Please leave a comment to let me know how this turns out for you 😊

Sources

https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview

https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-faq