FAQs for Microsoft Local Administrator Password Solution (LAPS) – Part 2

• Author
• Recent Posts

Kyle Beckman

Kyle Beckman works as a systems administrator in Atlanta, GA supporting Office 365 in higher education. He has 17+ years of systems administration experience.

Latest posts by Kyle Beckman (see all)

• Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
• Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
• Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016

Is there a log on the client I can use to audit password changes or troubleshoot LAPS?

By default, no. In its default configuration, LAPS only logs errors. Errors (and other events if you bump up the logging level) are logged to the Application Event Log by the AdmPwd Source.

You can enable additional logging by creating a new REG_DWORD value named ExtensionDebugLevel in the Registry in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}\ . Set it to 0 (the default) to log errors only, 1 to log errors and warnings, and 2 for verbose logging.

Verbose logging of LAPS AdmPwd events in the Application Event Log

Is there a log in Active Directory for LAPS?

Not by default, but it is possible to audit changes to the attributes if you enable auditing in Active Directory. Just be aware that changes are logged as Event ID 4662, which is going to inundate your DC Security Event Logs with superfluous information. Just enabling this in my lab was incredibly noisy. I wouldn’t turn on auditing unless you’ve got a plan for offloading the Event Logs or you’ve got a way to analyze them. Otherwise, you may want to look into third-party AD auditing tools.

Can I audit who accesses the passwords in AD?

Yes. To enable auditing, you’ll need to use the Set-AdmPwdAuditing PowerShell cmdlet:

Import-Module AdmPwd.PS
Set-AdmPwdAuditing -OrgUnit $OU-of-Computers-to-Audit -AuditedPrincipals:$Group-to-Audit

Enable auditing of password access in Active Directory with Set-AdmPwdAuditing

If a user accesses the ms-Mcs-AdmPwd attribute in AD, Event 4662 will be logged in the Domain Controllers Security Event Log. The schemaIDGUID for the ms-Mcs-AdmPwd, xxxxx, will be logged as part of the event and can be used for searching for the event in your logs. (Please note that you’ll need to look up this GUID in ADSI Edit as it will be unique to your environment.)

Viewing Event 4662 generated by user accessing a LAPS password in AD

I’m currently using Group Policy Preferences (insecure CPasswords) to change the passwords, and I need to migrate to LAPS. What do I need to do to stop the Group Policy Preference from overwriting the password that LAPS now manages?

If you’re transitioning from Group Policy Preferences to LAPS, you’ll need to remove the Preference that you’ve set for modifying the local Administrator account. To do this, open your Group Policy Object and go to Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups. Find the Administrator account, right-click it, and choose Delete.
Deleting the Group Policy Preference that uses the insecure CPassword

The date stored in the ms-Mcs-AdmPwdExpirationTime attribute is just numbers. How do I view the expiration date/time without the LAPS UI tool?

The expiration date that is stored in the ms-Mcs-AdmPwdExpirationTime attribute is stored in 100-nanosecond intervals that have elapsed since the 0 hour of January 1, 1601 GMT, until the expiration time. (I have no idea why it was engineered this way instead of just storing it as a date and time, but I’m sure there was a good reason.) You can convert it with w32tm.exe:

w32tm /ntte $number-you-want-to-convert

Convert the ms-Mcs-AdmPwdExpirationTime string to a date and time with w32tm

You can also use the Get-AdmPwdPassword PowerShell cmdlet to view the expiration date:

Import-Module AdmPwd.PS
Get-AdmPwdPassword -ComputerName $Target-Computer-Name

View the password and password expiration with Get-AdmPwdPassword

How quickly after a password expires does the client change the local Administrator password?

The password that is stored in AD will be updated as soon as the next Group Policy refresh runs on the client system.

Can I specify the password that LAPS uses on the client?

No. LAPS randomizes the passwords to protect against Pass-the-Hash attacks. It also ensures that the local Administrator password is being changed regularly. Forcing a specified password to multiple clients would defeat one or more of these security protections.

Does LAPS detect if someone changes the local Administrator password?

Unfortunately, no. The LAPS Group Policy Client Side Extension only checks to see if the password expiration has passed. It doesn’t verify that the password stored in AD is the same as the current local Administrator password. If the computer is still joined to the domain, you can force a reset in the LAPS UI that will update the password in AD at the next Group Policy refresh.

Can LAPS re-apply the password that is stored in Active Directory if a user with local Admin rights changes it?

No. The LAPS Group Policy Client Side Extension only checks the expiration date that is stored in AD. If the expiration date has passed, it changes the local Administrator password and updates AD. It doesn’t check to see if the password has changed from what is stored in AD and therefore wouldn’t know if the password had changed.

How do I manage the local Administrator password with LAPS if a user with local Admin rights can change it?  

