I saw yesterday that Microsoft announced the public preview of LAPS for AAD joined devices to be managed via Intune.
LAPS for on premises AD joined devices has been around a while, for devices joined direcly to AAD though it's not been a "thing" until now. With the move to a more cloud first approach for a lot of things, it made sense to have this available for devices that don't have an on premises footprint.
I think this might have been around for a couple of weeks now via Graph/CSP's/PowerShell and the like but yesterday's announcement made it easier to manage this via Intune with Endpoint Security profiles.
I thought I'd take a look at how this could be leveraged for MTR's as it seemed like a good solution for managing a local admin account for the device and keeping it secure. Each MTR comes with a default local admin account created (username of 'Admin') which is very basic in its name and password and Microsoft recommends this is disabled or at the very minimum the password updated from the default. The default password for the built in account is 'sfb', yes very simple, Googleable and not secure at all. Even if you choose to change it from this to something more secure you're still then left with a password that's either not changing or involves a convoluted process to update. If you did this across all your MTR's, you'd either have the same password for all your devices, not great, or a different password for each one which is a nightmare to manage.
So AAD LAPS seems like the perfect way to manage a local admin account for these devices so that should an engineer need to access the admin account on the device for maintenance or troubleshooting they can do so via the managed account by retreiving the rotated password (via an approved process I would suggest) and using that. From a security perspective we then don't need to worry that the engineer has an admin password as once they've used the password to authenticate it'll get rotated at the defined time in the LAPS policy to a new one. This also helps to ensure you have different passwords for all devices and since the passwords are stored in AAD we don't have to worry about how to manage the details of them all.
Pre Reqs
Let's take a look at how we can set this up and see how it works. There are a few pre reqs we need to check are either enabled in Azure or have been installed on the device to use this.
Firstly, we need to enable this feature from the AAD/Entra portal. For once Microsoft seem to have not enabled something by default!?. So to turn this on, head to the Entra portal and then AAD -> Devices -> All Devics -> Device Settings and from the bottom of that menu you'll see an option for "Enable Azure AD Local Administrator Password Solution (LAPS)". Turn this on.
Once this has been enabled there may be a delay in some of the options we need to configure in the next steps appearing (took a few hours for me).
Next up is making sure the April 2023 security updates have been installed on the devices we want to apply this to. Depending on the OS version your targetting this at the KB number will change, for this example we using an MTR running Windows 10 so the KB is KB5025221. We can see it has installed on the machine so all good from that perspective.
The last pre req is making sure we have an existing local account that we're going to manage. As stated in the Microsoft documentation, LAPS doesn't create a local admin account, it just manages the password for it. So the next steps are assuming you already have a local admin account on the device to manage.
If you don't, you can use the Accounts CSP (or whatever other method that works) to create a local account and add it to the local admin group on the device. The Accounts CSP can be configured as a custom configuration profile from Intune to create the account and add it to the local admin group. You could target a number of devices this way to get the account onto your devices. Here's a link to the Accounts CSP info if needed: https://learn.microsoft.com/en-us/windows/client-management/mdm/accounts-csp
We'll assume at this stage you've got an account configured to manage via LAPS.
Intune Endpoint Security Profile
To setup the LAPS profile in Intune, head to the Endpoint Security blade and then Account Protection. Create a profile, select Windows 10 and later and then Local admin password solution (Windows LAPS) as the profile
Give it a name and description and hit Next. The next set of options are down to you as to how you want to configure this but some of them need to be set to specific things.
Backup Directory - Since this is about AAD joined devices, we need to set this to "Backup the password to Azure AD only"
Password Age Days - You can leave this toggle off if you want and the password age will default to 30 days before it's rotated. Let's change this to 7 for this demo
Administrator Account Name - If you leave this unconfigured LAPS will apply the policy to the default built in local admin account. You could use this if you haven't disabled or changed the name of the default account on the MTR from "Admin". Personally I'd have disabled that default account and replaced it with something different just to make it harder for any nefarious types to try and guess the credentials. If they know it's Admin from a simple Google search they have one part of the credentials already.
Let's assume we have created a separate local admin account we want to manage, so we need to toggle this setting on and specify the name of that admin account. In this example we've already created our local admin account and it's affectionately called "LAPSAdmin"
Password Complexity - This is where we define how complex we want the password to be and have options ranging from just large letters, large letters and small letters, both of those plus number and finally all of those three plus special characters. Pick based on your requirements, in this example we'll go with the most complex because why not. It's worth noting the order of these for later as you can reference it in some of the Event Viewer logs we'll see to validate the settings
Password Length - Specify how many characters you want your password to be. Maximum is 64.....I wouldn't like to be the support person who has to read that out to someone!
We'll go with 14 here, seems a decent enough length and based on this table I found would take 200 million years on average to crack.
Post Authentication Actions - Here you specify what action you want to take once the post authentication period has expired (default is 24 hours post authentiction). We'll set this to just reset the password for now. For MTR's, based on the way they work I'd say the third option of reset the password and reboot the machine is best. The second option of just logging off the local admin account would result in the device returning to the Windows logon screen when we need it to sign back in to the local Skype account. Having the device reboot would achieve this.
Post Authentication Reset Delay - As above, if you leave this unconfigured the action above will be taken 24 hours after the local admin password has been used to locally authenticate. If you have agreed periods of time engineers are allowed admin access to a device you could align it to this value.
You'll end up with something similar to this
Once you're happy, click Next, define any scope tags, add your assignment group of devices and create the profile
Validate LAPS on the device
Now we either just wait for the device to check in with Intune and it should then process the new LAPS policy or we can manually sync it. Either way, once it's synced we can check from Intune that the profile has succesfully been applied
Let's also take a look at the device itself though to see what's happening. If we look in Event Viewer we have a specific folder within the Apps and Service Logs within Windows for LAPS
Within there we can see the logs of when it has processed the LAPS policy. We can see that until today, following the April security update LAPS was checking once an hour to see if the LAPS policy is enabled. Each time, it checked, saw that it wasn't and then checked again in an hour.
Then, once we'd applied our policy from Intune we can see the next time this processed it confirmed it was now enabled and showed the configured settings
This next screenshot shows the current configuration and links back to our Intune profile. We can validate here that the settings applied match
Most of these are easy to link and specify the same values we set in Intune. There are a two that aren't quite the same. Remember when I said it was useful to look at the order of the options for password complexity? We can use this order to validate that where Event Viewer is showing the Password complexity value is 4, this means the 4th option available from our list we configured. So we know it's configured for the large letters, small letters, numbers and special characters
The Post authentication actions is the same, 0x1 showing we specified the first option in the list.
The next set of events confirm that LAPS is backing up the password to AAD
That it needs to update the password due to one of the specified reasons (reason for this example is policy authority has changed)
and that it has succesfully backed up the password to AAD
Just for the avoidance of doubt it also confirms which account was updated
View Password
Once LAPS has processed the password we can check in Intune (or the Entra portal) that it's stored there and view it if we need to. The ability to view the password in Intune is based on role permissions so would only be accessible to admins with the right permissions.
If admins just need to view the LAPS rotation dates/times then they just need to be a member of one these AAD roles:
If they need to rotate or view the password though, this currently requires an admin to have one of two AAD roles....
....and they can then view the password from within Intune. Navigate to the device you want to view and select the Local admin password blade. This view will initially show you the date and time the password was last rotated and the date and time it will be next rotated (this should align to your profile settings).
To view the password, click on the link, a new window will open up and you can click on 'Show' or the clipboard icon if you want to copy it. The screenshot below shows the password (I clicked Show) to confirm that it's the right length (14 characters) and the right complexity (large letters, small letters, numbers and special characters).
We can then use this to logon to the device with the local admin credentials.
Once we do that, we can see in Event Viewer that LAPS recognises the login and will process the action we specified in the policy after the grace period (24 hours in our case)
Manually Rotate the Password
We have our grace period set to 24 hours, so LAPS will automatically rotate the password at that point without any intervention. What if we need to rotate it before then for some reason or because of an incident which requires it to be reset?
We can do that via Intune as well. From the device overview page, click the elipses and select 'Rotate local admin password'. You'll be asked to confirm, click Yes. You'll see a notification showing the request is pending
The next time the device syncs (I manually synced it to speed up the process), we can see it processes the request
and this event shows that LAPS is updating the password due to our request
and we get confirmation it succesfully updated the password in AAD
Back in Intune, we can also validate this by seeing the password rotation date/time has been updated and the password is now changed
Summary
That should be all you need to setup LAPS for AAD joined devices, and in this use case MTR's. Looks useful and a better way to manage local admin access for these types of devices which aren't tied to a user and might need field engineers to access the admin settings for maitenance and troubleshooting.
There are some additional audit logs created that can be viewed to verify if a LAPS password has been either manually rotated or rotated as per the defined grace period. These can be used to audit any changes which to passwords. I haven't looked at these just yet, they're in the AAD audit logs.
Comments