The concept is pretty simple – LAPS sets a Local Administrator password policy against all the computers (except domain controllers) in a domain environment.  A typical policy:

• Password is reset every X number of days
• Password meets complexity requirements
• Password meets length requirements

In my own environment I set a policy of 90 days and 24 completely randomized characters.

I found lots of resource online for getting started:

• How to install and configure Microsoft LAPS – 4sysops
• How to Configure Microsoft Local Administrator Password Solution (LAPS)

Both sites are great at detailing out the process.

The drawbacks I encountered:

1. If deploying the MSI package via GPO you do have to reboot the system for the install to happen
2. It doesn’t work for Domain-Joined systems in Azure unless you’ve planned for this in advance

When you deploy an Azure Windows VM, the ‘administrator’ account is reserved by Azure, so you’re prompted to create your own.  Out of the box configurations for LAPS utilizes the Administrator account, so unless you plan ahead and have a policy that resets the default Administrator to a different username, and incorporated the same username into your LAPS policy, your Azure Windows VMs will accept the policy but never return a password.

Truthfully I did cheat this last bit by just adding the Administrator username to the Azure VM and giving it a random password.  LAPS then did grab that account and reset the password according to policy.  This isn’t the right way to do it though, so I don’t recommend it.  Best practice would be to set your own Local Administrator username and implement across your domain, and incorporate into your LAPS policy.

Oct 18, 2024 – update

I keep hitting my head against needing to validate LAPS passwords.  Sometimes I don’t want the password, I want to know how many or which systems have a LAPS password:

Get-ADComputer -LDAPFilter “(ms-mcs-AdmPwd=*)” | select-object name

(Get-ADComputer -LDAPFilter “(ms-mcs-AdmPwd=*)”).count

Inversely to find out how many or which systems do not have a LAPS password:

Get-ADComputer -LDAPFilter “(!(ms-mcs-AdmPwd=*))” | select-object name

(Get-ADComputer -LDAPFilter “(!(ms-mcs-AdmPwd=*))”).count

The post Windows Security – LAPS appeared first on Wiredwolf Canada.

Some of these attacks have been pretty basic and if I didn’t have security auditing enabled may not have even noticed them.  But I do, and I get email notification when an account is locked, which prompts me to go see what’s happening.

Before you say, “Hey, RDP open to the public is just ASKING for trouble!” – I already know this.  In fact, I’ve been documenting the experiences.  However, when a lot of this was originally set up the Internet was a safer place and the tools to exploit and attack networks were far less sophisticated.  I now encourage all of my clients to pay a bit more attention to security concerns and start closing some of these transitional gaps.

Anyway, one of the biggest frustrations I’ve experienced is the ridiculous way Microsoft records Security Audit information.  

The computer attempted to validate the credentials for an account.

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: LIBRARY
Source Workstation:
Error Code: 0xC0000064

Note that Source Workstation is blank or NULL.  It isn’t always.  Sometimes it’s some other nonsensical entry (MSTSC, RACCESS, etc.) that cannot be resolved on the domain or network.  The point is, the information provided is basically useless.  I know someone is trying, I just don’t know where it’s coming from.  If I can’t source it, I can’t stop it.

In this particular case it was a workstation with a Public RPD connection available.  The user was actually sitting in front of the workstation for a change, but it was still being used to brute force attack a number of accounts.

While the Security Logs can’t tell me the source, NETLOGON can.  

Here’s how to go about finding the source:

Open a CMD prompt (as Administrator) on the domain controller (PDC Emulator)

nltest /dbflag:0x2080ffff

This turns on debug logging for the Netlogon service on the DC

Now go review the log entries:  Start –> Run –> “%windir%\debug\netlogon.log”

When you’re done, unless you don’t mind the netlogon.log file growing at an alarming rate, turn off the debug logging:

nltest /dbflag:0x0

Now, the netlogon.log will be completely stuffed with helpful information, but it’s information overload.  This is what you’re looking for:

SamLogon: Transitive Network logon of

Paste that into your Find and you’ll start seeing responses like this:

05/29 15:36:42 [LOGON] [10684] <<DOMAIN>>: SamLogon: Transitive Network logon of (null)\MARK from  (via <<WORKSTATION>>) Returns 0xC0000064

More sophisticated attacks don’t have a NULL domain, and we’ve been seeing a lot of very targeted attacks where the hacker network knows the custom RDP port, the domain, and the username.  I haven’t yet determined how they know this, but it is pretty accurate.  As I’ve documented though, brute force attacks against networks with progressive security policies such as account lockout policies and complex password compliance with regularly changed passwords makes this a very inefficient way to break in.  Having said that, it only takes one…  

The post Security Audits – Tracking down the Source Workstation appeared first on Wiredwolf Canada.