I’ve had a few people tell me that they have users who are given Administrator rights and either (1) change the password for the local Administrator password without permission from IT or (2) have a business need to change the password.

If an employee has Admin rights and is changing the password without permission, that would typically be handled as a policy through an HR process in most organizations where I’ve worked. The organization would have some form of a policy for users with Administrator rights outlining what the user is and isn’t allowed to do with Admin rights. If IT determined that the employee was violating policy, the HR process would take over to notify managers, council employees, etc. so that the violation would, I hope, stop.

Some organizations may not be as willing to deal with an issue through HR and would leave it up to IT to solve the problem. In this situation, the best solution would be to take Admin rights away from the user. But, that’s not always feasible. Option #2 in this case would be to apply a separate policy to this user’s computer that lowers the threshold for Administrator password changes to 1 day. Maybe this would deter the user. If not, it still ensures that the user’s custom password doesn’t stay that way for long.

If the user does have permission to change the password, you may want to consider using a secondary Admin account with a different name for the IT department. This allows the user to continue to manage the local Administrator while giving IT the “back door” to the system if necessary. Otherwise, you may need a third-party solution.

My Security/Information Security/CyberSecurity department is concerned that, if our AD database (NTDS.dit) gets stolen, the attacker will have access to all of the local Administrator passwords on our network stored in plain text. With that information, an attacker could easily take control of computers on our network.  How do I address that concern?

The NTDS.dit contains all of the data in Active Directory: computer names, user accounts, password hashes, etc.  If you implement LAPS, this file will also contain the plain text passwords for the local Administrator accounts for all of the computers and servers managed by LAPS.  Yes, an attacker would have access to all of your local Administrator passwords in plain text should NTDS.dit file be compromised.

The most damaging thing stored in the NTDS.dit file is the password hashes for all of your user accounts, including Domain Administrators and the krbtgt account.  If you had not implemented LAPS, the attacker would not have the passwords for your computers’ local Administrator accounts, but he would still have more than enough information to wreak havoc on your network.  Hashes do secure the password to some level, but a determined attacker can use tools to crack or brute force the hashes into plain text passwords.  Even if you have a password policy that requires longer passwords (that are harder to crack), the attacker can still use the hashes to perform Pass-the-Hash attacks across the network and compromise user accounts and computers.

An attacker that steals the NTDS.dit really doesn’t need your computers’ local Administrator account passwords.  Password hashes for Domain Administrators are far more valuable since they can be used to compromise accounts and computers en masse.

We have reason to believe that the local Administrator password on several machines has been compromised. How do we force all of these systems to update the local Admin password?  

You can use the Reset-AdmPwdPassword PowerShell cmdlet in conjunction with Get-ADComputer to reset the local Administrator password for all the computers in an OU:

Get-ADComputer -Filter * -SearchBase “OU=Computers_OU,DC=corp,DC=yourdomain,DC=ext” | Reset-AdmPwdPassword -ComputerName {$_.Name}

Resetting the Administrator password on all the computers in an OU

The password for the local Administrator account has been changed and/or the password stored in Active Directory is wrong. How do I access the local Admin account on the computer?

There are two things you can do. Your first option is to force a reset of the password and then force a Group Policy refresh on the system. This assumes that you still have a logon that works on the system. If you can log in to the console, you should be able to run the Group Policy refresh.

If you can’t log in to the system, your other option is to use something like DaRT (Diagnostic and Recovery Toolkit) to boot the system to external media and reset the local Admin password with the included utility.

How can I dump the passwords for several computers at once?

You can use the Get-AdmPwdPassword PowerShell cmdlet in conjunction with Get-ADComputer to view the local Administrator password for all the computers in an OU:

Get-ADComputer -Filter * -SearchBase “OU=Computers_OU,DC=corp,DC=yourdomain,DC=ext” | Get-AdmPwdPassword -ComputerName {$_.Name}

View the passwords for all systems in an OU with Get-AdmPwdPassword

I have a management requirement that the local Administrator passwords cannot be too complex. How do I implement LAPS?

First off, this is a pretty serious security concern. The local Administrator account should only be needed in extreme cases where the system can’t be accessed by an AD account where the AD trust has been broken, the system won’t get on the network, etc. In most cases, the Help Desk or workstation Admins shouldn’t be using local accounts on these computers. Additionally, the password can easily be written down or screenshotted if needed. Once the password has been used, force a reset. Your management needs to be made aware that this is a huge security risk for your network.

That being said, there are a couple of options. Option 1 is to use a third-party password management solution. A third-party solution is more likely to give you the granular password control your environment requires. Option 2 is to relax the Password Complexity that LAPS uses. You can configure LAPS to use the “Large letters” option so workstation admins would only need to use uppercase letters.