LAPS (Local Administrator Password Solution) позволяет централизованно управлять паролями локальных администраторов на компьютерах домена. Текущий пароль локального администратора хранятся в защищённых атрибутах объектов Computer в Active Directory, регулярно меняется автоматически, и может быть получен авторизованными пользователями.
В этой статье мы покажем, как настроить Windows LAPS для управления паролями локальных администраторов на компьютерах в домене Active Directory.
До апреля 2023 года установочный MSI файл LAPS нужно было вручную скачивать с сайта Microsoft, разворачивать на компьютерах компоненты администратора или клиентскую часть, устанавливать ADMX шаблоны GPO для LAPS и расширять схему AD.
В апреле 2023 года вышли обновления, которые добавляют встроенную поддержку новой версии LAPS в Windows. Теперь для использования LAPS не нужно скачивать и устанавливать MSI пакет.
Особенности новой версии Windows LAPS
Встроенная поддержка Windows LAPS была добавлена в следующих кумулятивных обновлениях, выпущенных в апреле 2023 года:
- Windows 11 22H2 – KB5025239
- Windows 11 21H2 – KB5025224
- Windows 10 22H2 — KB5025221
- Windows Server 2022 – KB5025230
- Windows Server 2019 – KB5025229
Что нового в Windows LAPS?
- Все компоненты нового LAPS встроены в Windows;
- Позволяет сохранять пароли администраторов в локальную AD и Azure AD;
- Поддерживается управление паролем DSRM (Directory Services Restore Mode) на контроллерах домена AD;
- Поддержка шифрования паролей;
- История паролей;
- Автоматическое изменение пароля локального администратора после его использования для локального входа на компьютер
Как мы уже указали выше, теперь не нужно скачивать и устанавливать клиент LAPS вручную, все необходимые компоненты LAPS доступны в Windows после установки апрельских обновлений.
Инструменты управления Windows LAPS:
- Новый ADMX файл групповых политик;
- Отдельная вкладка в свойствах компьютера в консоли Active Directory Users and Computers (ADUC);
- PowerShell модуль Windows LAPS;
- Отдельный журнал Event Viewer: Application and Service Logs -> Microsoft -> Windows -> LAPS -> Operational.
Microsoft указывает, что нужно отключить политики и удалить настройки предыдущую версию legacy LAPS (msi) перед развертыванием групповых политик новой LAPS. Для этого нужно остановить новые установки MSI LAPS и удалить все параметры в ветке реестра HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\State.
Если старая версия не удалена в Event Viewer будут появляться события со следующими Event ID:
- Event ID 10033, LAPS — The machine is configured with legacy LAPS policy settings, but legacy LAPS product appears to be installed. The configured account’s password will not be managed by Windows until the legacy product is uninstalled. Alternatively, you may consider configuring the newer LAPS policy settings.
- Event 10031, LAPS — LAPS blocked an external request that tried to modify the password of the current manager account.
Разворачиваем Local Administrator Password Solution в домене Active Directory
Вы можете начать внедрение новой версии LAPS после установки новых обновлений на все контроллера домена.
Для управления Local Administrator Password Solution используются PowerShell командлеты из модуля LAPS. Доступны следующие команды:
Get-Command -Module LAPS
- Get-LapsAADPassword
- Get-LapsDiagnostics
- Find-LapsADExtendedRights
- Get-LapsADPassword
- Invoke-LapsPolicyProcessing
- Reset-LapsPassword
- Set-LapsADAuditing
- Set-LapsADComputerSelfPermission
- Set-LapsADPasswordExpirationTime
- Set-LapsADReadPasswordPermission
- Set-LapsADResetPasswordPermission
- Update-LapsADSchema
После установки обновлений на DC и клиенты, нужно выполнить обновление схемы AD, которое добавит новые атрибуты. Выполните команду:
Update-LapsADSchema
Update-LapsADSchema : A local error occurred.
В схемы будут добавлены следующие атрибуты:
- msLAPS-PasswordExpirationTime
- msLAPS-Password
- msLAPS-EncryptedPassword
- msLAPS-EncryptedPasswordHistory
- msLAPS-EncryptedDSRMPassword
- msLAPS-EncryptedDSRMPasswordHistory
Откройте консоль ADUC, выберите любой компьютер в AD и перейдите на вкладку редактора атрибутов объекта AD. Проверьте, что у объекта теперь доступны новые атрибуты.
Атрибуты
msLAPS-*
пока не заполнены.
Теперь нужно разрешить компьютерам в указанном Organizational Unit (OU) обновлять атрибуты msLAPS-* в свойствах своих учетных записей в AD.
Например, я хочу разрешить компьютерам из OU MSK обновлять пароль, который хранится в атрибутах AD. Выполните команду:
Set-LapsADComputerSelfPermission -Identity "OU=Computers,OU=MSK,DC=winitpro,DC=ru"
Теперь с помощью PowerShell создадим группу пользователей, которым можно просматривать пароли локальных администраторов на компьютерах в этом OU:
New-ADGroup MSK-LAPS-Admins -path 'OU=Groups,OU=MSK,DC=winitpro,DC=ru' -GroupScope local -PassThru –Verbose
Add-AdGroupMember -Identity MSK-LAPS-Admins -Members user1, user2
Разрешим для этой группы просматривать пароли и сбрасывать их:
$ComputerOU = "OU=Computers,OU=MSK,DC=winitpro,DC=ru"
Set-LapsADReadPasswordPermission –Identity $ComputerOU –AllowedPrincipals MSK-LAPS-Admins
Set-LapsADResetPasswordPermission -Identity $ComputerOU -AllowedPrincipals MSK-LAPS-Admins
Чтобы проверить текущие права на атрибуты LAPS в OU используется команда Find-LapsADExtendedRights.
Find-LapsADExtendedRights -Identity "OU=computers,DC=yourdomain,DC=com"
Настройка групповой политики смены локальных паролей через LAPS
При установке последних обновлений в Windows появится новый набор административных шаблонов для управления конфигурацией LAPS через GPO (%systemroot%\PolicyDefinitions\laps.admx).
Если у вас используется централизованное хранилище для хранения ADMX шаблонов, скопируйте LAPS.admx в
\\winitpro.ru\SysVol\winitpro.ru\Policies\PolicyDefinitions
.
Настройки LAPS находятся в следующем разделе групповых Computer Configuration -> Policies -> Administrative Templates -> System -> LAPS. Здесь доступны следующие политики LAPS:
- Enable password backup for DSRM accounts
- Configure size of encrypted password histor
- Enable password encryption
- Configure authorized password decryptors
- Name of administrator account to manage
- Configure password backup directory
- Do not allow password expiration time longer than required by policy
- Password Settings
- Post-authentication actions
Попробуем настроить минимальную групповую политику LAPS для домена Active Directory.
- Откройте консоль Group Policy Management (
gpmc.msc
), создайте новую GPO и назначьте на OU с компьютерами; - Откройте новую GPO и перейдите в раздел с настройками LAPS;
- Включите политику Configure password backup directory и выберите Active Directory. Эта политика разрешает сохранять пароль администратора в учетной записи компьютера;Windows LAPS может сохранять пароли в Azure Active Directory (AAD) вместо локальной ADDS.
- Затем включите политику Password Settings. Здесь нужно указать параметры сложности пароля, длину, частоту смены ;
- В параметре Name of administrator account to manage нужно указать имя учетной записи администратора, пароль которого нужно менять. Если вы используете встроенного администратора Windows, укажите Administrator здесь.LGPO не создает локальные учетные записи администратора. Если вы хотите использовать другую учетную запись администратора, нужно предварительно создать ее на компьютерах с помощью GPO или PowerShell.
- Перезагрузите компьютер чтобы применить новые настройки GPO.
Как узнать пароль локального администратора через LAPS?
После внедрения политик LAPS, Windows при загрузке изменит пароль локального администратора и запишет его в защищенный атрибут msLAPS-Password в объект компьютера в AD. Вы можете получить текущий пароль компьютера в консоли ADUС или с помощью PowerShell.
Откройте консоль ADUC и найдите компьютер, пароль которого вы хотите получить. В свойствах компьютера появилась новая вкладка LAPS.
На вкладке отображаются следующие данные:
- Current LAPS password expiration
- LASP local admin account name
- LASP local admin account password
Также вы можете получить текущий пароль администратора компьютер через PowerShell:
Get-LapsADPassword "msk-pc221" -AsPlainText
ComputerName : msk-pc221 DistinguishedName : CN= msk-pc221,OU=… Account : administrator Password : .[lB2DWxy1!k23 PasswordUpdateTime : 4/20/2023 10:13:16 AM ExpirationTimestamp : 5/20/2023 10:13:16 AM Source : EncryptedPassword DecryptionStatus : Success AuthorizedDecryptor : WINITRPRO\Domain Admins
Вы можете использовать этот пароль для локального входа на этот компьютер с под учетной запись администратора.
Если вы хотите сбросить текущий пароль, выполните на компьютере команду:
Reset-LapsPassword
Это вызовет немедленную смену пароля текущего пользователя и запишет новый пароль в AD.
Windows Local Administrator Password Solution – это простое встроенное решение, которое позволит вам повысить безопасность использования учетных записей локальных администраторов на компьютерах домена. LAPS хранит текущий пароль администратора в защищённом атрибуте 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/
Из статьи не совсем понятно, как действовать, если ранее использовалась старая версия LAPS (которая раскидывалась через MSI на сервера и рабочие станции). Удалять ее? После обновления схемы AD старая версия будет работать? У меня домен на несколько тысяч серверов / рабочих станций, не хотелось бы все одномоментно похерить….
1) не нужно ставить старый LAPS после установки обновлений ( это ломает оба)
The April 11, 2023 update has two potential regressions related to interoperability with legacy LAPS scenarios. Please read the following to understand the scenario parameters plus possible workarounds.
Issue #1: If you install the legacy LAPS CSE on a device patched with the April 11, 2023 security update and an applied legacy LAPS policy, both Windows LAPS and legacy LAPS will enter a broken state where neither feature will update the password for the managed account. Symptoms include Windows LAPS event log IDs 10031 and 10033, as well as legacy LAPS event ID 6. Microsoft is working on a fix for this issue.
Two primary workarounds exist for the above issue:
a. Uninstall the legacy LAPS CSE (result: Windows LAPS will take over management of the managed account)
b. Disable legacy LAPS emulation mode (result: legacy LAPS will take over management of the managed account)
Issue #2: If you apply a legacy LAPS policy to a device patched with the April 11, 2023 update, Windows LAPS will immediately enforce\honor the legacy LAPS policy, which may be disruptive (for example if done during OS deployment workflow). Disable legacy LAPS emulation mode may also be used to prevent those issues.
_https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
2) Если развернут старый LAPS, новый работает в режиме эмуляции
_https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-legacy
Благодарю за развернутый ответ!
Вопрос по Microsoft LAPS. Есть лес, в нем три домена. 1 и 2 домен на win server 2012r2. 3 домен на win server 2019. Можно ли в 1 и 2 домене использовать windows laps, а в 3 домене использовать microsoft laps ?
Схема расширяется на весь лес, поэтому было бы логично сначала мигрировать со старой версии в режиме эмуляции с legacy laps в 1 и 2 и потом внедрять новую в 3 домене
То есть сама по себе идея рабочая? 1 и 2 домен работают по старому, а 3 домен по новому режиму?
Думаю, да.
Тут оказывается, что несмотря на то что в требованиях указан уровнеь домена 2016 для Windows LAPS, можно развернуть его в ограниченном режиме и на старых версиях:
If your domain is configured below 2016 Domain Functional Level (DFL), you can't enable Windows LAPS password encryption period. In this scenario clients can only be configured to store passwords in clear-text (secure by Active Directory ACLs), and DCs managing their local DSRM account.
_https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory
Мне кажется или в команде
Set-LapsADComputerSelfPermission -Identity "OU=Computers,OU=MSK,Company,DC=winitpro,DC=ru"
ошибка что Company указано без OU и причем два раза, или так подразделение называется MSK,Company?
Да, ошибка, поправил.
Не спешите разворачивать в RU доменах. После добавления шаблона в центральное хранилище идет ругань «не удалось найти подходящий файл ресурса для файла LAPS.admx».
Adml видимо хочет но его нет 🙂
https://learn.microsoft.com/en-us/answers/questions/1253614/after-installing-the-april-11-2023-kb5025229-patch
Вот тут как бы вопрос задали, но ответ конечно шедевральный. «Скачайте старый LAPS, разархивируйте и убедитесь что файл в описания LAPS.adml так и нет…» Ждемс …..
В Майском обновлении ошибку устранили.
Добрый день! Подскажите, при попытке развернуть LAPS на копии DC в виртуалке (Windows 2019, powershell из под администратора), команда Update-LapsADSchema выдаёт:
Update-LapsADSchema : An operation error occurred.
At line:1 char:1
+ Update-LapsADSchema
+ ~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Update-LapsADSchema], DirectoryOperationException
+ FullyQualifiedErrorId : System.DirectoryServices.Protocols.DirectoryOperationException,Microsoft.Windows.LAPS.Up
dateLapsADSchema
В Админы домена, схемы, предприятия себя добавил (перезагружался). До этого LAPS развёрнут не был. Куда копать ?
Добрый день.
Подскажите, пожалуйста, может кто-то задавался вопросом.
Если компьютер вывалился из домена и домен ему больше не доверяет (чиниться перевтягиванием в домен), а тут подошел срок генерации нового пароля и в АД новый пароль записан уже не может быть т. к. нет доверия, то получается под локальным админом уже не зайти на компьюетр?
Или если не будет доступа к АД, то и пароль новый не будет установлен при истечении срока пароля?
Пароль же хранится локально и всегда можно войти под старым паролем лок. админа.
Получается, что новый пароль записать в AD компуте уже не может (нет доверия с доменом(, но и пароль который хранится локально не будет перезаписан.
Ну вот то, что компьютер не сможет в АД записать новый пароль это 100%.
А вот, то что он не сможет сбросить локально пароль не факт.
Моя логика:
1. Групповые политики хранятся на компьютерах локально.
2. Из п.1 следует, что политика «Срок действия пароля (в днях)» = 30 дней компьютеру заранее известна и дата сброса пароля тоже.
3. Приходит дата сброса пароля. Сначала компьютер сбросит пароль и только потом попытается его записать в АД, но у него ничего не выйдет.
И вот тут непонятно.
— Либо сначала происходит генерация пароля, потом запись в АД и только потом установка нового пароля админа.
— Либо первым делом проверяется доступ к АД и только потом сброс пароля.
Но я сильно сомневаюсь, что хотя бы один из этих двух вариантов реализовали. Мне кажется МС считает что компьютер из АД не может сам отвалиться 😅, соответственно и проверять доступность АД не нужно 😁
New-ADGroup MSK-LAPS-Admins -path ‘OU=Groups,OU=MSK,DC=winitpro,DC=ru’ -GroupScope local -PassThru –Verbose
Тут вместо -GroupScope local должно быть -GroupScope DomainLocal
А в описании параметра сказано:
Всем доброго дня. Подскажите пожалуйста, есть ли возможность вывести где у LAPS нет пароля (то есть на какие компы он не применился) по всему домену и как это сделать, есть ли есть такая возможность? Чтобы не пробегать по каждому хосту в по OU и не искать.
Get-ADComputer -Filter * -Properties msLAPS-Password | Where-Object msLAPS-Password -eq $null | FT Name, msLAPS-Password
у меня так выдает,нормально что такой атрибут есть,а вашего нет?
Get-ADComputer -Filter * -Properties msLAPS-EncryptedPassword | Where-Object msLAPS-EncryptedPassword -eq $null | FT Name, msLAPS-EncryptedPassword
у меня так выдает,нормально что такой атрибут есть,а вашего нет?
Get-ADComputer -Filter * -Properties msLAPS-EncryptedPassword | Where-Object msLAPS-EncryptedPassword -eq $null | FT Name, msLAPS-EncryptedPassword
Значит у вас включена опция «Enable password encryption».
А так, все правильно.
Это нормально что они шифруются же? Или лучше отключить?
Нормально )
Что-то никак не могу понять как администратору, состоящему в группе, которая прописана в Set-LapsADResetPasswordPermission, сбросить пароль?
Если вы хотите сбросить текущий пароль, выполните на компьютере команду:
Reset-LapsPassword
Это вызовет немедленную смену пароля текущего пользователя и запишет новый пароль в AD.
В команде Find-LapsADExetendedRights ошибка, лишняя буква.
ну и неплохо бы добавить что полный формат команды:
Find-LapsADExtendedRights -Identity «OU=computers,DC=yourdomain,DC=com»
Пофикшено, спасибо!
Вам спасибо за такую отличную статью. LAPS уже был настроен, но я только из этой статьи узнал что оказывается его интегрировали в AD с недавними обновлениями. Пришлось все переделывать.
Кстати дополню еще, в вашей инструкции по настройке GPO пункт 5ый: в случае импользования Built-in Administrator не надо там указывать имя вообще. Об это написано в описаниие этого параметра в шаблоне. Т.е. если не настраивать этот параметр то LAPS по дефолту берет Built-in Administrator
Use this setting to configure the name of the managed local administrator account.
If not specified, this setting defaults to managing the built-in local administrator account.
https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-policy-settings#administratoraccountname
Добрый день,подскажите пожалуйста: как дать определенному пользователю из группы тех.поддержка просмотр пароля LAPS(настраивалось после апрельского обновления по статье),я так понимаю нужен просмотр каких то атрибутов,если да то как это сделать? или разрешения где то отдельно настраиваются?
Ошибка такая при просмотре в оснастке AD- «пароль учетной записи зашифрован,но у вас нет разрешений на его расшифровку»
Как и описано в статье, надо дать права на чтение атрибута:
Set-LapsADReadPasswordPermission -Identity -AllowedPrincipals
Если храните шифрованные пароли, нужно дополнительно дать группе права на расшифровку через GPO «Configure authorized password decryptors»
Если указываю на расшифровку только нужную группу, то права на расшифровку по умолчанию у доменных администраторов пропадают. Получается, что в этой политике нужно указывать 2 группы сразу — настроенную вручную и доменных администраторов. Вопрос как выглядит синтаксис для этого поля(просто через запятую может)? Также отмечу, что применение этой политики после включения происходит не сразу, а нужно какое то время подождать, имейте это ввиду!
Попробую добавить группу доменных администраторов в эту самую группу безопасности и указать ssid этой группы в политике «Configure authorized password decryptors». Может так получится решить проблему и не придётся указывать через запятую.
синтаксис через запятую не работает
Что делать, если в домене разнообразные версии Windows 10 (от 1809 до 22H2), тоже самое и про сервера — от 2016 и выше. Вы пишете, что старый LAPS нельзя совмещать с новым, при этом новый не поддерживает старые ОС, а старый — новые…
Тупик?
Нехорошо держать в домене старые билды, коотрые не обновляются. как минимум обновляйтесь до 22h2.
Либо идеть на старой версии laps. Я не пробовал в такой смешанной конфигурации, но думаю будет работать.
Вопрос как в Windows Server 2022 отключить Windows LAPS, чтоб доменными политиками нельзя было его включить?
Тут зависит от того, зачем вам это. спрятаться от старшего админа? исключить случайный сброс пароля?
В любом случае это будет костыль. Как вариант — исключить компьютер из области действия доменной политики laps. или лишить учетную запись компьютера прав на обновление атрибутов LAPS в учетке AD.
Привет, внесите в статью примечание: при смене членов группы decryptors, требуется сброс пароля лапс либо командлетом или во вкладке лапс, либо через изменение эксперейшин дэйт. Иначе доступ не будет предоставлен.
причину описывать?
Либо можно сложнее:
1. Очистить kerb тикеты пользователя
2. Удалить все кэшированные ключи DPAPI\KDS из локального каталога профиля пользователя «AppData\Local\Microsoft\Crypto\KdsKey».
Всем привет, есть замечательное решение для просмотра паролей через WEB — https://weblaps.pro/
Comunity version на 100 ПК, далее к разработчику
Советую
Спасибо за статью! Подскажите, как в случае чего забрать права на чтение и запись у группы
MSK-LAPS-Admins? Какова обратная команда данным командам:
Set-LapsADReadPasswordPermission –Identity $ComputerOU –AllowedPrincipals MSK-LAPS-Admins
Set-LapsADResetPasswordPermission -Identity $ComputerOU -AllowedPrincipals MSK-LAPS-Admins
Скорее всего придется вручную править ACL в свойства безопасности OU на вкладке Security.
Протестируйте сначала на тестовой OU.
Если все получится, автоматизируйте через Get-Acl/Set-Acl