3 Steps to Get Control of Your Local Admin Account Passwords
A few years ago, Microsoft removed the ability to store passwords in Group Policy Objects using the cPassword method that Active Directory domain administrators had been using for over a decade because it was too easy to extract the password from the GPO files on the domain controller. LAPS provides a way to securely set and retrieve a random password for local administrator accounts on domain-joined workstations. Access to the passwords can be controlled by permissions within the Active Directory database itself.
The initial deployment of LAPS is only a little more complicated than using the old method, but once deployed, new random passwords are generated for each workstation on a schedule, and the policy requires no further attention unless your organization wishes to change the password complexity or duration.
Step One: Prepare the Domain
- Download and install the Local Administrator Password Solution (LAPS) tool. Be sure to download the correct version for your operating system (64-bit or 32-bit) as the 32-bit (x86) will not install on a 64-bit OS. (Actually, you might as well download both versions. You’re going to need the msi files later.)
- Enable all Management Tool features by selecting “Will be installed on local hard drive” for each.
- It installs into “C:\Program Files\LAPS” for x64 and into “C:\Program Files (x86)\LAPS” for the x86 version. There is a graphical administrator tool, AdmPwd.UI.exe, and a PowerShell module.
- Enable all Management Tool features by selecting “Will be installed on local hard drive” for each.
- Extend the Active Directory schema. This step is irreversible but is unlikely to cause any problems. It adds two attributes for computer objects: one for the local administrator account password and one for the password expiration. Open a PowerShell window using the credentials of a Domain Admin or a Schema Admin and enter these cmdlets:
- Update Active Directory permissions. Run these cmdlets to update the permissions on the Organizational Unit that contains the computers you want to manage.
- Run this cmdlet to allow the computers to reset their local administrator passwords:
Set-AdmPwdComputerSelfPermission -OrgUnit ‘OU name’ - Run this cmdlet to allow your desktop support, help desk, etc., to view and reset the local administrator passwords:
Set-AdmPwdReadPasswordPermission -OrgUnit ‘OU name’ -AllowedPrincipals domain\object,domain\object,domain\object
…where “OU name” is the name of the OU, “domain” is your AD domain name and “object” is the user or group for whom you want to grant permissions. I recommend always using a single security group and not one or more user accounts here. It’s much easier to add a user to a group than to remove the old user’s permission and add the new user’s. Permissions to any network resource should be granted to groups and not to individuals whenever possible. - Verify the permission changes using this cmdlet:
Find-AdmPwdExtendedRights -Identity ‘OU name’
NOTE: This cmdlet does not show inherited rights, so it does not report accurate permissions on sub-OUs.
- Run this cmdlet to allow the computers to reset their local administrator passwords:
- Install the required Group Policy Administrative Templates.
- Copy the AdmPwd.admx file from C:\Windows\PolicyDefinitions on the computer where you installed the administrative tools to C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions on the primary domain controller.
- Copy the AdmPwd.adml file from C:\Windows\PolicyDefinitions\en-US (or whatever the appropriate regional folder is) on the computer where you installed the administrative tools to C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US on the primary domain controller.
- Enable auditing of password access. I would only enable auditing if you have a specific reason to.
- Use this PowerShell cmdlet:
Set-AdmPwdAuditing -OrgUnit “<Computer OU>” -AuditedPrincipals:”<User or Group Name to Audit>” - Events will appear under ID 4662 on the domain controller.
- Use this PowerShell cmdlet:
Step Two: Deploy and configure the LAPS client software.
- Install the LAPS client software on all workstations to be managed.
- Download and copy LAPS.x64.msi and LAPS.x86.msi to a network location that can be accessed by all workstations. (See above for the download link.) These are the same installation files used for the administrative functions.
- Create a new Group Policy Object (GPO) and edit it.
- Right click on “Computer Configuration\Policies\Software Settings\Software installation” and select New > Package.
- Browse to and select the x64 MSI package.
- Select Assigned as the deployment method.
- In any GPO that includes more than one installation, I like to rename each package. You can do that by opening the properties of the package in the policy and changing the Name on the General tab.
- Repeat this process for the x86 package.
- Important: Open the properties of the x86 package, go to the Deployment tab, click on the Advanced button, and de-select the “Make this 32-bit X86 application available to Win64 machines.” If you don’t do this, the policy will attempt (and fail) to install the 32-bit version on 64-bit machines.
- Right click on “Computer Configuration\Policies\Software Settings\Software installation” and select New > Package.
- Link the software deployment GPO to the Organizational Unit that contains the computers you want to manage.
- NOTE: Sometimes the workstation needs to be rebooted before the software will install or take effect.
- Configure the workstation password policies.
- Create another new GPO for setting password policies for the local administrator accounts. You can use the same GPO as for the software deployment, but I recommend keeping the two functions separate. Edit the GPO and configure the following policy settings under Computer\Policies\Administrative Templates\LAPS:
- Password Settings. This policy has 3 settings.
- Complexity. I recommend the most complex setting with 4 types of characters, but definitely don’t use anything less than the standard Windows complexity of 3 types. Click on the drop-down to select the complexity level.
- Length. I recommend 12 characters or more, but definitely no less than 10. The default value is 14, but can be anything from 8 to 64.
- Age. This setting can be overridden for any given workstation by a PowerShell cmdlet or the management GUI, but there is another setting—see below—that can prevent such an override. The aging begins when the policy goes into effect, and existing passwords won’t be changed by the policy until this threshold is met. I recommend setting the age to 1 day until all of your workstations have set new passwords, then raise it to 30 or whatever your organization’s policy dictates. The default value is 30, but can be anything from 1 to 365.
- Complexity. I recommend the most complex setting with 4 types of characters, but definitely don’t use anything less than the standard Windows complexity of 3 types. Click on the drop-down to select the complexity level.
- Name of administrator account to manage
- Enter the name of the local administrator account you intend to manage. Unfortunately, you can only manage one account per policy. Since the password will be different on each machine, you probably don’t need more than one.
- This account can be the built-in Administrator account, but should be another account, while the built-in Administrator should be disabled.
- Do not allow password expiration time longer than required by policy
- This option will prevent desktop support technicians or help desk personnel from overriding the password age in the Password Settings.
- Enable local admin password management
- This setting must be enabled before any of the other policies will have any effect.
- Create another new GPO for setting password policies for the local administrator accounts. You can use the same GPO as for the software deployment, but I recommend keeping the two functions separate. Edit the GPO and configure the following policy settings under Computer\Policies\Administrative Templates\LAPS:
Step Three: Manage the workstations
- Using PowerShell.
- Import the AdmPwd PowerShell module:
Import-Module AdmPwd.ps - Retrieve the password for any workstation within the OUs for which you have access:
Get-AdmPwdPassword -ComputerName <computername>
This will return the ComputerName, DistinguishedName, Password, and ExpirationTimeStamp. - Force a password to expire:
Reset-AdmPwdPassword -ComputerName <ComputerName> -WhenEffective <DateTime>
This cmdlet also takes pipeline input from Get-ADComputer.
- Import the AdmPwd PowerShell module:
- Using the graphical user interface (GUI).
- Retrieve a password. Start the LAPS GUI (AdmPwd.Ui.exe. See above.), enter the computer name you wish to manage, and click Search.
- Expire a password by setting a date and time in the “New expiration time” field and clicking Set.
- Retrieve a password. Start the LAPS GUI (AdmPwd.Ui.exe. See above.), enter the computer name you wish to manage, and click Search.
I abbreviated a few steps in this process that aren’t unique to deploying LAPS, such as creating a blank GPO. If you aren’t sure how to do that or how to complete one of the other steps, let me know in the comments and I’ll try to explain in more detail.
Password management has always been a pain and a constant source of scrutiny by auditors and security officers, but now you can stop worrying about it. Once you have completed this process, you can breath a huge sigh of relief.
Your local administrator account passwords are secure. You can even give a password to someone you wouldn’t normally (if it’s absolutely necessary) without giving him admin access on every other workstation in the domain. You can even expire that password so that it will only be good for a day or even just a few hours.