Blog Post

Windows IT Pro Blog
4 MIN READ

By popular demand: Windows LAPS available now!

JaySimmons's avatar
JaySimmons
Icon for Microsoft rankMicrosoft
Apr 11, 2023
Welcome to the new and improved Windows LAPS! That's Local Administrator Password Solution. We've been listening to your feedback and requests, and the day is finally here for both cloud and on-premi...
Updated Nov 09, 2023
Version 7.0
security
servicing and updates
JaySimmons's avatar
JaySimmons
Icon for Microsoft rankMicrosoft
May 07, 2023

KalimanneJ ,

 

>>What’s the best way to manage LAPS when you have Server 2016 combined with Windows 10 and Server 2019-2022 in the same AD environment?

 

I don't have an answer to this question other than to point to existing tools. Standard GPO policy techniques obviously need to be used to apply the appropriate (legacy LAPS vs Windows LAPS) policies to the various target systems.  Once the policies are correctly applied to a mixed env containing both legacy LAPS and Windows LAPS devices, IT staff will need to be educated on the fact that potentially two different tools may need to be used to retrieve passwords.  (Yes - the Get-LapsADPassword cmdlet can retrieve either password style - but PSH cmdlets are not generally considered suitable for mainstream IT usage?)

 

>>is there any central logging in on premises Active Directory that you can use to audit who is retrieving LAPS passwords and when they were retrieved?

 

Windows LAPS does not have any improvements in this area over legacy LAPS.  I mentioned in a previous comment on this blog that using AD as the store for Windows LAPS passwords has both pros and cons, one of the cons is that the DCs are "dumb" servers which don't have any specific logic or endpoints related to Windows LAPS passwords. Other solutions (eg, LAPS.E) offer a centralized place to store the passwords, which then allows for a very specific audit trail, at the cost of setting up and maintaining extra servers.

 

For Windows LAPS, standard AD auditing can be used to detect when the password is queried from AD.  Note if you are using password encryption, I do not think that DPAPI offers any centralized auditing on key use. This is a natural result of its underlying architecture where the key is retrieved from AD (after an authz check) and decryption occurs on the client device. Obviously you should treat devices used for password-retrieval as Tier 0 although this is no different from legacy LAPS IMO.

 

Windows-client side security logs can be used to detect when the account is used to authenticate to the target device. 

 

I am aware of various centralized event collection tools in use by customers (eg, WEF, SCCM, splunk) but there is no direct integration between such tools and Windows LAPS.

 

thx,

Jay