Как изменить пароль локального администратора через групповые политики

Обновлено 21.05.2021

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В минувшей статье я вам подробно осветил методы «как разархивировать файл» в операционных системах Windows или Linux. Сегодня я вам хочу показать очень удобный скрипт на PowerShell. который позволит вам изменить пароль локальной учетной записи на компьютерах в домене Active Directory. Уверен, что данная задача. хоть раз в год у вас и появляется. а по правильному лучше это проделывать хотя бы раз в пол года, в целях повышения безопасности.

Задача по смене пароля локального администратора в домене

Представим простую ситуацию. У вас есть домен Active Directory в котором 50 и более компьютеров. На каждом из них есть локальная учетная запись администратора, используется она чаще всего для второй линии, чтобы производить обслуживание рабочих станций. Вам потребовалось сменить пароль для учетной записи «Администратор», как быть, вы же не будите бегать и ручками все менять.

Ранее во времена Windows Server 2008R2, можно было легко обновить пароль локального администратора с помощью групповых политик, я об этом рассказывал, но в следующих версиях Windows Server 2012 R2 и выше, уже данная опция не доступна, кнопки просто неактивны.

Не знаю, с какой целью Microsoft убрала данную возможность, очень странный ход, поэтому пойдем другим путем. Мы напишем простой скрипт на PowerShell, который возьмет список DNS-имен серверов и на каждом из них он поменяет пароль для нужной нам локальной учетной записи.

Скрипт PowerShell по изменению пароля локальной учетной записи на удаленном компьютере

Для того, чтобы наш скрипт нормально отработал нам нужно выполнить некоторые требования:

1. Иметь права администратора на том компьютере, где будет изменяться пароль для локальной учетной записи, я уверен, что вы все доменные администраторы
2. Выяснить версию PowerShell, так как я приведу два варианта скрипта по изменению пароля, и тут нужно понимать, какой командлет поддерживает ваша версия.
3. Подготовить список с именами серверов и сформировать текстовый файл, по идее все.

Подготовка файла со списком серверов

Давайте я покажу формат и структуру файла, в котором будет содержаться список наших серверов. Создайте обычный txt файл и задайте ему имя. у меня пусть будет comps.txt. Далее скопируйте в него список ваших FQDN имен серверов, ОДНА СТРОКА — ОДНО имя.

Скрипт для массовой смены пароля у локального администратора для PowerShell 5.1 и ниже

Я уверен, что на серверах из списка вы администратор. Я для примера буду производить смену пароля у локальной учетной записи «Администратор«, хотя по хорошему вы ее должны переименовать или отключить вообще, создав другую. Откройте PowerShell ISE и скопируйте скрипт.

Можно использовать еще вот такой вариант для списка:

Или вариант для одного компьютера

Скрипт для массовой смены пароля у локального администратора для PowerShell 5.1 и выше

В Windows 10 build 1607 и выше, новый Powershell 5.1 представил Set-LocalUserкомандлет. Вы можете использовать его для этой задачи вместо адаптера ADSI, но для этого требуется, чтобы на удаленных компьютерах была включена служба удаленного взаимодействия Powershell (которая по умолчанию отключена). Чтобы разрешить прием удаленных команд, вам необходимо запустить run Enable-PSRemotingв терминале Powershell с повышенными привилегиями на удаленном компьютере.

Если удаленное взаимодействие PS включено, измененный сценарий будет выглядеть следующим образом:

• Для одного компьютера

• Для списка компьютеров

На этом у меня все, как говорится нет пределу совершенства. и вы можете написать куда лучше и поделиться со мной и читателями. С вами был Иван Семин. автор и создатель IT портала Pyatilistnik.org.

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

Как известно для увеличения уровня безопасности требуется периодически менять пароли, опять же менять пароль локального администратора на каждой рабочей станции физически дело трудозатратное, а следовательно нужно этот процесс упростить, в чем опять же поможет групповая политика!!!

Данный скрипт выполняет поиск учетной записи локального администратора и присваивает ей заданный пароль

On Error Resume Next

strPasswd = «НОВЫЙ ПАРОЛЬ»

Set Network = WScript.CreateObject («WScript.Network»)

Set objWMIService = GetObject («winmgmts:\.rootCIMV2»)

strServer = Network.ComputerName

