Local administrator password solution что это

Управление паролями с помощью LAPS

LAPS (Local Administrator Password Solution) – это специальный инструмент, который позволяет быстро и эффективно проводить администрирование локальных паролей. Он необходим для обеспечения безопасности серверов и упрощения проводимых процедур. И именно с ним мы будем работать в данном материале.

Управление паролями крайне необходимо, если вы хотите защитить свой домен от несанкционированного доступа. Грамотно распорядившись имеющимися инструментами, можно не только автоматизировать процесс смены шифра, но и отследить любую подозрительную активность. Некоторые администраторы прибегают к распространенным методам для упрощения процесса обеспечения безопасности ИТ.

Но все они не решают проблему. Вот несколько из них:

• Централизованное переименование учетных записей
• Их отключение
• Установка logon script, который будет оповещать админа о входе, автоматически внося ограничения
• Установка очень сложного пароля
• Замена гостевой учетной записи на администраторскую, чтобы запутать потенциального злоумышленника.

Однако, все вышеперечисленное не может обеспечить постоянный мониторинг, логирование и анализ. Более того, данные меры предосторожности легко обходятся специальными утилитами, которые могут быть скачаны невнимательным сотрудником из Интернета.

Для повышения ИТ безопасности стоит обратить внимание на NT 6.0, которая за счет Group Policy Preferences может облегчить работу администратору:

Но нужно учесть, что данном случае пароль можно легко восстановить с помощью директории SYSVOL, где он содержится. Это нам не подходит.
Поэтому, перейдем к использованию LAPS.

Цель LAPS

Данный инструмент сочетает в себе несколько важных элементов:

• Локальная установка на отдельные рабочие станции, включая сервера, открывая доступ к новым компонентам Group Policy Client Side Extension;
• Класс computer получает дополнительные атрибуты, а сама Active Directory – расширенные схемы;
• Добавление новых шаблонов для управления и настройки политик отдельных групп;
• Автоматизация управления с помощью модуля PowerShell;
• Управление с помощью GUI;

Эти элементы открывают возможности для:

• Безопасного хранения паролей отдельных рабочих станций в Active Directory
• Установки новых правил для создания паролей
• Смены администраторских паролей, подключив защищенный канал и минуя непосредственное подключение к системе с помощью Active Directory
• Регулирования “времени жизни” паролей, а также автоматизация процесса их автоматических замен

Данная система работает на платформе Windows Server 2003, а также на базе Windows Vista, а не XP. Последнее обусловлено наличием обрабатывающего модуля GPP, который устанавливается отдельно в качестве обновления.

Установка LAPS

Демонстрировать установку LAPS мы будем с помощью версии 6.1, которая была выпущена в 2015 году. Также, разворачивание системы произойдет на Windows Server 2008 R2. Это никак не скажется на функционале нашего ПО. Но не забудьте перед началом установки загрузить версию 4.0 для Windows Management Framework
Также стоит отметить, что работа LAPS никак не будет отличаться от развернутой платформы Windows Server.

Что ещё нужно для установки?

В первую очередь, сама система LAPS. На всякий случай, загрузите все имеющиеся дистрибутивы, как для 32-х, так и для 64-х разрядных ОС.
Затем, скачайте WMF 4.0. В идеале, она уже должна быть развернута на вашем сервере, если вы создавали базовую систему управления паролями. Вот, что у вас будет:

Устанавливаем LAPS для администратора

Полный пакет LAPS нужно развернуть на рабочей станции админа. Все основные компоненты устанавливаются сразу, поэтому вам не придется возвращаться к этом позднее. Но GUI-клиент может потребовать от вас дополнительных усилий.

Мы будем ставить LAPS непосредственно на DC, игнорируя AdmPwd GPO Extension. Этот компонент нам не понадобится. Но для остальных инженеров, которые будут работать с системой, он необходим.

Мы установим несколько важных компонентов:

• Fat Client UI: осуществляет быстрый поиск нужной станции с помощью сортировки по именам, просмотру или смене пароля
• PowerShell Module: обеспечивает администрирование LAPS с помощью PowerShell-модуля
• GPO Editor templates: позволяет использовать новые шаблоны для настройки LAPS

Остальное должно быть понятно интуитивно. По завершению установки, разверните WMF 4.0.

