В этой статье мы рассмотрим способ управления паролями локальных администраторов на компьютерах домена с помощью официальной утилиты 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
- Подготовка схемы Active Directory для внедрения LAPS
- Настройка прав в AD на атрибуты LAPS
- Предоставление прав на просмотр пароля LAPS
- Настройка групповой политики LAPS
- Установка LAPS на клиентские компьютеры через GPO
- Использование утилиты LAPS для просмотра пароля администратора
Утилита 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 и документацию к ней можно с этой страницы: https://www.microsoft.com/en-us/download/details.aspx?id=46899
Дистрибутив LAPS доступен в виде двух версий установочных msi файлов: для 32 (LAPS.x86.msi) и 64 (LAPS.x64.msi) битных систем.
Архитектура LAPS состоит из 2 частей. Модуль управления устанавливается на машине администратора, а клиентская часть устанавливается на серверах и ПК, на которых нужно регулярно менять пароль локального администратора.
Запустите MSI файл утилиты на компьютере администратора, выберите все компоненты для установки (требуется наличие как минимум .Net Framework 4.0 – Как узнать какие версии .Net установлены). Пакет состоит из двух частей:
- AdmPwd GPO Extension –исполняемая часть LAPS, которая устанавливается на компьютеры клиентов и осуществляет генерацию, сохранение пароля в домене согласно настроенной политики;
- И компоненты управления LAPS (Management Tools):
- Fat client UI – утилита для просмотра пароля администратора;
- PowerShell module – модуль PowerShell для управления LAPS;
- GPO Editor templates – административные шаблоны для редактора групповой политики.
Установка LAPS максимально простая и не должна вызывать каких-либо проблем.
Подготовка схемы Active Directory для внедрения LAPS
Перед развертыванием LAPS необходимо расширить схему Active Directory, в которую будут добавлены два новых атрибута для объектов типа компьютер.
- ms—MCS—AdmPwd– атрибут содержит пароль локального администратора в открытом виде;
- ms—MCS—AdmPwdExpirationTime — хранит дату истечения срока действия пароля на компьютере.
Для расширения схемы, нужно открыть консоль PowerShell, импортировать модуль Admpwd.ps:
Import-module AdmPwd.ps
Расширьте схему Active Directory (нужны права Schema Admin):
В результате в класс «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:
Find-AdmPwdExtendedRights -Identity Desktops | Format-Table ExtendedRightHolders
Как вы видите, право на чтение конфиденциальных атрибутов есть только у группы Domain Admins.
Ели вам нужно запретить определенным группам или пользователям доступ на чтение таких атрибутов, нужно выполнить следующее:
- Откройте ADSIEdit и подключитесь к Default naming context;
- Разверните дерево AD, найдите нужный OU (в нашем примере Desktops), щелкните по нему ПКМ и выберите Properties;
- Перейдите на вкладку Security, нажмите на кнопку Advanced -> Add. В разделе Select Principal укажите имя группы/пользователя, для которого нужно ограничить права (например, domain\Support Team);
- Снимите галку у права “All extended rights” и сохраните изменения.
Аналогичным образом нужно поступить со всеми группам, которым нужно запретить право на просмотр пароля.
Далее нужно предоставить права учетным записям компьютеров на модификацию собственных атрибутов (SELF), т.к. изменение значений атрибутов ms-MCS-AdmPwd и ms-MCS-AdmPwdExpirationTime выполняется из-под учетной записи самого компьютера. Воспользуемся еще одним командлетом Set-AdmPwdComputerSelfPermission.
Чтобы дать права компьютерам в OU Desktops на обновление расширенных атрибутов, выполните команду:
Set-AdmPwdComputerSelfPermission -OrgUnit Desktops
Предоставление прав на просмотр пароля LAPS
Следующий этап – предоставление прав пользователям и группам на чтение хранящихся в Active Directory паролей локальных администраторов на компьютерах домена. К примеру, вы хотите дать членам группы AdmPwd права на чтение паролей компьютеров в OU:
Set-AdmPwdReadPasswordPermission -OrgUnit Desktops -AllowedPrincipals AdmPwd
Кроме того, можно предоставить отдельной группе пользователей право на сброс пароля компьютера (в нашем примере мы предоставляем это право той же группе AdmPwd).
Set-AdmPwdResetPasswordPermission -OrgUnit Desktops -AllowedPrincipals AdmPwd
Настройка групповой политики LAPS
Далее нужно создать новый объект GPO (групповых политик) и назначить его на OU, в которой содержатся компьютеры, на которых вы будете управлять паролями администраторов.
Создайте политику с именем Password_Administrador_Local следующей командой:
Register-AdmPwdWithGPO -GpoIdentity: Password_Administrador_Local
В консоли управления доменными политиками (gpmc.msc) откройте эту политику на редактирование и перейдите в раздел GPO: : Computer Configuration -> Administrative Templates -> LAPS.
Как вы видите, имеются 4 настраиваемых параметра политики. Настройте их следующим образом:
- Enable local admin password management: Enabled (включить политику управления паролями LAPS);
- Password Settings: Enabled – в политике задается сложности пароля, его длина и частота изменения (по аналогии с доменными политиками для паролей пользователей);
- Complexity: Large letters, small letters, numbers, specials
- Length: 12 characters
- Age: 30 days
- Name of administrator account to manage: Not Configured (Здесь указывается имя учетной записи администратора, пароль которой будет меняться. по умолчанию меняется пароль встроенного administrator с SID-500);
- Do not allow password expiration time longer than required by policy: Enabled
Назначьте политику Password_Administrador_Local на OU с компьютерами (Desktops).
Установка LAPS на клиентские компьютеры через GPO
После настройки GPO нужно установить клиентскую часть LAPS на компьютеры в домене. Установить клиент LAPS можно различными способами: вручную, через задание SCCM, логон скрипт и т.п. В нашем примере мы установим msi файл с помощью возможности установки msi пакетов через групповые политики (GPSI).
- Создайте общую папку в сетевом каталоге (или в папке SYSVOL на контроллере домена), в которую нужно скопировать msi файлы дистрибутива LAPS;
- Создайте новую GPO и в разделе Computer Configuration ->Policies ->Software Settings -> Software Installation создайте задание на установку MSI пакета LAPS.
Осталось назначить политику на нужную 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:
Import-Module AdmPwd.PS
Get-AdmPwdPassword -ComputerName <computername>
Если вы считаете, что пароли локальных администраторов на всех компьютерах в некотором OU скомпрометированы, вы можете одной командой сгенерировать новые пароля для всех компьютеров в OU. Для этого нам понадобится командлет Get-ADComputer:
Get-ADComputer -Filter * -SearchBase “OU=Computers,DC=MSK,DC=winitpro,DC=ru” | Reset-AdmPwdPassword -ComputerName {$_.Name}
Аналогичным образом можно вывести список текущих паролей для всех компьютеров в OU:
Get-ADComputer -Filter * -SearchBase “OU=Computers,DC=MSK,DC=winitpro,DC=ru” | Get-AdmPwdPassword -ComputerName {$_.Name}
LAPS можно рекомендовать как удобное решение для организации безопасной системы управления паролями на компьютерах домена с возможностью гранулированного управления доступом к паролям компьютерам из разных OU. Пароли хранятся в атрибутах Active Directory в открытом виде, но встроенные средства AD позволяют надежно ограничить к ним доступ.
А вы из под какой винды LAPS ставили ?
Пробовал на 10TP и на Win8x64 — в обоих случаях не удается импортировать модуль AdmPwd.ps. Пишет Не был загружен….
Тестировал на Windows 2012 R2 + Windows 8.1. Попробуйте указать полный путь к модулю AdmPwd.ps.
Спасибо. Не помогло. А битность-то какая у ваших «тестовых» систем? Может-быть у меня на х64 не идет…
64-битные…
Приведите полный текст ошибки… и посмотрите какую версию Powershell используете (https://winitpro.ru/index.php/2020/05/12/uznat-versiyu-powershell/)?
У меня 3.0
Разобрался с установкой и импортом модуля, но возникла проблема на этапе создания политики.
Дело в том, что 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 января. Помогите пожалуйста.
Установил на DC отдельно шаблоны из инсталятора.
Спасибо.
Установил шаблоны на DC Из инсталлятора.
Спасибо!
Со всем разобрался. Установил — работает! Спасибо, за статью!
Подскажите, пожалуйста, подробнее, как производили установку из инсталятора.
Установка MSI программ через GPO https://winitpro.ru/index.php/2011/10/21/ustanovka-programm-s-pomoshhyu-gruppovyx-politik/
Спасибо, но вопрос был про установку шаблонов в GPO, а не установки программы через GPO. В любом случае, уже разобрался, но по-другому. Спасибо за ответы!
Добрый день!
Отличная статья, но оставила некоторый ряд нераскрытых вопросов.
Основной из них, что делать, если какая-либо рабочая станция вывалилась из домена?
В этом случае вход в систему не может быть совершен и сброс пароля приходиться выполнять известными всем, но достаточно затратными по времени способами…
Есть ли какая-либо распространенная практика на этот счет?
Ксюша, если даже машина «вывалилась» из домена — и политика хоть раз на нем успела отработать — то пароль будет храниться в открытом виде в атрибутах этой машины. Получить вы его можете все так же без проблем, за счет LAPS утилиты. Ну а если политика не применялась — то и пароль не менялся. Вроде логично 🙂
Да, я то же так подумала, и очень удивилась, что не подошел ни старый пароль, ни новый… Видимо где-то ошиблись с настройкой.. Только где?
Видимо, в днк)
Здравствуйте, Дмитрий!
При попытке импортировать модуль Admpwd.ps получаю ошибку:
Windows Server 2008 R2, PowerShell 2.0
Приветствую!
Скорее всего нужно обновить версию PowerShell до 3.0 или выше (cкачайте и установите Windows Management Framework >= 3.0 )
Также убедитесь, что операции изменения схемы проводится на DC с ролью мастера схемы FSMO.
Да, операции изменения схемы проводится на DC с ролью мастера схемы FSMO.
Спасибо, действительно, надо было обновить версию PowerShell до 3.0!
Модуль Admpwd.ps импортировался успешно. ))
Так уж сложилось, что у меня в домене все рабочие станции находятся не в OU, а в CN=Computers.
Решил воспользоваться Вашим примером и проверить, какие пользователи и группы с разрешением «All Extended Rights» имеют право на просмотр паролей компьютеров в CN=Computers.
Получил следующую ошибку:
Лучше все таки создать отдельную/ые OU для компьютеров и пере, возможно у LAPS есть какие то ограничения на этот счет.
Ну или попробуйте такую команду:
Find-AdmPwdExtendedRights -Identity «cn=Сomputers,dc=vashdomen,dc=ru» | Format-Table ExtendedRightHolders
Не помогло… ((
Может быть причина и не в использовании стандартного контейнера.
Попробуйте создать новый OU и проверить, будет ли скрипт отображать права на эту OU.
Сорри!
Не увидел сразу своё новое сообщение.
Подумал, не отправилось…
))
Подскажите.
Импорт проходит успешно. А расширение ошибку выдает. Права админа схемы добавил.
PS C:\Windows\system32> import-module AdmPwd.ps
PS C:\Windows\system32> Update-AdmPwdADSchema
Update-AdmPwdADSchema : Различающееся имя содержит неверный синтаксис.
строка:1 знак:1
+ Update-AdmPwdADSchema
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Update-AdmPwdADSchema], DirectoryOperationException
+ FullyQualifiedErrorId : System.DirectoryServices.Protocols.DirectoryOperationException,AdmPwd.PS.UpdateADSchema
Попробуйте выполнить данную операцию на DC с FSMO ролью schema master.
Если и на нем ошибка, проверьте нет ли проблем с репликацией в AD.
Аналогичная проблема.
На DC с ролью «Shema master» установил Management Tools из пакета LAPS.x64.msi (без AdmPwd GPO Extension).
Запустил PowerShell с правами администратора.
Подключил модуль: Import-module AdmPwd.ps.
При выполнении команды Update-AdmPwdADSchema, получают ошибку «Update-AdmPwdADSchema : The user has insufficient access rights».
Делал logoff/logon — не помогло.
Как обновить схему?
Включите учетную запись в доменную группу Schema Admins. + logoff
Так и сделал. Сработало. Спасибо!
Вопрос снимается. Пользователь, под которым выполняются эти команды должен состоять в группе «Администраторы схемы» (Schema Admins).
У меня по умолчанию компьютеры попадают в CN COmputers, дальше раскидыются по другим OU в которых есть OU Workstation.
Как быть в моем случае?
В общем-то ничего не меняется. В такой структуре вы даже сможете раздать право на просмотр паролей на ПК в конкретной OU определенным службам поддержки, не предоставляя им право на просмотр паролей компьютером в других OU
Так как дать права на CN?
Какой должен быть синтаксис?
Какой должен быть синтаксис для OU в OU?
Заренее благодарю за ответ.
Допустим вам нужно дать права на просмотр паролей в OU
OU=Computers,OU=SPB,DC=cprp,DC=local группе spbAdmPwd. Команда назначений прав на OU будет такой:
Set-AdmPwdReadPasswordPermission -OrgUnit «OU=Computers,OU=SPB,DC=cprp,DC=local» -AllowedPrincipals spbAdmPwd
Делегирование этих прав на OU вышестоящую поможет?
Хорошая статья и хорошая утилитка, только есть одно неудобство при её использовании: шрифт в UI !
Постоянно приходится угадывать букву между l и I 🙂
Вот если бы была возможность изменить шрифт для интерфейса данного приложения было бы проще жить.
upd: В новой версии поле с паролем использует шрифт в котором путаница не возможна.
А что делать с бездоменным зоопарком из 80 машин (ОС редакции home)?
Без домена такое обслуживать очень неудоно. Обновите редакцию ОС. Либо придется выдумывать что-то самописное.
К примеру скрипт, который периодически обходит все ПК, авторизуется на каждом под паролем из базы (даже в виде текстового файла), генерирует новый пароль и обновляет его на удаленном компьютере и в своей базе.
На PowerShell такое можно за пару дней накропать.
может кто знает, как изменить шрифт на удобочитаемый в LAPS? Иногда при выдаче пароля не можем разобрать символы
Смотрите пароль через PowerShell 🙂
Можно ли управлять сразу несколькими локальными учетками ?
LAPS может управлять только одиним аккаунтом локального администратора на компьютере. Либо встроенного администартора известным SID -500, либо другой учеткой, которую вы укажите в политики «Name of administrator account to manage».
Добрый день!
При запросе Get-AdmPwdPassword -ComputerName не отображается пароль, хотя все права прописал
Спасибо все исправил)
Добрый день.
Руками проверьте, появился ли атрибут Get-AdmPwdPassword у компьютера в AD и заполнен ли он.
Добрый день.
Политику сделал, до целевых машин доезжает, пользователь подхватывается. Но, пароль не назначается.
Атрибуты есть.
Если руками нажать сет, то временная метка в атрибуте появляется, но пароль так и не назначается.
Как будто прав не достаточно у SELF и у вас на новый атрибут компьютера. Под домен админом пробовали делать Set?
Ну и проверьте, что настройки политики LAPS успешно применялись к клиентам тем же gpresult (https://winitpro.ru/index.php/2014/08/15/gpresult-diagnostika-primeneniya-gruppovyx-politik/)
С этого момента поподробнее. Тоже есть несколько машин на которых не поменялся пароль. На других из той же ОУ без проблем. Куда копать?
Сам задал вопрос..сам отвечаю)))
В безопасности компа было выключено наследие.
Свойства -> Безопасность -> Дополнительно -> Включить наследование
Просто оставлю это здесь.
Как посмотреть права не на OU=Desktops, а на CN=Computers.
При выполнении команды
Find-AdmPwdExtendedRights -Identity Computers | Format-Table ExtendedRightHolders
выходит ошибка:
Find-AdmPwdExtendedRights : Object not found
At line:1 char:1
+ Find-AdmPwdExtendedRights -Identity Computers | Format-Table Extended …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Find-AdmPwdExtendedRights], NotFoundException
+ FullyQualifiedErrorId : AdmPwd.PSTypes.NotFoundException,AdmPwd.PS.FindExtendedRights
Правильно запускать так:
Find-AdmPwdExtendedRights -OrgUnit «CN=Computers,DC=test,DC=local» | Format-Table ExtendedRightHolders
у каждого свое имя OUшки, так вместо Desktops написал шотамутебя, и все ок
Добрый день!
А если со стороны контролера все изменения прошли успешно, появились атрибуты в компьютерах, UI выдает и пароль и время действия пароля но на пользовательских устройствах сам пароль не меняется и на дефолтной учетке и на указаной через политики ? в логах вообще нет никаких сообщений от AdmPwd, хотя msi нормально установилась
Не понял, т.е. пароль на компьютерах все-таки один раз изменился? Или по факту сейчас пароли в AD пустые?
На первых взгляд вам бы нужно проверить, что политика LAPS применяется к компьютеру и не фильтруется. Проверяйте через gpresult или rsop.msc.
Здравствуйте, а если в журнале Application нет никаких событий, но пароль поменялся.
и должен ли висеть процесс LAPS или он отрабатывает только при загрузке и закрывается?
Процесс LAPS не запушен все время, он выполняется при загрузке компьютера и выполнении расширенных политик CSE через библиотеку AdmPwd.dll.
Статья писалась про старую версию LAPS, которая еще AdmPwd, возможно сейчас событие другое.
В статье указывается, что необходимо снять атрибут в ADSI, но данный атрибут уже снят!!! Но даже с этим снятым атрибутом, пользователь видит пароль через свойство компьютера в АД.
Смотрите результирующе разрешения для пользователя, воможно ему делегированы административные полномочия на OU или объекты
При подключении к домену, новые компьютеры попадают в built-in-OU «Computers». Правильно ли будет создать отдельный OU для управления LAPS, куда переместить все компьютеры, на которых необходимо управление паролем локального админа?
Конечно 🙂 Зависит конечно от размера домена, но если вам нужно разделять компьютеры по офисам, зданиям, филиалам, городам удобнее вешать на них разные политики, если переместить их в собственные OU.
ЗЫ. У меня дефолтное OU Computers чистится каждую ночь 🙂
Добрый день, коллеги.
Сегодня обнаружил странную вещь. Пароль показывает только тогда, когда я добавляю уч запись в группу акаунт операторс. Не смотря на то, что я создал группу для LAPS и дал ей права на просмотр и сброс пароля для определенного контейнера согласна статье:
Set-AdmPwdReadPasswordPermission -OrgUnit Desktops -AllowedPrincipals AdmPwd
Set-AdmPwdResetPasswordPermission -OrgUnit Desktops -AllowedPrincipals AdmPwd
Может у кого есть идеи?
Да и ещё такой момент-через Powershell пароль показывет, а через утилиту -нет(((
Проблему нашёл и устранил.
А заключалась она в том, что на проверяемом компьютере было отключено наследование и соот-но не применялись права назначенные на OU.
Хорошо, что разобрались сами и оставили решение здесь.
Может быть кто-то меня поправит, и я где-то до конца не разобрался, но: столкнулся с тем, что пользователь который добавлял компьютер в домен, имеет дополнительные права на этот компьютер (видно в ADSI edit, Security, Advdnced). И «простое» снятие галки у права “All extended rights” в свойствах OU, где находится этот компьютер не удаляет/запрещает просмотр доп параметров (extendet rights) у данного пользователя.
Например, Вася вводит комп PC01 в домен, далее этот комп переносится в OU «Comp». Делаются все манипуляции по внедрению LAPS. Далее на OU Comp (в ADSI, Security, Advanced) явно добавляем Васю, снимаем (у меня по дефолту она и так не активна) галку «extendet rights», применяем (наследование включено).
Потом в ADSI смотрю закладку уже на самом компе PC01 и вижу, что пользователь Вася имеет целый ряд дополнительных разрешений.
Т.е. получается своеобразная «дыра».
Даже если в домене выделена отдельная учетка для ввода компов, с кем-то в некоторых моментах это может сыграть злую шутку.
Или я чего-то не доглядел?
Хм, довольно интересно. Тоже замечал такое, что у пользователя добавившего комп в домен есть дополнительные права.
Провертите, есть ли у него право на просмотр значения атрибута ms—MCS—AdmPwd.
Можете создать тестового пользователя, добавить под ним в домен комп и утилитой проверить видит ли он пароль компьютера. Ну или проще через результирующие разрешения.
На 100% утверждать не буду (возможно что-то упустил, проверял несколько раз), но пользователь который вводит компьютер в домен — будет видеть значение атрибута ms—MCS—AdmPwd, пока вы не удалите его из списка в закладке Security (в ADSI редакторе). Ну или указать Deny на Extended rights.
Если есть у кого возможность/желание поэкспериментировать — отпишите результаты. Возможно кому-то это поможет избежать проблем.
у меня вообще “All extended rights” в свойствах OU нет, все списки перелопатил — нет и все, хз как так! В общем встал и сижу….
Создал тестовый OU DesktopsTest с одним объектом TEST-PC.
Схема AD подготовлена — в атрибутах объекта TEST-PC имеются два атрибута: ms-Mcs-AdmPwd и ms-Mcs-AdmPwdExpirationTime. Права на чтение атрибутов имеются у группы «Администраторы домена»:
PS C:\Users\user1> Find-AdmPwdExtendedRights -Identity DesktopsTest | Format-Table ExtendedRightHolders
ExtendedRightHolders
--------------------
{NT AUTHORITY\СИСТЕМА, Domain\Администраторы домена}
Создана политика «LAPS settings» с указанными в статье настройками. Также создана политика «LAPS install», с помощью которой программа установлена на компьютер TEST-PC.
Этот компьютер перезагружался, локальная учётная запись администратора включалась и отключалась. Но её пароль так и не был назначен с помощью политики — утилита LAPS UI показывает пустое поле.
Что я делаю не так? Что проверить?
Политики на компьютере TEST-PC применяются. Проверял с помощью gpresult /r:
Примененные объекты групповой политики
---------------------------------------
LAPS settings
LAPS install
Default Domain Policy
Но утилита LAPS UI по-прежнему ничего не показывает.
Set-AdmPwdComputerSelfPermission -OrgUnit "OU=DesktopsTest,DC=Domain,DC=com"
После выполнения этой команды, компьютер TEST-PC, член OU DesktopsTest, получил доступ к новым атрибутам (ms-Mcs-AdmPwd и ms-Mcs-AdmPwdExpirationTime), и заполнил их согласно политике. Вижу их в свойствах TEST-PC. Но утилита LAPS UI, запущенная на DC, всё равно их не видит.
Зато пароль можно увидеть, запустив команду «get-admpwdpassword test-pc» на контроллере домена.
Только что заметил, что программа LAPS UI не показывает пароль, но показывает правильный срок его действия.
Вопрос снимается. Для чтения атрибута ms-Mcs-AdmPwd на удалённой машине, нужно запускать утилиту LASP UI или консоль PowerShell на контроллере домена, с правами Администратора.
LAPS всем хорош, кроме того что в больших компаниях неудобно управлять и получать доступ к ним.
Есть расширения к LAPS, напримерв в виде бесплатных вариантов веб доступа к LAPS _https://github.com/lithnet/laps-web
Есьб готовые решения в виде условно-бесплатных (для мелких компаний) и платных, типа Convenient LAPS (от _https://solsecurity.org/), с веб-интерфейсом, возможностью доступа с мобильных устройств, журналированием, гибким делегированием полномочий и другими функциями, которых нет в LAPS.
у меня работает, но показывает какие то странные пароли (делал на тестовых машинах) допустим у меня пароль на встроенном админе «1», а мне LAPS показывает целый набор символов.
LAPS не собирает пароли лок админов с компьютеров, а меняет их на рандомные. Их вы и видите в консоли.
Так по умолчанию же локальная учетка Администратора выключена, пароль то генерируется, но пишет что учетная запись Администратора отключена. Как быть?
Можно включить учетную запись встроенного администратора через GPO
https://winitpro.ru/index.php/2015/09/25/vklyuchaem-skrytuyu-uchetnuyu-zapis-administratora-v-windows-10/