securely manage LAPS on a Windows network

Passwords have all the time been a pain point in securing computing infrastructure. Complexity and length are key components of a robust password, but each make it inherently difficult for a human to recollect. Moreover, passwords must be modified periodically, superb once you’re working with a handful of devices, but when your network is distributed geographically with tons of, or hundreds of computers things get more complex. Fortunately, Microsoft has had an answer to this problem in the shape of Local Administrator Password Solution (LAPS), though it’s definitely not marketed as heavily as other Microsoft solutions. LAPS is a utility that permits local administrator passwords to be set programmatically based on a provided schedule using the complexity parameters you define.

make one of the best use of LAPS initial installation

As any experienced Windows administrator knows, most Windows computers in a Microsoft Energetic Directory (AD) domain retain accounts which might be local to that computer to facilitate administrative access to individual devices in cases where the domain is probably not available (network issues and even missing hardware drivers are common reasons). Securing these local accounts becomes a bit tricky. Group Policy provides options to rename the default administrator account on computers inside the policy scope, but managing the password requires a bit more effort.

At a high-level, installing and configuring LAPS requires software installation on a number of management servers, minor customization of the AD schema, configuration of settings using Group Policy, and deployment of the add-on to member servers and workstations. We’ll dig into each of those components a bit more, and likewise discover a number of issues you would possibly encounter along the way in which.

Step one in deploying LAPS is installing the utility on a server that has the Group Policy management tools pre-installed. Moreover, as a part of the LAPS deployment process involves modifications to the AD schema, I like to recommend you do that installation on a website controller, ideally the domain controller which holds the schema master role. During this installation you’ll need to install all the features under the Management Tools node (the Fat client UI, PowerShell Module, and GPO Editor templates).

The second step is to configure Energetic Directory to give you the chance to store each computer’s local administrator password and the expiration date for that password, which requires customizing the AD Schema so as to add these fields. Opening an administrative PowerShell window and executing the Import-Module AdmPwd.PS command followed by Update-AdmPwdADSchema should lead to an inventory of three actions performed successfully. If this step gives you any trouble you would possibly must be sure that your user has the suitable Schema Administrator permissions, the Energetic Directory Schema snap-in is registered (regsvr32 schmmgmt.dll), and Energetic Directory replication is healthy.

Tim Ferrill

Third, for computers to give you the chance to set passwords for his or her local administrator when required and for admins to read and reset those passwords, there are some permissions that have to be configured on the AD organizational units (OUs) that contain computer accounts. While this could possibly be done manually the LAPS install offers PowerShell cmdlets to assist manage these permissions. The Set-AdmPwdComputerSelfPermission cmdlet might be used to configure the permissions on an OU to permit computers to store the local admin password and track the date of the change. The Set-AdmPwdReadPasswordPermission and Set-AdmPwdResetPasswordPermission allow the designated groups the power to retrieve or reset the password respectively.

Finally, Group Policy settings related to the LAPS configuration have to be set. There are 4 different settings under Computer Configuration/Policies/Administrative Templates/LAPS which might be straightforward to configure.

1. First is Password Settings, which requires you to discover the varieties of characters that must be used for complexity, the length of the passwords to be generated, and the variety of days before password resets occur mechanically.
2. The second setting is used to discover the Local Administrator account to administer. This setting is barely used if the account to be managed is just not the built-in Administrator account and shouldn’t be used to reference the built-in Administrator account even when it’s been renamed.
3. Setting number three is used to be sure that the LAPS password expiration time doesn’t exceed that of the usual Energetic Directory Password Settings policy.
4. Lastly the Enable local admin password management setting simply enables LAPS for computers inside the scope of the GPO.

Tim Ferrill

LAPS security ramifications

The most important thing to pay attention to when considering using LAPS is the indisputable fact that Local Administrator passwords are stored in plain text in Energetic Directory. Within the grand scheme of things this risk is mitigated with permissions to the important thing attributes being restricted. Moreover, the chance of a single Administrator account being compromised is amazingly low in comparison with having all of the accounts set to a single password that isn’t modified mechanically.

Energetic Directory forests, which have been around for some time, could have allowed computers to be joined to the domain by non-administrative accounts. In that case, Computer accounts joined by non-admins could have the msds-CreatorSid attribute set, which grant the users that created the account additional permissions for these Computer objects in AD, including the power to read the ms-Mcs-AdmPwd attribute containing the password for the Local Administrator account.

Computer objects with the msds-CreatorSid must be identified and handled accordingly, and best practices dictate that only Administrators must be allowed so as to add latest computers to the domain.

Retrieving and resetting passwords in LAPS

Generally, the one manual interaction admins can have with LAPS will likely be to retrieve an area administrator password for a single computer. If the LAPS administration components have been installed that is as easy as using the LAPS UI, typing in the pc name, and retrieving the password. The LAPS administration components also include the Get-AdmPwdPassword PowerShell cmdlet to retrieve passwords.

Tim Ferrill

Alternatively, standard Energetic Directory administrator tools corresponding to AD users and computers or the Get-ADUser PowerShell cmdlet can each read the ms-Mcs-AdmPwd attribute, assuming the user has the correct permissions.

Local administrator passwords for computers might be reset using either the LAPS UI or the Reset-AdmPwdPassword cmdlet. These tools merely trigger the LAPS utility to re-generate a random password for the administrator account by updating the expiration to a time prior to now. The PowerShell utility is especially useful for resetting administrator passwords in bulk, a function that must be leveraged every time a privileged user leaves the team.

Microsoft further invests in LAPS

LAPS is just not a latest solution and it has its shortcomings. The excellent news is that Microsoft is actively investing in LAPS for his or her latest operating systems as a way to treatment among the weaknesses in legacy LAPS and even leverage modern technologies like Azure AD. Note that currently modern LAPS is barely supported on Windows 11 Insider Preview Construct 25145 and later, and support for integration with Azure AD is proscribed to pick out Windows Insider users, so in the intervening time it’s not ready for prime time.

The primary major feature modern LAPS brings to the table is the power to store local administrator passwords in either Energetic Directory or Azure AD. Microsoft will even support storing encrypted passwords in your on-prem Energetic Directory (running on the 2016 domain functional level or above), but not Azure AD. This closes a significant security gap in legacy LAPS for those using Energetic Directory. Modern LAPS also supports backing up AD’s Directory Services Restore Mode (DSRM ) password, a key credential for performing disaster recovery on Energetic Directory, but one which isn’t used and due to this fact easy to forget, particularly in enterprise environments.

Like legacy LAPS, much of the configuration of the trendy implementation on Energetic Directory involves management of Group Policy objects, but in fact with latest features there are latest settings. One latest setting permits you to specify the user or group that may decrypt passwords. If this setting is just not configured only members of the domain admins group in the identical domain as the pc can view passwords. The Azure AD implementation is clearly quite the paradigm shift, but chances are high in the event you’re going that route, you’ve likely already invested in Azure AD and the complexities of managing device policies through the Microsoft cloud.

One last latest feature is the power to configure LAPS to mechanically handle a password reset after an area administrator account is used. This feature is meant to limit the damage if an area administrator account becomes compromised and involves the configuration of two Group Policy settings, though a malicious user that gains administrative privileges can interrupt these actions.

The post-authentication actions setting permits you to trigger an easy password reset, a password set and a forced sign-out of the user, or a password reset and a reboot of the pc. Each of those options have their place in numerous scenarios. The second setting permits you to configure a reset delay of as much as 24 hours (with a worth of 0 disabling the feature altogether).