Расширение схемы LAPS

Основная работа LAPS базируется на двух атрибутах:

• ms-Mcs-AdmPwd: отвечает за хранение паролей
• ms-Mcs-AdmPwdExpirationTime: хранит данные о сроке их действия.

Данные атрибуты являются дополнительными для схемы, а их установка очень проста. Для начала, запустите PowerShell с правами на изменение Active Directory. Затем выполните два шага:

1. Используйте команду Import-Module AdmPwd.PS, чтобы подгрузить модуль LAPS
2. Используйте команду Update-AdmPwdADSchema

Результат – два функционирующих атрибута. Первый:

Не включайте GC, так как это позволит осуществлять поиск по тексту установленных паролей. Все остальные атрибуты достаточно просты и ясны с точки зрения использования:

Настройка домена для LAPS GPO

Схема LAPS использует собственные шаблоны GPT. Мы может сделать их доступными, перенеся их в Central Storage. Это позволит всем администраторам ознакомиться с действующими политиками. Не нужно оставлять эти шаблоны в той директории, куда они были сложены по умолчанию, тем самым ограничивая своей команде административные возможности.

Итак, поищем шаблоны групповой политики (GPT):

Не забудьте про языковый файл AdmPwd.adml, который находится в директории en-us. Мы перенесем все это в Central Storage:

Проведем проверку на корректную работу:

Мы поможем улучшить и облегчить контроль учетных записей и повысить внутреннюю безопасность ИТ среды предприятия. Обращайтесь [email protected]

Installing and Configuring Microsoft LAPS: A Complete Guide Part 1

Microsoft LAPS: Installation and Configuration Part 1 — Int64 Software Blog

Microsoft LAPS (Local Administrator Password Solution) is making a big splash in the Active Directory community by…

Update Feb 2019

Please note that OVERLAPS has now been updated to version 1.2 and has even more to offer LAPS users, including a free trial:

Introducing OverLAPS for Microsoft LAPS — Update 1.2

We are happy to announce the release of OverLAPS 1.2. This latest update for our web interface to Microsoft's Local…

Microsoft’s Local Administrator Password Solution (LAPS) is making a big splash in the Active Directory community by providing a simple, secure, and free solution to the age-old question of how to secure your Local Administrator accounts.

Today we’re going to take a look at LAPS while doing a fresh install and configuration in our internal development Active Directory environment, taking a look at any gotchas or unanswered questions along the way.

What is the Local Administrator Password Solution?

Simply put, Microsoft’s LAPS tool randomises the local administrator account on each computer and stores the new password on the computer object in Active Directory.

Specifically, part of the installation process extends your Active Directory schema to include two new values:

ms-Mcs-AdmPwd

Stores the current Administrator password.

Stores the timestamp (measured in 100-nanosecond chunks that have elapsed since 1st January 1601 (GMT)).

A DLL (AdmPwd.dll) is installed on each client which runs a check against the timstamp when a Group Policy refresh occurs to see if the password needs to be refreshed.

A Note on Interacting with LAPS (and a better solution than the ones provided by default)

The LAPS technology as it stands is mostly concerned with the action of randomly refreshing Local Administrator passwords. It has little concern for day-to-day usability, and as such it expects you to install either the AD client tools or the LAPS client utility (“Fat Client UI”) on each and every computer you want to be able to access the passwords from.

Naturally this is less than ideal, and should you need to access it from a mobile or non-Windows device, there are limited options available.

For this reason we have made OverLAPS available, which is a simple, self-hosted web interface for LAPS that allows multi-device, multi-operating system access to LAPS managed passwords, and makes it super simple to control who gets that access.

Installing LAPS

We’ll now go over the (relatively) simple installation process for LAPS. Note that we’ve brought up a development domain specifically for this purpose, and would strongly recommend anyone following this do the same before making schema changes to your Active Directory structure.

Step 1: Prerequisites

The current version of LAPS is 6.2 and is available from Microsoft’s website here.

(Note: Part 2 of this tutorial will also be going over the OverLAPS installation and configuration procedure as it provides a much more intuitive interface to LAPS, so we’ve grabbed the installer for that as well, see here)

You’ll also need a Domain Administrator or other account with permissions to modify the AD schema. The installation can be run from any domain joined computer or server.

Step 2: Installation