strWQLquery = «SELECT * FROM Win32_UserAccount WHERE domain = ‘» & strServer & «’»

Set colAllSysUsers = objWMIService.ExecQuery ( strWQLquery )

For Each User In colAllSysUsers

RID = Right ( User.SID ,3)

If RID = «500» Then

Set objUser = GetObject («WinNT://» & strServer & «/» & User.Name & «,user»)

objUser.Setpassword strPasswd

objUser.SetInfo

Exit For

End If

Next

Следует внимательно отнестись к тому, что в скрипте открыто указан пароль, после того как пароль присвоился ко все компьютерам следует данный файл удалить!!! Более безопасно будет его зашифровать, но это уже тема для другого урока.

Сохраняем файл с расширением new_password.vbs и добавляем его в автозапуск в групповой политике (Конфигурация компьютера – Конфигурация Windows – Сценарии – Автозагрузка).

Жмем на кнопку показать файлы, и откроется сетевой ресурс из которого будут запускаться скрипты. Копируем туда наш файл со скриптом new_password.vbs. Теперь жмем на Добавить и добавляем файл из появившегося окна.

В данной ситуации требуется применить данную политику только к компьютерам домена, так как пароль локального администратора и администратора домена должны быть различны!!!

Вот и готово! Теперь, после применения политики, на всех компьютерах данного контейнера логин и пароль локального администратора будут едины.

Так же как и в случае с переименование учетной записи, программы которые запускаются по заданию от имени администратора могут не запуститься, если имя пользователя и пароль задается фактически вводом в окно запускать от имени пользователя и пароля

Скачать видеоурок и инструкцию

Привет.

Управление локальными паролями администраторов на доменных машинах – достаточно древняя и до сих пор актуальная задача.

Ведь по сути, жизненный цикл учётной записи администратора, в плане продолжительности, равен жизненному циклу рабочей станции – поэтому задачи защиты этой учётной записи от НСД, периодической смены пароля на известный IT-отделу (чтобы можно было проводить в случае форс-мажора какие-либо нужные действия), отслеживание нецелевого использования (как локального, так и удалённого – ведь знающий этот пароль в обычной ситуации может удалённо подключаться к системе и проводить различные действия) – все эти и множество других, более мелких, но нужных задач – они отнимают много времени и снижают общий уровень безопасности домена.

Обычно используются различные ухищрения и их комбинации, чтобы упростить эту ситуацию. Например:

• Централизованно переименовать учётную запись локального администратора на рабочих станциях
• Отключить её (хотя всё равно при входе в Safe Mode она автоматически включается)
• Поставить на logon script что-то сигнализирующее о входе локальным администратром и ввести за это кары
• Придумать огромный и сложный пароль (вариант – написать скрипт, который обходит workstations и member servers в Active Directory и меняет там, используя специальную техническую доменную учётку, пароль локальной учётной записи администратора, отписывая в отдельный файлик новый пароль или, в случае неудачи операции, код ошибки)
• Варварский метод, который я в своё время очень любил – физически удалить учётную запись локального администратора из SAM и переименовать гостя в админа – тогда взломавший эту учётную запись пользователь будет долго медитировать над странными околонулевыми правами на системе

Все эти варианты чем-то снижают проблематику, но не убирают её. Организовывать сложную систему постоянного мониторинга за статусом этой учётной записи, не отредактировали ли её, не зашли ли ей, не запустили ли что-то от неё – трудоёмко и опять-таки не спасает от всех ситуаций НСД – например от того, что продвинутый пользователь скачает утилиту, которая позволит на загрузке сбросить пароль локального админа. Но задачи управления этой учётной записью и безопасного и автоматического обновления её пароля всё ж решаемы.

Начиная с NT 6.0 у вас появились Group Policy Preferences, которые тоже могут помочь в этом деле:

Но неприятность в том, что данный пароль будет лежать в легковосстановимом виде в папке SYSVOL, вместе с остальными данными GPP. Так что проблемы остаются.

Эти вопросы – и некоторые другие – можно решать более цивилизованным способом – используя LAPS.

Давайте разберёмся. Я предполагаю, что вы знаете вопросы работы Active Directory хотя бы на уровне простенького бесплатного курса Microsoft 20410D, поэтому в отдельные совсем уж тривиальные детали углубляться не буду.

Использование LAPS (Local Administrator Password Solution)

• Что умеет LAPS
• Разворачиваем LAPS по шагам
• Ставим LAPS на рабочее место администратора
• Расширяем схему для LAPS
• Подготовка домена для LAPS GPO
• Подготовка для работы с LAPS RODC
• Защищаем хранение паролей в Active Directory
• Настраиваем политики LAPS для рабочих станций и member-серверов
• Развёртываем LAPS для клиентов – рабочих станций и member-серверов

Начнём.

Что умеет LAPS

Local Administrator Password Solution представляет из себя сочетание:

• Локально устанавливаемого на управляемых рабочих станциях (и серверах, замечу) ПО, которое, по сути, добавляет ещё один компонент к Group Policy Client Side Extension;
• Расширения схемы Active Directory (два новых атрибута для класса computer, нужные для хранения паролей локальных администраторов и некоторых доп.атрибутов);
• Дополнительных административных шаблонов для групповых политик;
• Модуля PowerShell для автоматизации всех задач управления LAPS;
• Утилиту для управления через GUI;

Всё это позволяет:

• Безопасно хранить в Active Directory пароль локального администратора для каждой рабочей станции (а также member server’ов)
• Устанавливать правила для пароля (длину, критерий сложности)
• Менять пароль локального администратора через Active Directory, без необходимости прямого подключения к целевой системе – при этом делать это безопасно, в рамках применения групповых политик, по защищённому каналу
• Устанавливать срок истечения времени действия пароля локального администратора и автоматически менять его (безусловно, и на локальной машине, и в Active Directory)

Работать всё это будет на инфраструктуре, построенной на DC уровня Windows Server 2003 и выше, и управлять паролями на системах, построенных на базе серверной ОС Windows Server 2003 и клиентской ОС Windows Vista. Да, XP официально не поддерживается, увы – но можно использовать приведённый выше пример с Group Policy Preferences, ведь на Windows XP SP3 модуль обработки GPP ставится как обновление.

Разворачиваем LAPS

Я буду разворачивать актуальный на июль 2015го года LAPS 6.1. Для приближенности к боевой ситуации это будет сделано на Windows Server 2008 R2 (что, впрочем, ничего не меняет в функционале LAPS) – разве что, для того, чтобы корректно отработали powershell-скрипты мне нужно будет обновить Windows Management Framework – я поставлю версию 4.0 вот отсюда: http://www.microsoft.com/en-us/download/confirmation.aspx?id=40855.

Этот шаг не нужен, если Вы будете ставить 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, данный компонент бы понадобился, чтобы управлять паролем локального администратора на данной системе.

Компоненты, которые будут установлены:

• Fat Client UI – утилита для быстрого поиска рабочей станции или member server’а по имени и просмотра/смены информации по паролю учётной записи builtin-администратора
• PowerShell Module – подгружаемый модуль для выполнения административных задач LAPS через PowerShell
• GPO Editor templates – административные шаблоны для управления настройками модуля LAPS на клиентах

Далее установка тривиальна, а после неё я установлю WMF 4.0 и можно переходить к подготовке Active Directory.

Расширяем схему для LAPS

LAPS использует два дополнительных атрибута для хранения нужных данных – это ms-Mcs-AdmPwd, который используется для хранения пароля, и ms-Mcs-AdmPwdExpirationTime, в котором будет храниться время истечения действия пароля. Эти атрибуты добавляются просто – вам необходимо будет запустить PowerShell от учётной записи, имеющей права на модификацию схемы Active Directory (обычно это участник группы Schema Admins), и сделать два действия:

1. Подгрузить модуль LAPS – командлетом Import-Module AdmPwd.PS
2. Выполнить командлет Update-AdmPwdADSchema

По итогам этой операции в схеме 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:

Нас будет интересовать значение атрибута searchFlags – это битовый массив, указывающий, как обращаться с данным атрибутом – искать ли по его значению, передавать в GC, и реплицировать ли на RODC. В нашем случае значение по умолчанию будет 0x388 – это сумма флагов PRESERVE_ON_DELETE, CONFIDENTIAL, NEVER_AUDIT_VALUE, RODC_FILTERED. Мы видим, что нужные нам атрибуты – CONFIDENTIAL (это 7й бит) и RODC_FILTERED (это 10й) выставлены правильно, т.е. доступ к атрибуту будет ограничен и реплицироваться на RODC он не будет. Всё ОК. Кстати, как понятно, Вы можете аналогичным образом защитить любой нужный атрибут, который не нужен на RODC – допустим, какой-то добавленный Вами вручную и содержащий приватную информацию. Атрибут будет по прежнему доступен, но не будет храниться на RODC – поэтому злонамеренные товарищи, ночью выкрутившие жёсткий диск из RODC и сделавшие его полную копию, при просмотре ntds.dit ничего не увидят.

ОК, теперь перейдём к защите наших данных от тех пользователей 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 и там добавить право на работу с данными атрибутами:

Опять-таки – то же самое нужно проделать со всеми уже существующими учётными записями компьютеров/рабочих станций – LAPS в этом плане может предложить лишь частичную автоматизацию путём запуска на контейнере с компьютерами командлета Set-AdmPwdComputerSelfPermission -OrgUnit имя_контейнера, который добавит данную строчку и включит её наследование на нужный тип child object’ов. Как именно вы это сделаете – некритично, цель – разрешить компьютеру от себя лично работать с данными атрибутами своей же учётки в Active Directory.

Следующий шаг – раздать права тем, кто будет администрировать эти пароли локальных администраторов. А то мы пользователям обычным доступ выключили, компьютерам для применения политик включили, а бедный админ, поставивший GUI-клиента LAPS, остался в стороне.

Снова действуем по аналогии – создаём группу с именем вида “Builtin Administrators password management”, добавляем в неё нужных участников и выдаём этой группе право на доступ к атрибуту с паролем – который ms-Mcs-AdmPwd. Скриншоты не делаю, т.к. всё абсолютно по аналогии с предыдущими действиями – и в PowerShell-модуле LAPS опять же есть на этот счёт командлет, упрощающий работу: Set-AdmPwdReadPasswordPermission -OrgUnit контейнер_в_котором_компьютеры -AllowedPrincipals наша_группа_тех_кто_имеет_право_сбрасывать_на_этих_компьютерах_пароль_локального_админа. Как и в предыдущих действиях – не забудьте, пожалуйста, добавить эти же права в Default ACL компьютерной учётной записи – Microsoft это забывает сделать.

Для второго атрибута – который ms-Mcs-AdmPwdExpirationTime – делаем аналогичное действие, права на него нужны тем, кто будет сбрасывать пароли (по сути, этот процесс будет состоять в изменении срока действия, чтобы система сама изменила пароль). Командлет будет чуть другой по названию – Set-AdmPwdResetPasswordPermission, параметры у него будут те же.

В общем всё – теперь перейдём к настройке политик.

Настраиваем политики LAPS для рабочих станций и member-серверов

Политик немного, всего 4, пробежимся по ним, т.к. не все они очевидны в плане настроек.

Enable local admin password management

Это – включение локального клиента LAPS, являющегося CSE. Тут всё просто – если не включен, но установлен, то работать не будет – надо и установить, и включить.

Password Settings

Настройки сложности пароля и времени автоматической замены. В общем, тут ничего волшебного – всё это же есть и при работе с обычными паролями.

Name of administrator account to manage

Здесь уже интереснее. Если вы используете LAPS для управления учёткой встроенного админа – то этот параметр вам не пригодится, система сама поймёт, про что речь. Но LAPS может также использоваться и для управления другими учётными записями с правами локального администратора. То есть вы можете, например, через стандартные политики переименовать встроенного админа на всех серверах и рабочих станциях, выдать ему разово какой-нибудь специфичный пароль символов в 40, а потом его выключить – и после завести другую учётку для локального администрирования, и вот уже ей раздавать пароль через LAPS. Это неплохой вариант, поскольку всё же права встроенной учётки администратора чуть выше, чем произвольной из группы BUILTINAdministrators – и создание специфичной не-встроенной учётки локального админа – хороший ход с точки зрения безопасности.

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 – думаю, не требует доп. пояснений.

Напоследок

В итоге мы имеем хороший и надёжный механизм автоматизации одной из админских задач – потому что пароли локальных администраторов все равно есть и управлять ими как-то надо. Теперь это ощутимо проще и безопаснее.

Удачного применения!