During my carrier I have configured Microsoft Local administrator password solution many times. But as there has been gaps or breaks between each time implement this for a customer I have to go through my notes or end up reading through the installation and technical guides. It might be worth mentioning that the installation is straight forward. It is almost like point and shoot or click next, next and then finish. But that is only for the installation part. If you are a small or a tiny customer this might work for you. But if you are a typical American SMB customer, just using the standard installation and configuration guide might not work. Before proceeding with the configuration, let me provide you some context and background. I believe with Windows server 2008 or 2008 R2, Microsoft introduced Group policy preferences which could be used to set local administrator and user passwords and group memberships. The concept and idea was very well appreciated by IT-Pros around the world until a weakness was pointed out! The weakness was that the password or passwords you chose to setup using GPO ended up in a file which was surely encrypted but the decryption key and algorithm was well know by the IT-Community and specially the ones working with security and hacking. Now you might wanna know which of the hackers, was the red team or the blue team or may be purple? Answer is all of them.
It was not like that the feature was introduced and suddenly the flaw in design was noticed. This took its time and happened gradually. Nevertheless, as the local administrator password management solution was a necessity for most of Microsoft’s customers luckily Microsoft finally invested some effort and ab course money in developing a much more secure and functional solution Aka LAPS. Normally most of IT departments ended up using same passwords for all their workstations, domain joined machined and laptops. That was supposed to be an easy to remember and accessible solution. Only problem was and still is, that having the same password on numerous machines is a big security issue. The attack vector and severity increases dramatically as if someone, normally a hacker gains access to local administrator password he/she can easily move laterally, jumping from one machine to another. Ultimately landing on servers and then moving to domain controller or otherwise critical servers. So the solution LAPS is quite sensible, as it generates unique passwords for each computer/machine. Then this password is stored on the machine object in active directory. As you are aware, you can give delegated access and permissions with Active directory only allowing certain roles and people access to view this password. The beautify of the solution is that, once a computer has been onboarded there is no more manual interaction. GPO policies are defined and the computer its self maintains local account passwords. Just to point out, we are not talking about machine passwords, these are still managed and maintained for the machine by the machine, however, in addition you get the maintenance for Local administrator accounts.
Planning before implementation
As always, implementing the solution is not difficult as I already have pointed out. But the planning part is pivotal. If you have a well defined and maintained Active directory structure the implementation will become a piece of cake. However, if you have a mess in your AD DS environment, you only will end up with a piece of spaghetti.
You need to figure out, who needs or might need access to local administrator password. Who should be able to reset this password if so required and what policies should be applied to these passwords. That is, should all machines change their local administrator passwords once a month, quarterly or annually? Or what about changing the passwords in number of days or hours? I think actually the lowest possible unit is days, so setting it in hours will be a difficult task.
If you have these pieces in place, you can start with the design part. The components being used in the solution are mostly a DLL file, AD DS users and computers management console, and LAPS fat client. The LAPS fat client is required or used when you either want to retrieve or set a new password on demand. But to retrieve the current password you can also use the users and computers management console.
In installations that I perform, I normally always, with quite few exceptions end with setting up a dedicated server having the fat client installed. Normally you do not want all you IT tiers having access to domain controllers. If you are a single or double IT employees shop, you might get away installing the software on local clients. However, sticking with my chosen best practice, you start installing the software on a machine. This machine must be domain joined as this machine is required to perform a number of tasks during the preparation of LAPS implementation.
The installation process is quite easy. You must have a computer where you will install the software, besides that you would need the software which can be downloaded from Microsoft website: Microsoft Local administrator password solution.
After you have downloaded the binaries you can either read the installation instruction of you can just follow this blog post which provides you the steps of execution, with unnecessary details. You get to installation files, one for 32 and another one for 64 bit operating system. Using the 64-bit app, and 32-bit kicks of the installation wizard
You are then required to choose the components that you intend to install on the local machine.
All components are installed on the management server as this server will be used to extend Active Directory schema and run all the Powershell scripts provided by LAPS software (Microsoft team). After you press install, before you know it, the installer is done installing LAPS for you. You see, I told you so that this is just about next, next and finish.
Now lets start extending the schema for Active Directory, start Powershell and import the module by using import-module admpwd.ps
After the module has been loaded you can start extending the Schema by issuing the command
Remember that account performing this action must have Schema admins role. Otherwise you will be informed with an error message informing you that you do not have sufficient rights to perform the action.
If you do hold the schema admin role, the Powershell script will extend the schema and provide you feedback stating that you successfully extended the schema.
Now that schema has been extended, we can start to adjust the permissions for whom might access the extended attributes in AD DS and would be able to view the Local administrator account passwords for domain joined computers. We will also be required to configure permission on Machine objects in AD DS so that the computers in question can update their objects attributes in AD DS to store the passwords whenever it is generated or updated. Lets first take care of the easy part, i.e. allowing computers permission on their object.
This can be done for multiple OU’s if you have placed you machine objects spread across different OU’s.
Next step requires you to remove permissions from OUs as well as adding new permissions on the OUs. Removing permission for extended rights is only required if you want to limit access to who can/should be able to see the password. A normal AD DS user will not be able to see the password attribute, but will however see the expiration time for the password.
if you not so concerned about this, and neither are concerned about which admin users have access to view the passwords, you can jump over the steps. However, I personally do not do this and remove extended rights from those not needing them. So to do this, In adsi edit, right click the OU and then going into properties and then permissions.
To now add the permissions for selected groups you choose to run
Once this has been done, you are ready for next stem that is to create and distribute a policy to computers.
Configuring GPO for LAPS
Configuration of the GPO is performed in the Group policy management console. The setting must be configured for a machine object under Policies – Administrative templates and LAPS
There are basically only 4 settings, password settings, and enable local admin password management are the compulsory ones to configure.
The other setting is regarding the complexity of the password to be set as well as re-generation of password.
The other two can be configured if so desired. For example if you want to enforce the password age and if the local administrator account name is not administrator.
For the password setting, default settings works well but you can make adjustments as you prefer.
LAPS client distribution
There are several methods that can be used to distribute the client. Obvious choice would be to use System center configuration manager (SCCM) however, if you do not have that, in fact if you do not have any tools for distribution of client software there still are at least a couple of automated processes for distribution of client. These are, distribution from a file-share and using a script to perform the installation or the preferred way, using GPO to install the MSI files. Let us have a look at how this can be achieved using the later option.
In group policy management console, create a new policy or edit an existing one. If you are just testing and setting up the solution, it might just be best to create a new GPO. Then navigate Computer configuration – Software settings and right click in the area to create a new package
Make sure to make this package deployment type assigned under Deployment
And under advanced button make sure to check off for Ignore language when deploying this package
Save the GPO and then link it to an OU where the machine objects resides, which will get this GPO applied to them.
Troubleshooting GPO LAPS distribution
Often people or customers get into problems where packages are not deployed to end machines. One of the common problems encountered is an error message with error id 1274. This is found in the GPO event log, if you view to message as an XML file view.
If you too encounter this GPO processing error you are in for a treat, as this error states that the installation package is not available and hence cannot be installed. The simple fix is to check if the package exists under %Windir%installer if you are installing from a file server or a network location, you must provide read access to the machine object. These rights must be provided both on NTFS permissions as well as share permissions. Once that has been done, you should see the software being pushed out like warm pancakes from a kitchen. When the client module has been installed, it is registered under installed software on the machine in question.
Its only a DLL file which is registered by the MSI installer, meaning you can also perform this action manually I mean, by using script or whatever you prefer. But then the software is not registered in installed software and you have to run regsvr32 in order to register the dll file any ways. If you take my advice, use SCCM, GPO deployment or Intune.
That was all for todays blog post. Hope that some of you find it useful, I know for sure that next time installing this product for a customer I do not need to go through my notes and that I just can come back and use my personal blog to check how it is supposed to be done. If you have any question or comments, just drop dem in the section bellow and I will get back to you as soon as I can. But there are no hurries right? Happy securing you environment.