Launch LAPS.x64.msi (or LAPS.x32.msi if you’re in a 32bit OS).

The features we’ve opted to install here are:

AdmPwd GPO Extension

Installs the LAPS client for managing this devices password (as a Group Policy Object extension so that it can run during GPO update).

Required for extending the AD schema and initialise configuration of LAPS.

GPO Editor templates

Installs the ADMX for enabling and configuring LAPS through Group Policy.

We have opted not to install the “Fat Client UI” because we’ll be using OverLAPS instead.

Step 3: Active Directory Schema

The next step is to extend the AD schema with the two new computer object properties. To do this, we’ll need PowerShell (running as a Domain Administrator or another user with the rights to modify the schema).

Start by importing the LAPS AdmPwd.PS module, which contains all the tools we’ll need today.

Next, run the command to update the AD schema. If everything goes to plan, you should see “Success” all the way down the Status column.

Step 4: Check Existing Permissions

Now before we do anything else we need to secure Active Directory to make sure only people/services we allow can access the new properties. We can do this from within PowerShell by using the command “Find-AdmPwdExtendedRights” with the root OU for your computer objects (in our case a container called “ManagedDevices”)

We can see from this that only SYSTEM and Domain Admins have access to these OUs, but if you notice any groups you don’t want here (for example “Authenticated Users”, which would indicate all logged in users have access), load ADSI Edit and find the root OU for your computer objects.

Right click this and go to Properties -> Security, then click the Advanced button. Select the “Authenticated Users” (in this example) principal and click Edit.

Make sure that “All extended rights” is unchecked. Then click OK to apply the change.

Step 5: Allow Computers to Record their Password Changes

Now your computers will need to the rights to change the password and expiry values from the LOCAL SYSTEM account. Back in PowerShell, use the Set-AdmPwdComputerSelfPermission command to apply this permission to computers in your root computer OU.

This will add two new ACLs to the container for the “SELF” account, one for writing a new password, and another for reading/writing the expiration timestamp. Note that the account does not have read access to the password.

Step 6: Configure LAPS Group Policy

We go into greater detail on the individual policy settings in our post A Look at the Microsoft LAPS Group Policy Settings, but a brief overview of these are included below.

Define a new Group Policy Object linked to the root Computer container and navigate to Computer Configuration -> Policies -> Administrative Templates -> LAPS.

Allows you to configure the compexity, length and maximum age of LAPS managed passwords.

Name of administrator account to manage

If you’ve renamed your Local Administrator accounts, you can use this setting to specify the new name. (Take a look at our article Local Administrator: To Rename or not to Rename for our views on this).

Do not allow password expiration time longer than required by policy

Setting this tells LAPS that a password expiry longer than the one defined in “Password Settings” is not allowed (if being set manually). This prevents users with write access to the timestamp from setting it to a year in the future (for example) when the password policy clearly dictates it should reset every 7 days.

Enable local admin password management

The master switch for LAPS. Enabling this enables Local Administrator password management.

Step 7: Distributing the LAPS “Client”

The LAPS AdmPwd.dll CSE (Client-Side Extension) must now be distributed to all managed computers and registered. You have a number of options for achieving this, but we’ll concentrate on the two most common ways.

One simple method is to place the DLL on a share and have Group Policy copy the file to each computer, and use a startup script to register it.

I’ve worked in environments before where the proliferation of complex GPOs caused massive slow-downs however; and as the DLL really doesn’t need to be registered on every system startup, this may not be the best solution.

You can also simply run the LAPS .msi installer on your clients with the “/quiet” parameter. By default only the CSE is installed.

Your choice of how to do this depends very much on your environment: maybe you’d use SCCM or a similar technology. We opted to use our own Overcee suite though as I suppose you could say we’re experts in that technology.

For a more detailed look at setting up a custom tool like this in Overcee, please see our post titled “Tutorial: Privilege Escalation Vulnerability Scan Tool and Overcee“.

Installation Complete

That’s it for LAPS. Your computer’s administrator accounts may not change right away, but pretty soon you should see them starting to update.

What’s Next?

Head over to Part 2 of this article where we set up a funky web interface for LAPS so that we can access from any device while on the go.

Want More?

Follow me on Twitter (@matt_is_ready) for programming related content, or my company (@Int64Software) for infosec and other technical content.

