- 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
Does the Microsoft Local Administrator Password Solution (LAPS) require an agent? I really don’t want to install yet another agent on my computers. (Special thanks to reader Mike for this question.)
No, LAPS does not require an agent. For LAPS to function on workstations and servers, a Group Policy Client Side Extension (CSE) will need to be installed. The Group Policy CSE is not an agent. Typically, an agent is a service that runs at system startup and continues to run in the background to provide telemetry or some other data back to a central system such as System Center Configuration Manager, Operations Manager, or an antivirus monitoring platform. The CSE only runs at Group Policy refresh cycles.
Can I use LAPS without installing the Active Directory schema changes?
No, you cannot use LAPS without installing the AD schema changes. The schema update adds the ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes that LAPS requires.
Does LAPS require an additional infrastructure such as additional application servers or SQL?
No. LAPS requires two additions to your AD schema. LAPS also requires that an additional Group Policy Client Side Extension (CSE) be installed on all of the managed computers. You will not need to run an additional application server or SQL server to use LAPS.
Is storing the Administrator password in AD in plain text secure?
The ms-Mcs-AdmPwd attribute in AD is a confidential attribute protected by an Access Control List (ACL). Only users with permissions to view this attribute can view the password (that is, Domain Admins and anyone else they’ve delegated access to). Keeping the same local Administrator password across large groups of systems is a much bigger security risk.
If the passwords are stored in AD, can’t anyone with AD access view them?
No, only users with adequate permissions can view the stored passwords. You can use the Find-AdmPwdExtendedRights PowerShell cmdlet to view which groups and users can view the stored passwords. You can use the Set-AdmPwdReadPasswordPermission PowerShell cmdlet to give groups and/or users access to view the passwords.
Find-AdmPwdExtendedRights output example
Can I require two-factor authentication (2FA) to view the passwords LAPS has stored in AD?
Access to the ms-Mcs-AdmPwd attribute is controlled with a user’s regular AD credentials. You would need to implement 2FA for all user logons that have access to that data in AD. You won’t be able to require 2FA for just accessing that attribute without implementing some kind of custom solution.
What happens if an admin’s account is compromised? Wouldn’t the compromised account have access to the stored passwords?
If a user with adequate rights to view the ms-Mcs-AdmPwd attribute is compromised, that account could be used to pull all of the local Administrator passwords from your domain (or subset of computers if the user account can only view Administrator passwords for specific OUs in the domain). Typically, this kind of account would already have had enough rights to reset the password remotely on any of those computers or wreak other havoc with the delegated privileged access.
The upside of having LAPS in place is that you can now force a password reset on all systems that could have a compromised Admin password and then see in AD if they’ve updated.
Can LAPS manage the password of the local Administrator account and a custom local administrator account with a different name at the same time?
You can manage either the default Administrator account (including if the account has been renamed) or a secondary local Administrator account that you’ve created, but not both.
What happens if the computer loses its connection/trust with Active Directory? Will LAPS change the local Administrator password on the computer, but fail to update it in AD? If this happens, I won’t know the local Administrator password. (Special thanks to reader Ken D. for this question.)
The password that is stored in AD is the computer’s current password—even if the password should have expired. In this situation, the computer’s Group Policy Client Side Extension (running in the Local SYSTEM context) would be unable to check the expiration date stored in AD. When that happens, the password change process would stop. You would need to re-establish the computer’s AD trust before the local Administrator password changes again.
Can LAPS manage the local Administrator passwords on non–domain-joined machines?
No. Computers must be domain-joined to be managed by LAPS.
Can LAPS change the stored password for a service if it is using the local Administrator account?
No. LAPS will only update the local Administrator password. It will not update the service to use the new password.
Aren’t there more elaborate solutions that can do more than just randomize the local Administrator password? What if I need to rotate passwords for service accounts or do something more advanced?
Microsoft LAPS is designed to randomize passwords of the local Administrator (or a custom Administrator account) for domain-joined systems without the need to implement additional infrastructure. This gives organizations a way to randomize those local passwords to prevent large numbers of computers from being vulnerable to Pass-the-Hash attacks or from being compromised if that password becomes known. Yes, much more elaborate solutions exist if you’re willing to pay for them and take the effort to implement additional infrastructure.
What if my question isn’t listed here?
Feel free to ask your question in the comments section below!