local administrator password solution что это за программа
LAPS: управление паролями локальных администраторов на компьютерах домена
В этой статье мы рассмотрим способ управления паролями локальных администраторов на компьютерах домена с помощью официальной утилиты Microsoft – LAPS (Local admin password solution).
Вопрос управления встроенными учетными записям на компьютерах домена является одним из важнейших аспектов безопасности, требующих внимание системного администратора. Безусловно, не стоит допускать использования одинаковых паролей локальных администраторов на всех компьютерах. Есть множество подходов к организации управления учетными записями локальных администраторов в домене: начиная от полного их отключения (не очень удобно), до управления ими через logon скрипты групповых политик и создания собственных систем управления встроенными учётками и их паролями.
Ранее для изменения паролей локальный администраторов на компьютерах домена часто использовались расширения групповых политик (GPP – Group Policy Preferences), однако в них была найдена серьезная уязвимость, позволяющая любому пользователю расшифровать пароль, хранящийся в текстовом файле в каталоге Sysvol на контроллерах домена (об это мы подробно говорили в статье Почему не стоит задавать пароли через Group Policy Preferences). В мае 2014 года Microsoft выпустила обновление безопасности (MS14-025 – KB 2962486), полностью отключающее возможность задать пароль локального пользователя через GPP.
Утилита LAPS — Local Administrator Password Solution
Утилита LAPS (Local Administrator Password Solution) позволяет централизованной управлять паролями администраторов на всех компьютерах домена и хранить информацию о пароле и дате его смены непосредственно в объектах типа Computer в Active Directory.
Функционал LAPS основан на использовании специального функционала GPO, который основан на Group Policy Client Side Extension (CSE) и представлеяет собой небольшой модуль, который устанавливается на рабочие станции. Данное расширение GPO используется для генерации уникального пароля локального администратора (SID — 500) на каждом компьютере домена. Пароль администратора автоматически меняется с указанной периодичностью (по-умолчанию, каждые 30 дней). Значение текущего пароля хранится в конфиденциальном атрибуте учетной записи компьютера в Active Directory, доступ на просмотр содержимого атрибута регулируется группами безопасности AD.
Дистрибутив LAPS доступен в виде двух версий установочных msi файлов: для 32 (LAPS.x86.msi) и 64 (LAPS.x64.msi) битных систем.
Архитектура LAPS состоит из 2 частей. Модуль управления устанавливается на машине администратора, а клиентская часть устанавливается на серверах и ПК, на которых нужно регулярно менять пароль локального администратора.
Установка LAPS максимально простая и не должна вызывать каких-либо проблем.
Подготовка схемы Active Directory для внедрения LAPS
Перед развертыванием LAPS необходимо расширить схему Active Directory, в которую будут добавлены два новых атрибута для объектов типа компьютер.
Для расширения схемы, нужно открыть консоль PowerShell, импортировать модуль Admpwd.ps:
Расширьте схему Active Directory (нужны права Schema Admin):
Update-AdmPwdADSchema 
В результате в класс «Computer» будут добавлены два новых атрибута.
Настройка прав в AD на атрибуты LAPS
LAPS хранит пароль локального администратора в атрибуте Active Directory ms-MCS-AdmPwd в открытом виде, доступ к атрибуту ограничивается благодаря механизму конфиденциальных атрибутов AD (поддерживается с Windows 2003). Атрибут ms-MCS-AdmPwd, в котором хранится пароль, может быть прочитан любым обладателем разрешения “All Extended Rights”. Пользователи и группы с этим разрешением могут читать любые конфиденциальные атрибуты AD, в том числе ms-MCS-AdmPwd. Т.к. мы не хотим, чтобы кто-то кроме администраторов домена (или служб HelpDesk) имел право на просмотр паролей для компьютеров, нам нужно ограничить список групп с правами на чтение этих атрибутов.
С помощью командлета Find-AdmPwdExtendedRights можно получить список учетных записей и групп, обладающих этим правом на конкретную OU. Проверьте, кто обладает подобными разрешениями на OU с именем Desktops:
Как вы видите, право на чтение конфиденциальных атрибутов есть только у группы Domain Admins.
Ели вам нужно запретить определенным группам или пользователям доступ на чтение таких атрибутов, нужно выполнить следующее:
Аналогичным образом нужно поступить со всеми группам, которым нужно запретить право на просмотр пароля.
Далее нужно предоставить права учетным записям компьютеров на модификацию собственных атрибутов (SELF), т.к. изменение значений атрибутов ms-MCS-AdmPwd и ms-MCS-AdmPwdExpirationTime выполняется из-под учетной записи самого компьютера. Воспользуемся еще одним командлетом Set-AdmPwdComputerSelfPermission.
Чтобы дать права компьютерам в OU Desktops на обновление расширенных атрибутов, выполните команду:
Предоставление прав на просмотр пароля LAPS
Следующий этап – предоставление прав пользователям и группам на чтение хранящихся в Active Directory паролей локальных администраторов на компьютерах домена. К примеру, вы хотите дать членам группы AdmPwd права на чтение паролей компьютеров в OU:
Кроме того, можно предоставить отдельной группе пользователей право на сброс пароля компьютера (в нашем примере мы предоставляем это право той же группе AdmPwd).
Настройка групповой политики LAPS
Далее нужно создать новый объект GPO (групповых политик) и назначить его на OU, в которой содержатся компьютеры, на которых вы будете управлять паролями администраторов.
Создайте политику с именем Password_Administrador_Local следующей командой:
Как вы видите, имеются 4 настраиваемых параметра политики. Настройте их следующим образом:
Назначьте политику Password_Administrador_Local на OU с компьютерами (Desktops).
Установка LAPS на клиентские компьютеры через GPO
После настройки GPO нужно установить клиентскую часть LAPS на компьютеры в домене. Установить клиент LAPS можно различными способами: вручную, через задание SCCM, логон скрипт и т.п. В нашем примере мы установим msi файл с помощью возможности установки msi пакетов через групповые политики (GPSI).
Осталось назначить политику на нужную OU, и после перезагрузки, на всех компьютерах в целевом OU должен установиться клиент LAPS.
Проверьте, что списке установленных программ в Панели Управления (Programs and Features) появилась запись “Local admin password management solution”.
Когда утилита LAPS меняет пароль локального администратора, запись об этом фиксируется в журнале Application (Event ID:12, Source: AdmPwd).
Событие сохранения пароля в атрибуте AD также фиксируется (Event ID:13, Source: AdmPwd).
Вот так выглядят новые атрибуты у компьютера в AD.
Использование утилиты LAPS для просмотра пароля администратора
Графическую утилиту AdmPwd UI для просмотра паролей LAPS нужно установить на компьютерах администраторов.
Запустите утилиту, введите имя компьютера (в поле computername), и вы должны увидеть текущий пароль локального администратора компьютера и срок действия.
Дату истечения пароля срока действия пароля можно задать вручную, либо оставить поле с датой пустым и нажав кнопку Set (это означает, срок действия пароля уже истек).
Пароль также можно получить с помощью PowerShell:
Если вы считаете, что пароли локальных администраторов на всех компьютерах в некотором OU скомпрометированы, вы можете одной командой сгенерировать новые пароля для всех компьютеров в OU. Для этого нам понадобится командлет Get-ADComputer:
Аналогичным образом можно вывести список текущих паролей для всех компьютеров в OU:
LAPS можно рекомендовать как удобное решение для организации безопасной системы управления паролями на компьютерах домена с возможностью гранулированного управления доступом к паролям компьютерам из разных OU. Пароли хранятся в атрибутах Active Directory в открытом виде, но встроенные средства AD позволяют надежно ограничить к ним доступ.
Управляем паролем локального администратора с помощью LAPS
Одной из самых распространенных проблем, с которой сталкивается почти каждый системный администратор, является управление паролями локального администратора.
Существует несколько вариантов решения данной задачи:
LAPS расшифровывается как Local Administrator Password Solution и является наследником решения AdmPwd, которое было поглощено Microsoft и переименовано в LAPS. LAPS бесплатен и не требует дополнительных расходов на инфраструктуру, так как использует Active Directory в качестве базы данных. Поддержка доступна в рамках Microsoft Premier Support Services.
Автор оригинальной AdmPwd разработал новый продукт AdmPwd.E, но бесплатная версия ограничена 20 ПК, так что подойдет не всем. Официальный сайт.
LAPS поставляется с обширной документацией (только на английском) и вообще оставляет впечатление крайне продуманного и надежного решения.
Архитектура
Система состоит из следующих компонентов:
Полная диаграмма работы LAPS приведена на следующем изображении.
Установка и настройка LAPS
Для начала установим средства управления LAPS на компьютер, с которого будем осуществлять настройку.
Запускаем msi пакет и устанавливаем все Managemnt Tools, которые включают LAPS UI, модуль PowerShell и шаблоны групповой политики.
Если у вас настроено централизованное хранилище шаблонов групповых политик, то сразу переносим файлы «Admpwd.admx» и «En-us\AdmPwd.adml» из «%SystemRoot%\PolicyDefinitions» в «\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions».
Следующим шагом будет добавление новых атрибутов в схему AD. Для этого необходимо открыть консоль PowerShell от имени учетной записи с правами «Schema Admin» и сначала импортировать модуль командой «Import-module AdmPwd.PS», а затем обновить схему командой «Update-AdmPwdADSchema».
Эта команда возвращает список учетных записей/групп, которые будут иметь доступ к паролям хранящимся в AD. Если вы обнаружили «лишние» учетные записи/группы, то воспользуйтесь утилитой ADSIEdit для корректной настройки прав доступа. Убедитесь, что право доступа «All extended rights» не отмечено для тех групп, которые не должны иметь доступ к паролям.
Следующим шагом будет настройка групповой политики. Мы можем контролировать сложность и срок годности паролей, имя учетной записи пароль которой будет меняться, а также включать и выключать работу LAPS.
Имя учетной записи нужно указывать только в том случае, если это специально созданная учетная запись. Если это встроенная ученая запись, то этот параметр надо оставить в «Not configured» (Даже если учетная запись переименована), так как встроенная учетная запись будет найдена по well-known SID.
Следующим этапом будет установка расширения групповой политики на ПК. Это можно возложить на групповые политики, на SCCM, либо на другое средство развертывания приложений. Следует отметить, что по умолчанию msi пакет устанавливает только клиентскую часть, так что развертывание не требует передачи дополнительных параметров инсталлятору. Перезагрузка ПК потребуется только при развертывании через групповые политики.
Для просмотра пароля проще всего воспользоваться LAPS UI. Вводим имя компьютера в соответствующее поле и нажимаем «Search». Если мы все сделали правильно, то вы увидите пароль в соответствующем поле.
Работаем с LAPS (Local Administrator Password Solution)
Управление локальными паролями администраторов на доменных машинах – достаточно древняя и до сих пор актуальная задача.
Ведь по сути, жизненный цикл учётной записи администратора, в плане продолжительности, равен жизненному циклу рабочей станции – поэтому задачи защиты этой учётной записи от НСД, периодической смены пароля на известный IT-отделу (чтобы можно было проводить в случае форс-мажора какие-либо нужные действия), отслеживание нецелевого использования (как локального, так и удалённого – ведь знающий этот пароль в обычной ситуации может удалённо подключаться к системе и проводить различные действия) – все эти и множество других, более мелких, но нужных задач – они отнимают много времени и снижают общий уровень безопасности домена.
Все эти варианты чем-то снижают проблематику, но не убирают её. Организовывать сложную систему постоянного мониторинга за статусом этой учётной записи, не отредактировали ли её, не зашли ли ей, не запустили ли что-то от неё – трудоёмко и опять-таки не спасает от всех ситуаций НСД – например от того, что продвинутый пользователь скачает утилиту, которая позволит на загрузке сбросить пароль локального админа. Но задачи управления этой учётной записью и безопасного и автоматического обновления её пароля всё ж решаемы.
Начиная с NT 6.0 у вас появились Group Policy Preferences, которые тоже могут помочь в этом деле:
Но неприятность в том, что данный пароль будет лежать в легковосстановимом виде в папке SYSVOL, вместе с остальными данными GPP. Так что проблемы остаются.
Эти вопросы – и некоторые другие – можно решать более цивилизованным способом – используя LAPS.
Давайте разберёмся. Я предполагаю, что вы знаете вопросы работы Active Directory хотя бы на уровне простенького бесплатного курса Microsoft 20410D, поэтому в отдельные совсем уж тривиальные детали углубляться не буду.
Использование LAPS (Local Administrator Password Solution)
Что умеет LAPS
Работать всё это будет на инфраструктуре, построенной на DC уровня Windows Server 2003 и выше, и управлять паролями на системах, построенных на базе серверной ОС Windows Server 2003 и клиентской ОС Windows Vista. Да, XP официально не поддерживается, увы – но можно использовать приведённый выше пример с Group Policy Preferences, ведь на Windows XP SP3 модуль обработки GPP ставится как обновление.
Разворачиваем LAPS
Этот шаг не нужен, если Вы будете ставить Local Administrator Password Solution на, допустим, Windows Server 2012 R2 – но в большинстве инфраструктур на DC всё же используются не самые топовые ОС, поэтому данный шаг потребуется. LAPS же, повторюсь, будет работать одинаково и на Windows Server 2008 R2, и на Windows Server 2003.
Загружаем нужное
LAPS версии 6.1: отсюда. Из компонентов нам понадобятся оба дистрибутива LAPS – что для x86, что для x64 систем – они равнозначны, но, скорее всего, понадобятся оба – исключение составит лишь инфраструктура, где или только 32х битовые системы, или только 64х битовые – а это случай довольно-таки редкий.
WMF версии 4.0 (я ставлю именно её как самую последнюю из RTM-версий на момент написания статьи – а так, грамотный администратор в принципе должен заранее упростить себе работу, обновляя WMF на серверах со старыми версиями ОС): отсюда. В результате у нас будет что-то такое:
ОК, теперь начнём установку.
Ставим LAPS на рабочее место администратора
Первым делом нам надо установить полновесный комплект LAPS на рабочее место администратора. Часть операций (например, расширение схемы и выгрузка в общее хранилище политик) будет делаться разово и больше не потребуется – ну а, допустим, установка “толстого” GUI-клиента может проводиться там, где удобно. Так как я ставлю LAPS прямо на DC, я не буду устанавливать компонент AdmPwd GPO Extension – здесь он не нужен. В случае, если бы шла установка на обычную клиентскую ОС, развёрнутую на рабочей станции инженера, который будет заниматься LAPS, данный компонент бы понадобился, чтобы управлять паролем локального администратора на данной системе.
Далее установка тривиальна, а после неё я установлю WMF 4.0 и можно переходить к подготовке Active Directory.
Расширяем схему для LAPS
По итогам этой операции в схеме Active Directory появятся два новых атрибута:
Как видно, они простые в плане используемых типов и настроек – индексация на GC отключена (включать её не надо, вам же не нужна возможность поиска по тексту паролей, которые хранятся в открытом виде). Также можно увидеть, что данные атрибуты добавлены к классу computer:
Подготовка схемы завершена – ну, разве что можете дописать комментарии к этим атрибутам, но это уже никак не повлияет на работу.
Теперь, после завершения подготовки леса Active Directory, перейдём к подготовке на уровне домена.
Подготовка домена для LAPS GPO
LAPS, для управления настройками на конкретных рабочих станциях/серверах или их группах устанавливает свои GPT (Group Policy Template). Он устанавливает их в свой каталог – чтобы они стали доступны сразу во всём домене, вынесем их в Central Storage – чтобы любой администратор, который может редактировать групповые политики, с любой точки домена видел эти настройки. Microsoft в официальной документации предлагает просто бросить эти шаблоны там, куда их по дефолту кидает инсталлятор – это неправильный шаг, не имеет смысла не пользоваться централизованным хранилищем Central Storage, оно лишь упрощает административные задачи. Мы сделаем правильно.
Находим шаблоны LAPS GPT:
Не забудем, что нужен ещё и языковый файл – который AdmPwd.adml и лежит в подпапке en-us. Переносим их оба, сохраняя структуру хранения, в центральное хранилище политик нашего домена:
И проверяем, что всё корректно работает:
ОК, вопрос с политиками решили. Перейдём к специфике работы с RODC.
Подготовка для работы с LAPS RODC
Начиная с Windows Server 2008 у нас есть Read-only DC – специальный вариант контроллера домена, применяемый для региональных офисов и прочих мест, где контроля мало, а DC нужен. Ключевая специфика RODC будет в том, что он держит на себе копии разделов Active Directory, но не может в них писать (поэтому с него и репликация не нужна, ничего нового на нём появиться не может), но копии эти не только read-only – они ещё и не полные. В них отсутствует та информация, которую небезопасно держать в месте, куда возможен НСД. Изначально к этой информации относится достаточно очевидный комплект данных – например, пароли учётных записей, входящие в явно указанные группы. Но список не ограничивается паролями – также в него входят некоторые данные PKI, Bitlocker, а в нашем случае, раз мы начали использовать LAPS, этот комплект будет расширен автоматически. Ведь логично, что если мы боимся хранить на RODC хэши паролей, то реплицировать туда пароли локальных администраторов в открытом виде как-то странно.
Давайте убедимся, что всё ОК. Для этого откроем ADSI и зацепимся за раздел схемы:
А после найдём атрибут ms-Mcs-AdmPwd:
ОК, теперь перейдём к защите наших данных от тех пользователей Active Directory, которым необязательно знать пароли локальных администраторов на разных рабочих станциях и серверах.
Защищаем хранение паролей в Active Directory
Мы добавили новый атрибут – и он, как положено, доступен каждому на чтение. У всех пользователей есть право Read All Properties – так повелось с древних времён, когда ещё были гибридные структуры Active Directory + NT 4.0. Microsoft предлагает самурайский способ – запретить всем пользователям читать все расширенные атрибуты. Вообще. Что ж, вариант фиговый – из-за установки одной административной утилиты, не глядя на другое использующееся ПО, глобально зарубить всё. Это неправильно, мы сделаем тоньше – запретим целевым security principal’ам только чтение и запись данных атрибутов, не затрагивая другие.
Для этого создаём группу с очевидным названием (вы, конечно, придумаете благозвучнее и в стиле локальной системы именования групп в вашем домене):
В эту группу вы после добавите тех участников, которым в явном виде не нужно работать с данными о паролях администраторов – например, используя группы сотрудников по отделам, или как-то ещё – зависит от вашей Active Directory. Теперь укажем, что на новорожденных учётных записях компьютеров эта группа сразу имеет данный запрет, для этого откроем редактор схемы (у кого в mmc / Add Snap-Ins его нет – просто выполните от локального администратора команду regsvr32 schmmgmt.dll ) и выберем Default ACL у объекта computer:
Не забудьте снять все прочие разрешения у данной группы – это кнопкой Clear All на первой и на второй вкладках. Соответственно, если хотите ещё более гранулярную раздачу прав на атрибуты – можете сделать две группы, одной запретить просмотр, а другой, например, запись. По аналогии.
На уже существующих учётных записях рабочих станций и серверов надо также будет выставить эту ACE – как это сделать, выбирайте сами – или, если у вас хорошо прописанная структура OU в Active Directory, просто унаследовать её на определённый тип объектов с корневых контейнеров, или как-то ещё. Ключевое в этой задаче – обычный пользователь, имеющий стандартные права на чтение всех объектов, не должен иметь возможность читать данный атрибут.
Теперь выдадим компьютерной учётной записи нужные для реализации механизма LAPS права на саму себя. Это нужно затем, чтобы работающий от локальной системной учётной записи сервис, который сработает на применении групповой политики, смог бы работать с парольными атрибутами в Active Directory. Так как локальный сервис будет имперсонироваться в учётную запись рабочей станции / сервера в Active Directory, то нам надо будет в том же редакторе схемы найти ACE про SELF и там добавить право на работу с данными атрибутами:
Следующий шаг – раздать права тем, кто будет администрировать эти пароли локальных администраторов. А то мы пользователям обычным доступ выключили, компьютерам для применения политик включили, а бедный админ, поставивший GUI-клиента LAPS, остался в стороне.
В общем всё – теперь перейдём к настройке политик.
Настраиваем политики LAPS для рабочих станций и member-серверов
Политик немного, всего 4, пробежимся по ним, т.к. не все они очевидны в плане настроек.
Enable local admin password management
Это – включение локального клиента LAPS, являющегося CSE. Тут всё просто – если не включен, но установлен, то работать не будет – надо и установить, и включить.
Password Settings
Настройки сложности пароля и времени автоматической замены. В общем, тут ничего волшебного – всё это же есть и при работе с обычными паролями.
Name of administrator account to manage
Здесь уже интереснее. Если вы используете LAPS для управления учёткой встроенного админа – то этот параметр вам не пригодится, система сама поймёт, про что речь. Но LAPS может также использоваться и для управления другими учётными записями с правами локального администратора. То есть вы можете, например, через стандартные политики переименовать встроенного админа на всех серверах и рабочих станциях, выдать ему разово какой-нибудь специфичный пароль символов в 40, а потом его выключить – и после завести другую учётку для локального администрирования, и вот уже ей раздавать пароль через LAPS. Это неплохой вариант, поскольку всё же права встроенной учётки администратора чуть выше, чем произвольной из группы BUILTIN\Administrators – и создание специфичной не-встроенной учётки локального админа – хороший ход с точки зрения безопасности.
Do not allow password expiration time longer than required by policy
Это специфичная настройка, нужная для разрешения конфликта – когда в Password Settings установлено одно время смены пароля, а вручную в атрибуте ms-Mcs-AdmPwdExpirationTime – другое. Если эту настройку включить, пароль будет автоматически сменён в случае наступления любого из этих двух сроков – искусственно продлить время жизни не получится.
Ну а теперь, в принципе, самое простое – развёртывание клиента LAPS.
Развёртываем LAPS для клиентов – рабочих станций и member-серверов
Это несложно и не требует дополнительного ПО – всё, что нужно – создать новую групповую политику, добавить в неё MSI-модуль LAPS (учитывая битовость целевых систем), назначить его установку от имени компьютера, и нацелить эту политику на нужную группу хостов. Выглядеть это будет примерно так:
Отключаем для ускорения применения юзерскую часть – там настроек все равно нет:
Выкладываем msi-файлы для LAPS на общедоступный сетевой ресурс, чтобы клиенты могли их оттуда забирать – я выложу прямо в SYSVOL, предполагая, что данная утилита будет использоваться по всей организации – вы же можете сделать отдельную distribution point с использованием DFS и адресно прописать и схему репликации, и потребление полосы пропускания, и всё другое нужное и необходимое – а после выкладывания назначаем (Assign) на раздачу для компьютеров, подпавших под эту политику:
Можно и более автоматизированно – добавить в политику WMI-фильтр, который ограничит её применение 64х битовыми системами:
Замечу, что атрибут OSArchitecture класса Win32_OperatingSystem будет только у NT 6.0 и выше – однако, системы на базе Windows XP мы не учитываем; если же нужно устанавливать LAPS на много разных Windows Server 2003, которые NT 5.2 и могут быть и x86, и x86-64, то можно воспользоваться анализом атрибута AddressWidth у класса Win32_Processor:
Это менее точный параметр, т.к. на систему с 64х битовым процессором может быть установлена 32х битовая ОС.
Вот так будет в результате выглядеть наша финальная политика:
В этом случае можно не заводить дополнительные группы вида “все 64х битовые хосты” / “все 32х битовые хосты”, а просто назначить обе политики – и для 32х, и для 64х битовых систем – на нужные контейнеры. Группа же LAPS Workstations служит дополнительным ограничением применения – в неё можно добавить, допустим, Domain Computers, в случае массового развёртывания, а можно и security-группы по отделам предприятия, например.
Вкратце всё. Теперь LAPS можно штатно использовать – после применения политик и установки модуля пароли автоматически сгенерятся и попадут в Active Directory. Как запустить утилиту администрирования (она установится и будет в меню) и нажимать там обе функциональные кнопки Set и Search – думаю, не требует доп. пояснений. 🙂
Напоследок
В итоге мы имеем хороший и надёжный механизм автоматизации одной из админских задач – потому что пароли локальных администраторов все равно есть и управлять ими как-то надо. Теперь это ощутимо проще и безопаснее.