5 Top Local Administrator Password Solution (LAPS) Tips

The local Windows administrator account is a coveted target for hackers and malware. There are potentially a lot of bad things that can happen if a hacker can crack the local admin account of one of your servers.

Dreadful things usually occur when someone downloads a malicious malware strain using the administrator account as well. The magnitude of these problems is amplified even more if you use the default administrator account for every similar machine uses the same password.

You can have the most complex password in the world, but once it is compromised on one machine, it is open season for all other devices using the same local admin credentials.

Of course, you could customize the local admin credentials for every Windows device, but that can prove highly time-consuming not to mention the task of inventorying the many credential sets. The process becomes virtually unworkable when you enable password refreshes (which you should of course). This is why many admins often just disable it.

But it’s understandable to have some type of local admin account to “walk up and fix the machine” like resetting it’s domain trust relationship or hardcoding an IP address, and so on.

If having the same local admin password on each machine is a terrible idea, what can be done about it?

Tip 1: Use Microsoft Local Administrator Password Solution (LAPS)

Microsoft Local Administrator Password Solution (LAPS) is a Microsoft tool that gives AD administrators the ability to manage the local account password of domain-joined computers and store them in AD.

When implemented via Group Policy, LAPS creates a random password of a defined length and complexity that is cryptographically secure and different every time, on every machine. It then applies the newly created password to the Local Administrator account and records the password in a secure field in your Active Directory schema. They can then be retrieved when access is needed to the account. The process is done automatically whenever a Group Policy defined password refresh is due.

LAPS does have a few requirements to implement it:

• It only applies to Windows devices
• Devices must be domain joined
• It requires a free Group Policy client-side extension
• It requires a schema extension (don’t freak out.)
• It only works for the local admin account
• It only works for ONE local admin account (in case you have more than one.)

Tip 2: LAPS and Group Policy

As mentioned, LAPS is deployed using Group Policy, which means it requires the creation of a GPO. You first need to download LAPS which you can do here.
Then use the wizard to install it on your Group Policy Management machine. You’ll want to do this by hand, and typically NOT in some automated way.

Make sure you at least select the GPO Editor Templates in order to access the necessary ADMX files. The fat client is a graphical user interface that gives a user with applicable rights the ability to query the password for a designated device. You only need to install the Management Tools, and not the “AdmPwd GPO Extension” on your machine (the one with the GPMC.)

You must then go into your local PolicyDefinitions folder and copy the AdmPwd.admx and AdmPwd.adml files and paste them into your AD central store. (Check this video on this process).

Next, we need to extend the AD Schema in order to accommodate the local passwords.

The two required attributes are:

• ms-Mcs-AdmPwd – Stores the password in clear text
• ms-Mcs-AdmPwdExpirationTime – Stores the time to reset the password

To update the schema, simply import the AdmPwd PowerShell module and use the update-AdmPwdADSchema command as shown below.

The next step is to create a computer side GPO. For this example, I will call it LAPS Policy. The LAPS settings will now appear under Computer Configuration > Administrative Templates > LAPS where 4 settings are available as is shown below.

You can use your LAPS GPO to manage the password for either the default local admin or a custom local admin account. Below I have enabled the “Enable local admin password management ”setting.”

If you have renamed the local admin account, (which you should) you can then specify the updated name. Once the admin account is selected, the final step is to enable the Group Policy setting which configures the password settings (that include password length and age.)

Once configured, simply deploy the LAPS client-side-extension software via your desired software deployment method, like PDQ Deploy. You only need the “GPO Extension” part if you’re going to do an initial test by hand. You can see this here.

You can also use PolicyPak to gain more control over the deployment process. More on that in just a minute.

Tip #3: Getting Passwords when needed via LAPS

So, the day comes that you need to know what the current generated password is for one of your Windows machines. How do you do it? There are several ways. On is to use the following PowerShell command.

Get-AdmPwdPassword -Computername “name of computer”

If you installed the LAPS Fat Client, you can access the LAPS UI application in your start menu.

Tip #4: Assign Granular LAPS Policies to Users via Item-Level Targeting

PolicyPak offers all of the ADMX template settings in its PolicyPak Admin Templates Manager and we update them at the time of every new ADMX release. There’s a lot of advantages to using Admin Templates Manager versus standard Group Policy.

