MS Local Administrator Password Solution – управление паролями локальных администраторов в домене | Windows для системных администраторов

MS Local Administrator Password Solution – управление паролями локальных администраторов в домене

Вопрос управления встроенными учетными записям на компьютерах домена является одним из важнейших аспектов безопасности, требующих внимание системного администратора. Безусловно, не стоит допускать использования одинаковых паролей локальных администраторов на всех компьютерах . Есть множество подходов к организации управления учетными записями локальных администраторов в домене: начиная от полного их отключения (не очень удобно), до управления через logon скрипты групповых политик и создания собственных систем управления встроенными учётками и их паролями.

Ранее одним из популярных средств изменения паролей локальный администраторов на ПК являлось возможность расширений групповых политик (GPP – Group Policy Preferences), однако в этой системе была найдена серьезная уязвимость, позволяющая любому пользователю расшифровать пароль (об это мы подробно говорили в статье (Почему не стоит задавать пароли через Group Policy Preferences). В мае 2014 года Microsoft выпустила обновление безопасности (MS14-025 – KB 2962486), полностью отключающее возможность задать пароль локального пользователя через GPP.

Сегодня мы подробно рассмотрим одну из методик, позволяющих организовать управления паролями локальных администраторов в домене. Речь идет об утилите AdmPwd (новое название LAPS — Local admin password management solution).

Утилита Local Administrator Password Solution (LAPS)


Важно. Ранее утилита не была официальной и называлась AdmPwd. В момент написания статьи Microsoft (май 2015) анонсировала официальную версию AdmPwd, переведя ее из раздела сторонних скриптов в официально поддерживаемое решение. Теперь AdmPwd официально называется LAPS (Local Administrator Password Solution).

Утилита LAPS позволяет организовать решение по централизованному контролю и управлению паролями администраторов на всех компьютерах домена с хранением информации о пароле непосредственно в объектах Active Directory типа Computer.

Функционал LAPS основан на технологии Group Policy Client Side Extension (CSE) и заключается в генерации и установки уникального пароля локального администратора (SID — 500) на каждом компьютере домена. Пароль автоматически меняется через определенный интервал времени (по-умолчанию, каждые 30 дней). Значение текущего пароля хранится в конфиденциальном атрибуте учетных записей компьютеров в Active Directory, доступ на просмотр содержимого атрибута регулируется группами безопасности AD.

Скачать LAPS и документацию к ней можно с этой страницы: https://www.microsoft.com/en-us/download/details.aspx?id=46899

Дистрибутив LAPS доступен в виде двух версии установочных msi файдлв: для 32 (LAPS.x86.msi) и 64 (LAPS.x64.msi) битных систем.

Инструментарий управления устанавливается на машине администратора, а на серверах и ПК, на которых мы планируем управлять паролем локального администратора, устанавливается клиентская часть.

Совет. Перед развертыванием полного решения LAPS рекомендуем провести его апробацию в тестовой среде, имитирующую продуктив, т.к. как минимум потребуется расширение схемы AD (необратимое).

Установка LAPS

Запускаем установку утилиты на машине администратора, отметив все компоненты для установки (требуется наличие как минимум .Net Framework 4.0). Пакет состоит из двух подсистем:

  1. AdmPwd GPO Extension – собственно исполняемая часть LAPS
  2. И компоненты управления:
    • Fat client UI – утилита для просмотра пароля
    • PowerShell module – модуль Powershell для управления LAPS
    • GPO Editor templates – административные шаблоны для редактора групповой политики

Параметры установки LAPSУстановка LAPS максимально простая и не должна вызывать каких-либо проблем.

Подготовка Active Directory


Перед разворачиванием инфраструктуры LAPS необходимо расширить схему Active Directory, в которую будут добавлены два новых атрибута для объектов типа компьютер.

ms-MCS-AdmPwd– атрибут содержит пароль локального администратора в открытом виде

ms-MCS-AdmPwdExpirationTime: — дата истечения срока действия пароля

Для расширения схемы, нужно открыть консоль PowerShell, импортировать модуль Admpwd.ps:

Import-module AdmPwd.ps

Import-module AdmPwd.psИ выполнить расширение схемы Active Directory (нужны права Schema Admin):

Update-AdmPwdADSchema Update-AdmPwdADSchema  - расширение схемы

В результате в класс «Computer» будут добавлены два новых атрибута.

Наводим порядок с правами на атрибуты

Пароль администратора будет хранится в атрибутах Active Directory в открытом виде, доступ к нему ограничивается благодаря механизму конфиденциальных атрибутов AD (поддерживается с Windows 2003). Атрибут ms-MCS-AdmPwd, в котором хранится пароль, может быть прочитан любым обладателем разрешения «All Extended Rights«. Пользователи и группы с этим разрешением могут читать любые конфиденциальные атрибуты, в том числе ms-MCS-AdmPwd. Т.к. мы не хотим, чтобы кто-то кроме администраторов домена (или служб HelpDesk) имел право на просмотр паролей компьютеров, нам нужно ограничить список групп с правами на чтение этих атрибутов.

С помощью командлета Find-AdmPwdExtendedRights можно получить список учетных записей и групп, обладающих этим правом на конкретную OU. К примеру, проверим, кто обладает подобными разрешениями на OU с именем Desktops:

Find-AdmPwdExtendedRights -Identity Desktops | Format-Table ExtendedRightHolders

Find-AdmPwdExtendedRightsКак мы видим, право на чтение конфиденциальных атрибутов есть только у группы Domain Admins.

В том случае, если нужно запретить определенным группам или пользователям доступ на чтение таких атрибутов, нужно выполнить следующее:

Совет. Ограничить права на чтение придется на все OU, паролями компьютеров в которых будет управлять LAPS.
  1. Откройте ADSIEdit и подключитесь к Default naming context.ADSIEdit connect Default Naming Context
  2. Разворачиваем дерево, находим нужный OU (в нашем примере Desktops) и щелкнем по нему ПКМ и выбираем PropertiesСвойства OU
  3. Затем переходим на вкладку Security, нажимаем на кнопку Advanced. Затем нажав на кнопку Add, в разделе Select Principal укажите имя группы/пользователя, для которого нужно ограничить права (например, domain\Support Team).Отключаем All extended rights
  4. Снимаем галку у права All extended rights и сохраняем изменения.

Аналогичным образом нужно поступить со всеми группам, которым нужно запретить право на просмотр пароля.

Назначаем разрешения для компьютеров

Далее нужно дать права учетным записям машин на модификацию собственных атрибутов (SELF), т.к. изменение значений атрибутов ms-MCS-AdmPwd и ms-MCS-AdmPwdExpirationTime выполняется из-под учетной записи самого компьютера. Воспользуемся еще одним командлетом Set-AdmPwdComputerSelfPermission.

Чтобы дать права компьютерам в OU Desktops на обновление расширенных атрибутов, выполним команду:

Set-AdmPwdComputerSelfPermission -OrgUnit Desktops

Set-AdmPwdComputerSelfPermission

Назначаем права пользователям

Следующий этап – предоставление прав пользователям и группам на чтение хранящихся в Active Directory паролей на локальные учетные записи администраторов компьютеров домена. К примеру, мы хотим дать членам группе AdmPwd права на чтение паролей:

Set-AdmPwdReadPasswordPermission -OrgUnit Desktops -AllowedPrincipals AdmPwd

Set-AdmPwdReadPasswordPermissionКроме того, можно отдельной группе пользователей предоставить право на сброс пароля компьютеров (в нашем примере мы предоставляем это право той же группе AdmPwd)

Set-AdmPwdResetPasswordPermission -OrgUnit Desktops -AllowedPrincipals AdmPwd
Set-AdmPwdComputerSelfPermission

Настройка групповой политики LAPS

Далее нужно создать новый объект GPO (групповых политик) и назначить его на OU, в которой содержатся компьютеры, на которых мы хотим управлять паролями локальных администраторов.

Создадим политику с именем Password_Administrador_Local следующей командой:

Register-AdmPwdWithGPO -GpoIdentity: Password_Administrador_Local

Register-AdmPwdWithGPOОткроем на редактирование созданную политику и настроим ее. Для чего перейдём в раздел GPO: Computer Configuration -> Administrative Templates -> LAPS

LAPS параметры GPOКак мы видим, имеются 4 настраиваемых параметра. Настраиваем их следующим образом

  • Enable local admin password managementEnabled
  • Password SettingsEnabled – в политике задается сложности пароля, его длину и частота изменения
    • Complexity: Large letters, small letters, numbers, specials
    • Length: 12 characters
    • Age: 30 days
  • Name of administrator account to manageNot Configured (по умолчанию меняется пароль пользователя с SID -500)
  • Do not allow password expiration time longer than required by policyEnabled

Политика управления паролями

Назначим политику Password_Administrador_Local на OU Desktops.

Установка LAPS на клиентские компьютеры

После настройки GPO настала очередь установить LAPS на клиентские компьютеры. Распространить клиент LAPS можно различными спрособами: вручную, через задание SCCM , логон скрипт и т.п. В нашем примере мы установим msi файл с помощью возможности установки msi пакетов через групповые политики (GPSI).

  1. Создадим на сетевом каталоге общую папку, в которую нужно скопировать дистрибутивы LAPS
  2. Создадим новую политику и в разделе Computer Configuration ->Policies ->Software Settings -> Software Installation создадим задание на установку пакета

Установка LAPS.msi через GPOОсталось назначить политику на нужную OU, и после перезагрузки, на всех компьютерах в целевом OU должен установиться клиент LAPS .

Удостоверимся, что в списке установленных программ Панели Управления (Programs and Features) появилась запись Local admin password management solution

Local admin password management solutionПри смене пароля администратора утилитой LAPS запись об этом фиксируется в журнале Application (Event ID:12, Source: AdmPwd).

Event ID:12, Source: AdmPwdСобытие сохранения пароля в атрибуте AD также фиксируется (Event ID:13, Source: AdmPwd).

Event ID:13, Source: AdmPwdВот так выглядят новые атрибуты у объектов типа компьютер.

Атрибут ms-MCS-AdmPwd и значени пароля администратора компьютера

Совет. Время истечения срока действия пароля хранится в формате «Win32 FILETIME», сконвертировать его в нормальный вид можно, к примеру так

Использование утилиты LAPS для просмотра паролей

Графический интерфейс (GUI) LAPS необходимо установить на компьютерах администраторов.

admpwduiЗапустив утилиту, и указав имя компьютера (в поле computername), можно посмотреть пароль и срок действия пароля учетной записи локального администратора данного компьютера.

LAPS-UI - утилита получения пароля компьютераДату истечения пароля срока действия пароля можно задать вручную, либо оставить поле с датой пустым и нажав кнопку Set, установить что пароль срок действия пароля уже истек.

Пароль также можно получить с помощью PowerShell:

Get-AdmPwdPassword -ComputerName <computername>

Get-AdmPwdPasswordLAPS (AdmPwd) можно рекомендовать как удобное в управлении решение для организации системы управления паролями на компьютерах домена с возможностью гранулированного управления доступом к паролям компьютеров из разных OU. Пароли хранятся в атрибутах Active Directory в открытом виде, однако встроенные средства AD позволяют ограничить к ним доступ.

Еще записи по теме: Group Policy
Понравилась статья? Скажи спасибо и расскажи друзьям!
Назад:
Вперед:

Комментариев: 19

Оставить комментарий
  1. Denis | 28.05.2015

    А вы из под какой винды LAPS ставили ?
    Пробовал на 10TP и на Win8x64 — в обоих случаях не удается импортировать модуль AdmPwd.ps. Пишет Не был загружен….

    Ответить
    • itpro | 28.05.2015

      Тестировал на Windows 2012 R2 + Windows 8.1. Попробуйте указать полный путь к модулю AdmPwd.ps.

      Ответить
      • Denis | 28.05.2015

        Спасибо. Не помогло. А битность-то какая у ваших «тестовых» систем? Может-быть у меня на х64 не идет…

        Ответить
        • itpro | 28.05.2015

          64-битные…
          Приведите полный текст ошибки… и посмотрите какую версию Powershell используете (_http://winitpro.ru/index.php/2013/06/26/pereklyuchenie-mezhdu-versiyami-powershell/)?
          У меня 3.0

          Ответить
  2. Denis | 02.06.2015

    Разобрался с установкой и импортом модуля, но возникла проблема на этапе создания политики.
    Дело в том, что Register-AdmPwdWithGPO -GpoIdentity: Password_Administrador_Local не выполняется, т.к. Register_AdmWithGPO не распознано как имя командлета, функции, файла сценария или выполняемой программы.
    По запросу: Get-Help AdmPwd в списке, Register_AdmWithGPO тоже нет.
    У меня в наличии только:
    Find-AdmPwdExtendedRights
    Get-AdmPwdPassword
    Reset-AdmPwdPassword
    Set-AdmPwdAuditing
    Set-AdmPwdComputerSelfPermission
    Set-AdmPwdReadPasswordPermission
    Set-AdmPwdResetPasswordPermission
    Update-AdmPwdADSchema

    В офф источнике написано, что Register — теперь удалили, за ненадобностью. Апдейт скрипта был от 1 января 2015 года. И теперь все это происходит в момент апдейта схемы. Но в GPO я так и не увидел желаемого шаблона. Да и статья Ваша написана гораздо позже, ем 1 января. Помогите пожалуйста.

    Ответить
    • Denis | 02.06.2015

      Установил на DC отдельно шаблоны из инсталятора.
      Спасибо.

      Ответить
  3. Denis | 02.06.2015

    Установил шаблоны на DC Из инсталлятора.
    Спасибо!

    Ответить
  4. Denis | 02.06.2015

    Со всем разобрался. Установил — работает! Спасибо, за статью!

    Ответить
  5. Ксюша | 29.09.2015

    Добрый день!

    Отличная статья, но оставила некоторый ряд нераскрытых вопросов.

    Основной из них, что делать, если какая-либо рабочая станция вывалилась из домена?
    В этом случае вход в систему не может быть совершен и сброс пароля приходиться выполнять известными всем, но достаточно затратными по времени способами…

    Есть ли какая-либо распространенная практика на этот счет?

    Ответить
    • Denis | 29.09.2015

      Ксюша, если даже машина «вывалилась» из домена — и политика хоть раз на нем успела отработать — то пароль будет храниться в открытом виде в атрибутах этой машины. Получить вы его можете все так же без проблем, за счет LAPS утилиты. Ну а если политика не применялась — то и пароль не менялся. Вроде логично :)

      Ответить
      • Ксюша | 01.10.2015

        Да, я то же так подумала, и очень удивилась, что не подошел ни старый пароль, ни новый… Видимо где-то ошиблись с настройкой.. Только где?

        Ответить
        • Ten | 26.01.2016

          Видимо, в днк)

          Ответить
  6. Сазонов Игорь | 26.02.2016

    Здравствуйте, Дмитрий!
    При попытке импортировать модуль Admpwd.ps получаю ошибку:

    PS C:\Windows\system32> Import-module AdmPwd.ps
    Import-Module : Could not load file or assembly ‘file:///C:\Windows\system32\WindowsPowerShell\v1.0\Modules\AdmPwd.ps
    dmPwd.PS.dll’ or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime
    nd cannot be loaded.
    At line:1 char:14
    + Import-module <<<< AdmPwd.ps
    + CategoryInfo : NotSpecified: (:) [Import-Module], BadImageFormatException
    + FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerShell.Commands.ImportModuleCommand

    Windows Server 2008 R2, PowerShell 2.0

    Ответить
    • itpro | 26.02.2016

      Приветствую!
      Скорее всего нужно обновить версию PowerShell до 3.0 или выше (cкачайте и установите Windows Management Framework >= 3.0 )
      Также убедитесь, что операции изменения схемы проводится на DC с ролью мастера схемы FSMO.

      Ответить
      • Сазонов Игорь | 29.02.2016

        Да, операции изменения схемы проводится на DC с ролью мастера схемы FSMO.
        Спасибо, действительно, надо было обновить версию PowerShell до 3.0!
        Модуль Admpwd.ps импортировался успешно. ))
        Так уж сложилось, что у меня в домене все рабочие станции находятся не в OU, а в CN=Computers.
        Решил воспользоваться Вашим примером и проверить, какие пользователи и группы с разрешением «All Extended Rights» имеют право на просмотр паролей компьютеров в CN=Computers.
        Получил следующую ошибку:

        PS C:\Windows\system32> Find-AdmPwdExtendedRights -Identity Computers | Format-Table ExtendedRightHolders
        Find-AdmPwdExtendedRights : Object not found
        At line:1 char:1
        + Find-AdmPwdExtendedRights -Identity Computers | Format-Table ExtendedRightHolder …
        + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo : NotSpecified: (:) [Find-AdmPwdExtendedRights], NotFoundException
        + FullyQualifiedErrorId : AdmPwd.PSTypes.NotFoundException,AdmPwd.PS.FindExtendedRights

        Ответить
        • itpro | 01.03.2016

          Лучше все таки создать отдельную/ые OU для компьютеров и пере, возможно у LAPS есть какие то ограничения на этот счет.
          Ну или попробуйте такую команду:
          Find-AdmPwdExtendedRights -Identity «cn=Сomputers,dc=vashdomen,dc=ru» | Format-Table ExtendedRightHolders

          Ответить
          • Сазонов Игорь | 01.03.2016

            Не помогло… ((

            Ответить
            • itpro | 02.03.2016

              Может быть причина и не в использовании стандартного контейнера.
              Попробуйте создать новый OU и проверить, будет ли скрипт отображать права на эту OU.

      • Сазонов Игорь | 29.02.2016

        Сорри!
        Не увидел сразу своё новое сообщение.
        Подумал, не отправилось…
        ))

        Ответить
Полные правила комментирования на сайте winitpro.ru. Вопросы, не связанные с содержимым статьи или ее обсуждением удаляются.

Сказать Спасибо! можно на этой странице или (еще лучше) поделиться с друзями ссылкой на понравившуюся статью в любимой социальной сети(специально для этого на сайте присуствуют кнопки популярных соц. сетей).

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Я не робот( Обязательно отметьте)



MAXCACHE: 0.29MB/0.00185 sec