Nathan Ziehnert

5 minute read

Let’s face it - some probably all of us were managing our local Administrator password via Group Policy (or maybe you’re not managing your password at all… tsk tsk).  This was great until Microsoft published the location of the keys used for encrypting that data and had to disable the ability to store passwords in Group Policy since they were no longer “secure”.

Crap.

Now if you’re in an environment with more than say, 10 machines, you don’t want to go around updating the admin password on every machine, every time you need to change it. If you’re in an environment like mine (>2000 machines), that would be a near physical impossibility.  So what solutions do we have?

Well, we could write a PowerShell script to do the work.  The downside to a local PowerShell script is you have to somehow be notified of the password change, keep track of all those passwords, and at some port or another that password is going to pass cleartext or be stored cleartext.  The downside to a remote PowerShell script is that unless every machine is online when it runs, you have no guarantee that every machine will be updated.

Time to run LAPS (Local Administrator Password Solution) around your desktop security. LAPS is a nifty little utility with a nice GUI front end to manage and track your passwords SECURELY in Active Directory.

Prefontaine LAPS

What exactly is LAPS? 

Well, it’s a little bit of Active Directory magic mixed with Group Policy CSEs (client-side extensions).  Basically the flow looks something like this:

  • Group Policy and the CSE determine that the password is out of date.  The client side extension generates a new password.
  • The computer stores the new password along with the updated expiration in a couple of special Active Directory extended attributes readable only by the assigned group or by Domain Admins.
  • The computer sets the new administrator password
  • Repeat ad nauseam (luckily for us computers don’t get bored with repetitive tasks)
How do you install LAPS?

The installation procedure is simpler than it looks (don’t let AD extension scare you):

  • You extend your AD schema to include two new attributes:
    • ms-Mcs-AdmPwd - to store the password of the account
    • ms-AdmPwDExpirationTime - to store the timestamp of the password expiration
  • You set the permissions on the attributes to allow computers to WRITE to them
  • You install the Group Policy CSE on the workstations that you want to manage password from
  • You configure a Group Policy Object to set the properties of the password (length, complexity, expiration)
  • Remove or unlink your existing password group policy
  • Wait until group policy refresh happens…
  • Then you can open the admin UI and type in a computer name (provided you have access to read those extended attributes!)
If you’re ready to embark, keep reading… if not - I would strongly recommend you reconsider writing your own little script or extension to do this, since all the work is already done for you.  In this 3 part series I will walk you through the process of extending the AD schema and configuring the appropriate permissions, installing the client side extensions, and finally configuring the group policy and using the administrative user interface.

EXTENDING THE SCHEMA AND CONFIGURING PERMISSIONS

What you need to get going:
  • A computer with access to your AD domain
  • A user account with permissions to extend the schema
    • NOTE: If you’re not the AD admin for your domain, don’t crap in someone else’s bed - get them involved.
  • The LAPS installer located HERE (grab the appropriate one for your architecture)
So let’s get to it then. Logon to the computer with AD access and run the installer for LAPS (LAPS.x64.msi or LAPS.x86.msi). We’ll install the client side extensions later, for now choose the following features to install:

Installer

Once the installation is complete, you need to launch PowerShell with your Schema Extension account. Import the LAPS module by typing the following command and pressing ENTER

Import-Module AdmPwd.PS

You won’t get a return message unless importing was unsuccessful.  In which case you did not install the correct components as detailed above.  After this is completed, to extend the schema type the following command and press ENTER

Update-AdmPwdADSchema

This should output the following result - or similar to it based on your domain common names:

PowerShell AD Schema Extension

The schema has now been extended, but by default only “Enterprise Admins” and “Domain Admins” groups have access to these attributes. This is done on a parent OU basis, just in case you store your computers under multiple parent OUs. To add groups to the allowable viewers type in the following command, replacing “OU Name” with the short name of the OU that houses your computer objects, replacing “Users or Groups” with a comma-separated list of user or group short names you wish to delegate access to, and press ENTER

Set-AdmPwdReadPasswordPermission -OrgUnit "OU Name" -AllowedPrincipals "Users or Groups"

The output of the command should look something like this depending on your domain and OU names:

PowerShell Delegate Access

Finally we need to allow the computers to write their passwords back to AD.  Again this is done on a parent OU basis, so you will need to do this for every parent OU that houses computers in which you want them to write passwords back to AD.  From the PowerShell terminal type in the following command, replacing “OU Name” with the short name of the parent OU that houses your computer objects, and press ENTER

Set-AdmPwdComputerSelfPermission -OrgUnit "OU Name"

The output of the command should look something like this depending on your domain and OU names:

PowerShell LAPS Configuration

Now you’re all done with the Active Directory schema extension and permission setting.  In the next post we’ll look at installing the client side extension on workstations via GPO or SCCM.

Thanks for reading, and happy admining!

comments powered by Disqus