PolicyPak uses Group Policy Editor as is shown below but adds a secret superpower.

The key benefit is that PolicyPak can utilize Item-level Targeting for any Group Policy setting, including LAPS.

If you are familiar with Group Policy Preferences, then you already know how ILT provides a lot more granularity concerning policy assignment. For instance, let’s say that all of the local admin accounts residing on your servers are named ServAdm1n and you want to create a separate LAPS policy for those admins. Since those aren’t admin domain accounts, you can’t target them using group policy but you can use ILT to target those machines running Windows Server 2016.

Now let’s make a LAPS policy for C-Level executive laptops. Naturally, we would want to have a strong password for those local admin accounts. In this case, I want to enforce 20-character passwords using the strongest complexity. Then I will use ILT to target the C-Level security group. As you can see in the screenshot below, there are many targetable options including computer name, OU Match, Site Match, computer form factor (Laptop vs. Desktop) and more!

As a bonus, while traditional GPOs created within the Group Policy Editor can normally only be deployed using Group Policy, PolicyPak settings can be deployed using a number of ways such as SCCM, KACE or your preferred MDM service.
You can learn more about that process by watching this video that demonstrates the process of delivering Group Policy settings, without the Group Policy engine itself.

Tip 5: Pair LAPS with PolicyPak Least Privilege Manager

Local Administrator Password Solution is a great tool to tighten administrative access to your most important machines. In fact, it also makes a great pairing with PolicyPak Least Privilege Manager. PolicyPak Least Privilege Manager completely removes the need to have local admin rights, enabling Standard Users to do special functions like an admin… but without actual admin rights.

Together, you could enforce LAPS on all of your enterprise machines … since you won’t be needing local admin access any longer.

In the end, whatever you can do with Group Policy, you can do it better with PolicyPak. Implement LAPS and add PolicyPak and get more security, power, and agility.

Local Admin Password Solution (LAPS)

LAPS or Local Admin Password Solution is a solution that automatically generates a unique local administrator password and writes that password back to Active Directory. This way each client or server has a unique local administrator password based on a set password policy. If we go back a few years many organizations used a GPO (Group Policy Object) to specify the local administrator password, some even do this today. Having the same administrator password on all clients in the organization is very convenient for administrators and helpdesks, but extremely unsecure. If a single device within the organization was compromised, an attacker would have access to all the other clients and servers where that particular GPO was applied. LAPS was released initially back in 2015, but unfortunately I still see customers that still have not implemented this best practice from Microsoft. In this post I will be walking through how to implement LAPS in an on-premise Active Directory Environment.

Microsoft has not implemented a similar tool for its Azure Active Directory joined devices. From what I understand it is something Microsoft is considering, but there is no timeframe as of now. See my post on Administering Local Administrator Access using Privileged Identity Management (PIM), this is probably the best Microsoft solution for Azure AD joined devices. If you would like to use a community tool check out CloudLAPS.

Contents

Requirements

• Downloaded LAPS from Microsoft here.
• Active Directory environment
• Test Client or Server
• Schema Admin
• Domain Admin (GPO and Delegation rights)
• Local Admin access on an existing Management Server / Domain Controller
• Preferably a Management System Like Configuration Manager but not required.

Extending the Active Directory Schema

LAPS does not require any specific Functional Level or Domain level, however the Active Directory schema must be extended to allow for two new attributes on the computer object.

ms-Mcs-AdmPwd – This attribute stores the local administrator password.

ms-Mcs-AdmPwdExpirationTime – defines when the password will expire and automatically changed.

1. Install the LAPS on your Management Server / Domain Controller. Make sure that the all of the management tools are selected for installation. We will create a client installation package later.

1. Open PowerShell as an Administrator and import the LAPS PowerShell module.

1. Extend the Schema using PowerShell.

Caution: Making changes to the Active Directory Schema is a big change in production environments. I recommend a restart of the domain controller and the management server before and after making change to the schema. Remember that it can take a while for larger environments to replicate the changes.

Now that the schema has been extended with the attributes we need for LAPS we can start assigning permissions.

Specifying Permissions

1. Firstly we need to give our devices the ability to write the LAPS password back to Active Directory by using the following PowerShell cmdlet. Repeat the command for all OU’s that contain devices.

