Last Updated on July 26, 2024 by rudyooms
This blog will show you how the new Automatic Account Management feature in Windows LAPS, in combination with another new “hidden” feature, will deal with already existing administrator accounts.
1. Introduction
In one of my latest blog posts, I showed you how the new LAPS automatic account management feature will ensure that you won’t need to manually create the managed LAPS account any longer. This Automatic Account Management feature is going to do this for you!
LAPS | Automatic Account Management | WlapsPending (call4cloud.nl)
As shown above, with just some simple settings we could define the managed account name (or name prefix) we want to create with the automatic account management feature.
You can even decide to keep the managed account turned off and just enable it on the fly without changing anything else. Isn’t that awesome? But… what if we are turning on this feature, specifying an account name without having looked at other policies first?
2. Duplicate Accounts
For fun, let’s say we are specifying, “admin” as the automatic account that needs to be created by Windows LAPS.
I guess it’s best practice to first take a good look at what configuration policies your organization already has deployed before deploying this policy above.
For now, let’s skip best practices because a long time ago we deployed a CSP to configure the managed account on our own.
This CSP above is creating a new local user and with a second CSP, we are adding it to the local administrator group. All good right?
With that CSP, we now have a local admin on the device with the account name admin. But what if we totally forgot about this CSP and just configured the new LAPS automatic account feature and defined the same account name?
If we configure the same account name in the new LAPS feature, I guess we will have some collisions.
3. Defunct it!
If mister Jay Simmons wasn’t aware of this, we could have ended up with some serious issues. We could have ended up with some nice collisions with the previously created account. Luckily, he was aware! By the looks of it, he added the “defunctAccount” function in the LAPS.DLL
This defunct function is added to the Automatic Account Management flow itself and will guarantee that the LAPS-managed account we specified is always going to be available for its intended purpose. Without this function, we could have ended up in a world of pain when we needed to log in with the WLAPs account
If we take a look at the DefunctAccount function as shown below, we will notice some simple steps that it will take to make sure the account we specified in the Automatic Account management policy is the one that survives the battle.
The process kicks off the same way we noticed in the blog I wrote about the automatic account creation process. It creates a WlapsPending user and tries to add it to the local administrator’s group.
From there on, it will determine if another account has the same name in play. If that’s the case it will first defunct the existing account name. The old admin account will be renamed to wlapsdefuncted(randomized)
Once the account is renamed, LAPS will also make sure that the defuncted account is disabled
From there on the regular Automatic Account Creation flow kicks in again and would rename the WLapsPending account to the account name we configured: admin.
With it, we will end up with a “new” admin account that is managed by WLAPS and the old admin account that is being renamed to defuncted!
As shown above, the new admin one is the ruler of the world and the defuncted one lost its job!!
4. The Flow
I guess I don’t need to introduce the world’s most famous flow any longer… so here it is!
Conclusion
With all the new features popping up in the canary build, the automatic account management feature is one of the most asked-for. Luckily, Jay also thought about some collisions that could occur when we already had an account with the same name in play.