Revice Password Last Set logic to check local PasswordLastSet and msLAPS-PasswordExpirationTime

[rk-ca-2023]

Opps, Revise, not Revice , dang typo.

[Jay Simmons]

@rk-ca-2023 ,

Is your Windows LAPS policy targeting the built-in admin account, or a different account that you are creating?

Can you provide more details about the nature of your "template" images?   Are they sysprep'd?  Were they previously joined to Active Directory, AND did they have Windows LAPS policies applied?

I am intrigued by your issue, please do lmk.  You're correct that Windows LAPS does not currently check the PasswordLastSet state of the target account - but we do maintain other local state (primarily under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\LAPS\Config) that if missing or inconsistent will also trigger a fresh password rotation regardless of msLAPS-PasswordExpirationTime.  So I am really curious what values are stored under the LAPS\Config key in your template images.

thx,

Jay

[rk-ca-2023]

Thanks for responding Jay.

Is your Windows LAPS policy targeting the built-in admin account, or a different account that you are creating?

Yes, targeting the built-in admin account which has been renamed by one of our security GPOs.

Can you provide more details about the nature of your "template" images?   Are they sysprep'd?  Were they previously joined to Active Directory, AND did they have Windows LAPS policies applied?

We are using Citrix MCS on VSphere (Machine Creation Services (MCS) / Citrix Provisioning (PVS)). Basically, updates are done on the master image, then a snapshot is created  which is used by the provisioning services. A reboot of the server will reset the server to the snapshot and every server is rebooted on a rotating basis. The local admin password will be set back to the default of the snapshot after a reboot.

https://docs.citrix.com/en-us/tech-zone/design/reference-architectures/image-management.html

Yes sysprep’d by Citrix during machine creation.

Master image is joined to AD.

Windows LAPS policies are applied to the master image as well but this image is only started monthly to patch and apply configuration updates.

I am intrigued by your issue, please do lmk.  You're correct that Windows LAPS does not currently check the PasswordLastSet state of the target account - but we do maintain other local state (primarily under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\LAPS\Config) that if missing or inconsistent will also trigger a fresh password rotation regardless of msLAPS-PasswordExpirationTime.  So I am really curious what values are stored under the LAPS\Config key in your template images.

We have a custom Compliance App that checks many different things for us on all servers. One check is the local admin password change date which alerted us to the issue. We solved the issue using this hack’ish technique: https://support.citrix.com/article/CTX331247/laps-randomizing-local-admin-passwords-in-nonpersistent...

Also, the servers are Win 2019 Standard and using the included Win LAPS version of LAPS. I had to add the attribute “msLAPS-PasswordExpirationTime” to the script as it was written for the old LAPS version.

LAPS Config:

Could the fix be to ensure that LAPS is not configured on the master image and that these settings are blank/removed? Some of this is due to us having written polices that relate to our Cyber Security Insurance. All local admin passwords are randomized, which means that we would prefer that the master images are also is using LAPS.

Thank you for your help.

[Jay Simmons]

@rk-ca-2023 ,

Awesome - thank you for the extra details.   I am going to do two separate replies - the first one (this one) will focus on a short-term workaround. The second reply will explore some longer-term improvement ideas.

>>Could the fix be to ensure that LAPS is not configured on the master image and that these settings are blank/removed?

>>All local admin passwords are randomized, which means that we would prefer that the master images are also is using LAPS.

My preferred approach to fix your problem would be to just make sure that the Windows LAPS policy is never configured on your master images. Since this goes against your second requirement above, never mind on this option.

The image of the LAPS\State registry key you pasted is not written by policy (whether GPO or Intune). Those registry values are the locally saved breadcrumbs that Windows LAPS uses to keep itself consistent from run to run.  Note that those registry values are not documented or intended for external use (granted, it's not hard to understand what they do).  What I can suggest here as a short-term solution is the following:  after sysprep'ing a new master image, delete ALL of the registry values under the LAPS\State key (don't delete the key itself).  The next time Windows LAPS runs, the absence of those values will cause us to do an immediate password rotation on the managed account.  Which should put that image into a good state (Windows LAPS-wise, anyway) and fix your problem, if I am understanding everything correctly.   

Is it possible for you to implement this workaround within your deployment framework?

One follow-up question:  when it is necessary to apply updates to the master image, does that involve booting the master image, or are the updates applied to the offline image?   

Jay

[Jay Simmons]

@rk-ca-2023 ,

This is my second reply on the issue you're seeing integrating Windows LAPS with your Citrix MCS\Provisioning solution.

Basically, I think there is definitely room for improvement here in Windows LAPS.

My first idea is that Windows LAPS needs to integrate with sysprep so we can automatically take make our local state consistent during a sysprep generalize image. Simplistically, during sysprep I would just delete all of the LAPS\State registry values.  Based on my analysis so far this would not help your situation - but it would be an improvement for other customers.

Secondly, I've been pondering your PasswordLastSet-related ideas. I am still thinking through the details but I believe there is a definite place for it.  No ETA or anything like that, so do please consider the short-term workaround I described in my previous reply.    

Mostly for fun, here is the super precise engineering diagram I am using to think about your scenario:

Anyway, I have logged bugs on both of these ideas and will work on them.  Thank you again!

Jay

[Jay Simmons]

Hi @rk-ca-2023 ,

Please check out the new Windows LAPS rollback-detection-feature (and other new features!) that dropped in today's 26040 Canary build:

Announcing Windows 11 Insider Preview Build 26040 (Canary Channel)

This rollback-detection feature was designed with your scenario in mind - however it is based on comparing locally-persisted-state (a guid password "version") against similar new state stored in Active Directory.  This new feature requires a new attribute be added to the AD schema - just re-run the new Update-LapsADSchema PowerShell cmdlet.

I obviously realize you won't be deploying a preview feature in your production environment, but I would like to hear your feedback on whether or not this feature will solve the problem that you had raised.

thanks,

Jay