This blog will show you how the new Automatic Account Management feature in Windows LAPS, in combination with another new “hidden defunct” feature, will deal with already existing administrator accounts.
1. Introduction
In one of my latest blog posts, I showed you how the new Windows LAPS Automatic Account Management feature will ensure that you won’t need to manually create the managed LAPS account anymore. This feature will 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 examine 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 creates a new local user, and with a second CSP, we add 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? We will have some collisions if we configure the same account name in the new LAPS feature.
3. Defunct it!
If Mister Jay Simmons hadn’t been 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 will always 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 look at the DefunctAccount function, as shown below, we will notice some simple steps it takes to ensure that the account we specified in the Automatic Account Management policy 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 ensure the “defuncted” account is disabled.
From there on, the regular Automatic Account Creation flow kicks in again and will 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 Part 1
I guess I don’t need to introduce the world’s most famous flow any longer… so here it is!
5. The Flow Part 2
If you don’t like the paint flow with all the images in it… maybe this one would suit you better to understand whats happening under the hood.
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.