1. To allow support and operations teams to read passwords, a new group called LAPSReaders has been created. To delegate the appropriate permissions to the AD group use the following PowerShell cmdlet.

1. To find what security principals have access (extended rights) to a particular OU and also verify that the LAPSReaders were given permissions, use the following PowerShell cmdlet.

To prevent certain users or groups from reading the passwords the Extended RIghts attribute for those users need to be removed. To do this open ADSI Edit (adsiedit.msc) and connect to the Default Naming Context. Navigate to the OU that contains devices, right click the OU and select Properties. Select the Security tab then click Advanced. Locate the user/group that should not have access and click Edit. Remove the All Extended Rights attribute and repeat for any other device OUs.

Note: Removing the All Extended Rights could impact other services and applications used in the organization. Verify that this does not cause issues in your environment.

Group Policy

Our next task is to create a Group Policy that will be used to define our password complexity, length and password age that LAPS will generate. When we initially installed LAPS on our Management Server / Domain Controller the AdmPwd.admx and AdmPwd.adml files were installed into the C:\Windows\Policy Definitions folder. If your environment has been configured with a central store for Group Policy objects (most likely the case for enterprises) then these two files need to be copied to the central store. If a central store is not configured make sure the two files are present on the domain controllers Policy Definitions folder.

1. Open the Group Policy Management Editor
2. Create a new policy for LAPS
3. Edit the LAPS policy and navigate to Computer Configuration -> Policies -> Administrative Templates -> LAPS. If the LAPS folder is not present then the AdmPwd.admx anf AdmPwd.adml files have not been copied correctly.

1. Start by setting the Enable local admin password management to Enabled. If this setting is set to anything other than Enabled, LAPS will not perform any password management.
2. Open Password Settings and set the policy to Enabled. Configure the password complexity, length and password age to fit your needs.

1. Next set the Do not allow password expiration time long that required by policy to Enabled. This setting enforces the password age specified in Password Settings. If this setting is set to disabled or not configured passwords can have a longer password age than the value specified in Password Settings.
2. The last setting Name of administrator account to mange should only be configured if LAPS will not administer the built-in Administrator account (even if this account has been renamed. The SID remains the same even if the account is renamed). If a dedicated account is used specify it here. For this walkthrough we will be using the built-in Administrator account and hence this option will be left unconfigured.

Deploy LAPS to Clients/Servers

In order for LAPS to work correctly on clients and servers the LAPS software needs to be installed. In this environment we will leverage Group Policy to install LAPS to our devices, for larger organizations a management system like Configuration Manager is preferred. When we initially installed LAPS on our Management Server / Domain Controller we installed all the management tools, these are not required on the endpoints.

1. Copy the installation file to a central location. Since we will be using Group Policy to deploy the software we will simply use the NETLOGON share to host the installation media.
2. Open the Group Policy Management Editor and edit the LAPS policy that we created earlier.
3. Navigate to Computer Configuration -> Policy -> Software Installation.
4. Right click Software Installation -> New ->Package. Specify the network path to the installation file, in my example it would be \\lab.local\NETLOGON\LAPSx64.msi.
5. Once the installation package is selected choose Assigned

Group Policy will now install the LAPS software on all devices the GPO is applicable to. Software installations are only done prior to user logon, meaning that the device will receive the Group Policy but the installation wont be triggered while we are logged on. For testing purposes run gpupdate from the command line and restart the client/server to trigger the installation.

Verifying

The LAPS UI tool should be installed on the Management Server / Domain Controller where we installed the management tools. This is the tool that you should make available to your helpdesk or any other personnel that needs access to the local administrator credentials. The password will automatically be changed by the policy once the password age expires, alternatively an administrator can change the expiration time.

We can also find the same information through the Active Directory Users and Computers snap-in (dsa.msc). Under View make sure Advanced Features is enabled. Locate the appropriate computer object, and view its Properties. In the Attribute Editor tab locate the two attributes used by LAPS.

To easiest way of retrieving LAPS information through PowerShell is using the Get-AdmPwdPassword cmdlet, but this requires the LAPS module that might not always be present.

Troubleshooting

LAPS logs all of its events in the Application Event Log and by default only logs errors on the local computer. If more logging is required create a new registry using the cmdlet below, adjust the value using the reference table.