Здравствуйте.

Необходима следующая информация:
- Версия операционной системы на клиентской машине.
- Версия пакетов gpupdate, admc, admx-basealt, gpui, libcng-dpapi, libgkdi на клиентской машине (это очень важно, были внесены изменения и исправления в последние версии пакетов).
- Вывод команды gpoa --loglevel 0 выполненная от рута на клиентской машине.

Включены ли экспериментальные политики в настройках GPUI?
Для того чтобы включить:
Перейти в Компьютер → Административные шаблоны → Система ALT → Групповые политики → Экспериментальные групповые политики.
Переключить в состояние Включено и нажать OK.

По умолчанию у машин в OU к которому применяется групповая политика LAPS нет прав читать свой собственный пароль, поэтому нужно задать расширенные права безопасности для машин в ADMC.

ПКМ по OU. После чего выбрать вкладку Безопасность. Выбрать "Дочерние объекты: Компьютер" в выпадающем меню "Применять:". Выбрать SELF в дереве "Пользователи и группы". Выбрать вкладку "Расширенные". Установить галочки напротив "Читать свойство - ms-LAPS-Encrypted-Password-Attributes" и "Изменять свойство - ms-LAPS-Encrypted-Password-Attributes" в разделе Разрешено.
Применить изменения кнопкой "OK".

После этого запустить на клиенте от рута gpoa --loglevel 0. Для получения отладочной информации gpupdate.
Посмотреть что появился вывод:
LAPS applier started|{}
LDAP updated with new password data|{'computer_dn': Dn('CN=LINUX-CLIENT,OU=LAPSManaged,DC=domain,DC=alt')}

Для тестирования нового функционала LAPS в samba можно использовать windows client введя, например, windows 11 в домен samba и запустив на ней обновление групповых политик. В RSAT в оснастке Users and Computers будет видно пароль администратора для данной машины во вкладке LAPS. Это позволит отделить ошибки в samba от ошибок клиентских утилит таких как admc.

И хотелось бы добавить что если у нас в заголовке задачи стоит "admc", то странно прикреплять эту ошибку к пакету samba. У нас есть пакет "admc", я думаю будет, более правильно, перевести эту ошибку на него.

Created attachment 19794 [details]
gpoa --loglevel 0

Перепроверил ошибку с использованием Samba DC в [p11+394751] и [sisyphus].

(В [p11] поддержки LAPS у Samba DC ещё нет, не проверял.)

Проблема пока именно в Samba, т. к. с клиента Windows видно то же самое. Поэтому оставляю компонент `samba`.

Отмечу:

- Ошибку с DNS при gpupdate/gpoa на ALT. Не уверен, воспроизводилась ли она при изначальном заведении ошибки.

- Интересное сообщение "Политика LAPS настроена как disabled." в логе Windows, несмотря на все настройки. Хотя политики были настроены для "Система ALT", вероятно они не применяются для Windows.


Шаги
====

1. Развернуть Samba DC + replica.

При этом применён workaround для ошибки https://bugzilla.altlinux.org/43863 (Не стартует сервис samba после перезагрузки: Failed to bind to ipv6 NT_STATUS_ADDRESS_NOT_ASSOCIATED): отключение прослушивания на IPv6:

    interfaces = <ipv4_dc/dc2> 127.0.0.1
    bind interfaces only = yes

См. https://bugzilla.altlinux.org/show_bug.cgi?id=55254#c9 о проблеме с IPv6 из-за workaround в шаге 1. Но пробовал и без этого workaround (что требует перезапуска samba.service после запуска системы) - поведение не изменилось.


2. Ввести клиентов с помощью system-auth (alterator-auth), SSSD.


3. Повысить уровень домена:
3.1. DC, replica: В раздел [global] файла `/etc/samba/smb.conf` добавить строку `ad dc functional level = 2016`
3.2. DC, replica: # systemctl restart samba.service
3.3. DC: # samba-tool domain schemaupgrade --schema=2016
3.4. DC: # samba-tool domain functionalprep --function-level=2016
3.5. DC: # samba-tool domain level raise --domain-level=2016 --forest-level=2016
3.6. DC: # samba-tool domain level show


4. Расширить схему на DC:

4.1. # git clone https://github.com/august-alt/samba-extension-laps-v2-schema && cd samba-extension-laps-v2-schema

# git rev-parse HEAD
0fd4fdba97f8289b96ae063e2d547a1b57762f3e

(В p11 пакета ещё нет.)

4.2. # mkdir /usr/share/native-laps-schema ; \
  cp extended-rights.ldif /usr/share/native-laps-schema ; \
  cp laps-v2-schema-extension.ldif /usr/share/native-laps-schema/ ; \
  cp computer.ldif /usr/share/native-laps-schema/

4.3. # python3 install-laps-v2-schema.py --domain "dc=samba,dc=testdomain" --samfile "/var/lib/samba/private/sam.ldb"


5. Выполнить предварительную настройку политик:

5.1. На клиенте, где установлен admc, зайти доменным пользователем и запустить admc из консоли:

$ kinit Administrator && admc

5.2. ПКМ на samba.testdomain -> Создать -> Подразделение -> ввести имя, например LAPSOU -> ОК

5.3. Переместить всех клиентов из Computers в LAPSOU.

5.4. Создать новую групповую политику для LAPSOU:

    - Объекты групповой политики -> LAPSOU -> Создать политику и связать ее с этим подразделением -> ввести имя, например LAPS -> ОК

5.5. Включить политики LAPS:

    - ПКМ по политике LAPS -> Изменить...

    - Компьютер → Административные шаблоны → Система ALT →
        - Групповые политики → Механизмы GPUpdate → Настройка LAPS → Включено → ОК
        - LAPS:
            - Каталог резервного копирования паролей -> Включено -> установить значение Active Directory -> OK
            - Шифрование паролей -> Включено -> OK
            - Имя учетной записи администратора -> Включено -> Указать root -> OK


6. Применить политики и проверить:

6.1. Выйти из gpui и admc, обновить групповые политики на всех клиентах
$ gpupdate

6.2. Снова зайти в admc:
$ admc

6.3. Включить Настройки -> Дополнительные возможности


7. Проверить в admc наличие атрибутов:

7.1. В admc выбрать подраздление LAPSOU, ПКМ по записи компьютера -> Свойства -> Атрибуты

7.2. Проверить наличие атрибутов LAPS:

    msLAPS-EncryptedDSRMPassword
    msLAPS-EncryptedDSRMPasswordHistory
    msLAPS-EncryptedPassword
    msLAPS-EncryptedPasswordHistory
    msLAPS-Password
    msLAPS-PasswordExpirationTime


8. Перейти в раздел LAPS и проверить информацию о пароле:

    Время завершения действия пароля
    Имя учетной записи локального администратора LAPS
    Пароль учетной записи локального администратора LAPS


9. Дополнительно: # gpoa --loglevel 0


10. Дополнительно: Проверить влияние экспериментальных политик:

10.1. Из комментарий #1: (Включены ли экспериментальные политики в настройках GPUI?) Для того чтобы включить: Перейти в Компьютер → Административные шаблоны → Система ALT → Групповые политики → Экспериментальные групповые политики. Переключить в состояние Включено и нажать OK.

10.2. Закрыть GPUI, ADMC
10.3. Повторно $ gpupdate
10.4. Повторно # gpoa --loglevel 0
10.5. Повторно проверить в ADMC наличие вкладки LAPS и значения в ней (см. шаг 8)


11. Дополнительно: Проверить влияние прав чтения пароля:

11.1. Из комментарий #1: (По умолчанию у машин в OU к которому применяется групповая политика LAPS нет прав читать свой собственный пароль, поэтому нужно задать расширенные права безопасности для машин в ADMC.)
      - ПКМ по OU. [-> Свойства]
      - После чего выбрать вкладку Безопасность.
      - Выбрать "Дочерние объекты: Компьютер" в выпадающем меню "Применять:".
      - Выбрать SELF в дереве "Пользователи и группы".
      - Выбрать вкладку "Расширенные".
      - Установить галочки напротив "Читать свойство - ms-LAPS-Encrypted-Password-Attributes" и "Изменять свойство - ms-LAPS-Encrypted-Password-Attributes" в разделе Разрешено. [В названии вместо ключа свойства указано "LAPS Encrypted Password Attributes"]
      - Применить изменения кнопкой "OK".

11.1. Закрыть GPUI, ADMC
11.2. Повторно $ gpupdate
11.3. Повторно # gpoa --loglevel 0
11.4. Повторно проверить в ADMC наличие вкладки LAPS и значения в ней (см. шаг 8)


12. Дополнительно: Проверить с клиента Windows в RSAT:

12.1. Ввести машину Windows 10 Pro 22H2 в домен.
12.2. Перенести машину в LAPSOU с помощью ADMC.
12.3. Войти на машине обычным доменным пользователем.
12.4. ПКМ на меню Пуск > открыть PowerShell от имени администратора
12.5. PS> gpupdate
12.6. PS> Add-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0 (указание версии обязательно)
12.7. PS> Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0
12.8. PS> Get-WindowsCapability -Online -Name Rsat* | Select-Object -Property Name, State, DisplayName
12.9. PS> dsa.msc
12.10. Перейти в samba.testdomain > LAPSOU > дважды нажать на компьютер > перейти на вкладку LAPS

(При работе с PowerShell иногда необходимо нажать Enter, чтобы увидеть дальнейший вывод.)


Фактический результат
=====================

6.1. При выполнении gpupdate cтолкнулся с тем, что сначала на том клиенте, где запускался ADMC (ALT Workstation), команда выполнилась успешно, но затем на остальных клиентах и на этом же клиенте начала происходить ошибка:

> $ gpupdate
> Apply group policies for computer.
> 2025-10-16 11:59:10.568|[E00024]| Error occured while running machine applier|{'applier_name': 'laps_applier', > 'msg': 'The DNS response does not contain an answer to the question: _ldap._tcp.dc._msdcs. IN SRV'}
>
> Apply group policies for testuser.


7. Атрибуты присутствуют, но значения пустые.


8. Вкладка LAPS отсутствует.


9. Происходит та же ошибка, что и у gpupdate (полный вывод с sisyphus - во вложении):

> # gpoa --loglevel 0
> ...
> 2025-10-16 13:25:00.328|[D00218]| Запущен обработчик LAPS|{}
> 2025-10-16 13:25:00.334|[E00024]| Ошибка во время работы applier для машины|{'applier_name': 'laps_applier', 'msg': 'The DNS response does not contain an answer to the question: _ldap._tcp.dc._msdcs. IN SRV'}


10. Не влияет на результат gpupdate/gpoa, и в ADMC не появляется вкладка LAPS.


11. Не влияет на результат gpupdate/gpoa, и в ADMC не появляется вкладка LAPS.


12.5. Обновление проходит без ошибок.
12.10. Вкладка присутствует, открывается без ошибок, но значения пустые (см. скриншот).

При выборе клиента Windows ситуация такая же (даже после запуска Invoke-LapsPolicyProcessing при проверке с Samba DC в [sisyphus]). В Win+R -> eventvwr -> Microsoft -> Windows -> LAPS -> Operational: "Начинается обработка политики LAPS.", "Политика LAPS настроена как disabled.", "Политика LAPS успешно обработана."


Дополнительно
=============

DNS-запись, о которой говорит gpupdate/gpoa, есть:

> # dig @dc.samba.testdomain _ldap._tcp.dc._msdcs.samba.testdomain SRV
> ...
> _ldap._tcp.dc._msdcs.samba.testdomain. 900 IN SRV 0 100 389 dc.samba.testdomain.


Версии пакетов
==============

# rpm -q samba gpupdate admc admx-basealt gpui libcng-dpapi libgkdi

[p11+394751]
ALT Education 11.0 x86_64 (KDE)
ALT Education 11.0 x86_64 (XFCE)
ALT Workstation 11.1 x86_64
ALT Workstation K 11.1.1 x86_64
ALT Server 11.0 x86_64 (minimal)

samba-4.21.8-alt4.x86_64
gpupdate-0.13.3-alt1.noarch
admc-0.20.0-alt2.x86_64
admx-basealt-0.5.0-alt1.noarch
gpui-0.2.55-alt1.x86_64
libcng-dpapi-0.0.2-alt3.x86_64
libgkdi-0.0.2-alt2.x86_64


[sisyphus]
ALT Education 11.0 x86_64 (KDE)
ALT Education 11.0 x86_64 (XFCE)
ALT Workstation 11.1 x86_64
ALT Workstation K 11.1.1 x86_64
ALT Server 11.0 x86_64 (minimal)

samba-4.21.8-alt4.x86_64
gpupdate-0.13.4-alt1.noarch
admc-0.22.0-alt1.x86_64
admx-basealt-0.6.0-alt1.noarch
gpui-0.2.55-alt1.x86_64
libcng-dpapi-0.0.4-alt1.x86_64
libgkdi-0.0.4-alt1.x86_64

Одинаковы только версии gpui и samba (т. к. 394751 c samba), остальные версии отличаются.

В sisyphus на Workstation дополнительно на текущий момент требуется обход для https://bugzilla.altlinux.org/56400 (`# apt-get install lightdm-gtk-greeter && systemctl disable gdm && systemctl enable lightdm && reboot`).

Created attachment 19795 [details]
RSAT LAPS пустой

Мы разобьём эту ошибку на 3 различных случая: p11, sisyphus, windows, так как во всех случаях присутствуют разные проблемы конфигурации тестового стенда.

Начну как не странно со стенда с Windows. У нас различаются настройки LAPS для машин с p11/sisyphus и клиентов windows. ADMX файлы и политики предоставляющие LAPS v2 для windows и p11/sisyphus взаимно не совместимы. 
Поэтому на клиенте с Windows вы получаете:
"Политика LAPS настроена как disabled."

Поэтому, на клиенте с Windows необходимо настроить LAPS для windows.

Для тестового стенда c клиентом Windows и сервером Samba предполагается что были установлены соответствующие обновления Windows:
    Windows 11 22H2 – KB5025239
    Windows 11 21H2 – KB5025224
    Windows 10 22H2 — KB5025221
    Windows Server 2022 – KB5025230
    Windows Server 2019 – KB5025229

И был установлен пакет Power Shell для LAPS.


Необходимо открыть RSAT для групповой политики LAPS на LAPSOU.
Редактировать политику и добавить групповые политики из раздела: 
Конфигурация компьютера -> Политики -> Административные Шаблоны -> Система  -> LAPS
Здесь нужно установить политики:
- Configure password backup directory: Active Directory
- Password Settings: 14 символов, смена каждые 30 дней
- Name of administrator account to manage: root
Применить изменения.

После этого нужно применить политику LAPS при помощи Power Shell:
Reset-LapsPassword -Verbose -Debug

Если всё

Откройте консоль ADUC и найдите компьютер, пароль которого вы хотите получить. В свойствах компьютера появилась новая вкладка LAPS.

Предыдущий комментарий отправился преждевременно, поэтому продолжение:

Для тестового стенда с p11/sisyphus не получится установить пароль LAPS из-за того что samba использует NDR32 для [MS-RPC], а Windows использует NDR64 для [MS-RPC] - библиотека python3 dpapi-cng используемая gpupdate умеет работать только с NDR64. Обновления были отправлены в gpupdate, и будут выпущены в одной из следующих версий.

Что касается ADMC - в sisyphus он поломан - при внедрении нового функционала был сломан LAPS - исправления подготавливаются.

ADMC из p11 должен корректно расшифровать и показать пароль LAPS - установленный на windows client.

Created attachment 19807 [details]
Предупреждение

(Ответ для august7147 на комментарий #6)
> Конфигурация компьютера -> Политики -> Административные Шаблоны -> Система
> -> LAPS

Подскажите, пожалуйста, для появления данного пункта при Samba DC на [p11+394751.3] необходимы ли какие-то дополнительные действия? Возможно, необходима более новая версия какого-то пакета? Возможно, admx-basealt-0.6.0-alt1 из задания [392520.3]?

Посмотрел как в ADMC, так и на клиенте Windows в `PS> gpme` -> LAPSOU samba.testdomain -> LAPS -> Конфигурация компьютера -> Политики -> Административные шаблоны -> Система, раздела LAPS нет.

При этом на клиенте Windows при открытии gpme через пару секунд отображается предупреждение и вместо "Административные шаблоны" становится написано "Административные шаблоны: определения политик (ADMX-файлы) получены из центрального хранилища." (см. скриншоты).

---

Использую Windows 10 22H2, обновлённый до июля 2023; обновление "Накопительное обновление для Windows 10 Version 22H2 для систем на базе процессоров x86, 2023 04 (KB5025221)" не применимо, скорее всего уже установлено (возможно, в составе других).

Установлены:

> 12.6. PS> Add-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0
> 12.7. PS> Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Created attachment 19808 [details]
Новое название раздела

Created attachment 19852 [details]
Попытка Update-LapsADSchema

Нашёл, что для появления раздела LAPS необходимо скопировать файлы:

%windir%\PolicyDefinitions -> \\samba.testdomain\SYSVOL\samba.testdomain\Policies\PolicyDefinitions
- LAPS.admx
- ru-RU\LAPS.adml


Это можно сделать с помощью PowerShell от имени администратора домена:

PS> Copy-Item "$Env:WinDir\PolicyDefinitions\LAPS.admx" -Destination "\\samba.testdomain\SYSVOL\samba.testdomain\Policies\PolicyDefinitions"

PS> Copy-Item "$Env:WinDir\PolicyDefinitions\ru-RU\LAPS.adml" -Destination "\\samba.testdomain\SYSVOL\samba.testdomain\Policies\PolicyDefinitions\ru-RU"

После этого в gpme появляется Конфигурация компьютера -> Политики -> Административные Шаблоны -> Система -> LAPS. (Предупреждение, упомянутое выше, остаётся.)

См.:
- https://learn.microsoft.com/en-us/answers/questions/1246788/group-policy-for-new-microsoft-laps

Проверяю дальше.

---

Также сначала попробовал Update-LapsADSchema, но он не работал (полный вывод прикладываю).

> ПРЕДУПРЕЖДЕНИЕ: System.DirectoryServices.Protocols.DirectoryOperationException: Сервер не может обработать запросы
> каталогов.
>    в System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation,
> ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut)
>    в System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
>    в Microsoft.Windows.LAPS.UpdateLapsADSchema.AddSchemaAttribute(String schemaAttributeDN, LAPSSchemaAttribute
> lapsSchemaAttribute)

Попробовал далее, но ни одна из команд

PS> Invoke-LapsPolicyProcessing
PS> Reset-LapsPassword -Verbose -Debug

не работает даже после задания политик, требуя расширения схемы, которое не работает (см. выше).

---

Также, в gpupdate отображется предупреждение:

> PS (admin)> gpupdate
> Выполняется обновление политики...
>
> Обновление политики для компьютера успешно завершено.
>
> При обработке политики компьютера возвращены следующие предупреждения:
>
> Windows не удалось применить параметры "Group Policy Files". Параметры "Group Policy Files" могут иметь свой собственный файл журнала. Щелкните ссылку "Дополнительные сведения".
> Windows не удалось применить параметры "Group Policy Ini Files". Параметры "Group Policy Ini Files" могут иметь свой собственный файл журнала. Щелкните ссылку "Дополнительные сведения".
> Windows не удалось применить параметры "Group Policy Registry". Параметры "Group Policy Registry" могут иметь свой собственный файл журнала. Щелкните ссылку "Дополнительные сведения".
> Обновление политики пользователя завершено успешно.
>
> Чтобы получить дополнительные сведения, просмотрите журнал событий или запустите GPRESULT /H GPReport.html из командной строки для просмотра сведений о результатах групповой политики.

Пробовал заново с [p11+394751.4] samba-4.21.9-alt1.x86_64.

В этот раз для обновления схемы использовал `PS> Update-LapsADSchema` вместо пакета `samba-extension-laps-v2-schema`.

Также указал `dsdb:schema update allowed = true` в `/etc/samba/smb.conf` на DC, чтобы была возможность обновить схему. Когда обновление схемы выполняет сама Samba, она умеет временно включать этот параметр, но Windows так делать не может.

1. Политика LAPS применилась не сразу, даже после PS> gpupdate. На следующий день активировалась. Это аналогично поведению LAPS при Windows AD DC.

2. | LAPS не удалось найти настроенную в настоящее время учетную запись локального администратора.
| Имя учетной записи: root
| Код ошибки: 0x80070002

Исправилось выполнением PS> net user /add root 1

3. | LAPS получил ошибку LDAP_INSUFFICIENT_RIGHTS при попытке обновить пароль с помощью атрибута пароля LAPS. Следует обновить разрешения для контейнера этого компьютера с помощью командлета Set-LapsADComputerSelfPermission, например:
| Set-LapsADComputerSelfPermission -Identity 'OU=LAPSOU,DC=samba,DC=testdomain'

Через некоторое время исправилась сама, командлет не выполнял.

До того как увидел эту ошибку в eventvwr, пробовал включить экспериментальные групповые политики и выдать разрешение согласно комментарий #1, но пунктов "Читать/Изменять свойство - LAPS Encrypted Password Attributes" нет.

4. | Сбой шифрования нового пароля.
| Код ошибки: 0x80090034
| Эта проблема может возникнуть, если корневой ключ KDS недоступен. Убедитесь, что корневой ключ KDS доступен, выполнив командлет PowerShell Get-KdsRootKey, и что поле EffectiveTime корневого ключа в настоящий момент допустимо.
| Если корневой ключ KDS отсутствует, добавьте его, выполнив командлет PowerShell Add-KdsRootKey с параметром -EffectiveImmediately. Предоставьте достаточно времени для репликации нового ключа в лесу.

Попробовал Get-KdsRootKey, ключ есть:

> AttributeOfWrongFormat :
> KeyValue               : {35, 213, 214, 242...}
> EffectiveTime          : 27.10.2025 3:52:03
> CreationTime           : 27.10.2025 13:57:03
> IsFormatValid          : True
> DomainController       : CN=DC,OU=Domain Controllers,DC=samba,DC=testdomain
> ServerConfiguration    : Microsoft.KeyDistributionService.Cmdlets.KdsServerConfiguration
> KeyId                  : 49422599-4034-ce01-c0f3-d7ca75e52aa0
> VersionNumber          : 1

Попробовал Add-KdsRootKey, добавился ещё один. Также попробовал выполнить и командлет из п. 3. Результат Invoke-LapsPolicyProcessing не поменялся.

1. Чтобы принудительно выполнить фоновое обновление всех параметров групповой политики независимо от того, изменились ли они, введите:

gpupdate /force


3. Set-LapsADComputerSelfPermission -Identity 'OU=LAPSOU,DC=samba,DC=testdomain' - обязательно должна быть выполнена, если не были установлены расширенные права на атрибуты LDAP через ADMC, иначе клиентская машина не сможет записывать и читать атрибуты.

4. Есть способ мгновенно выполнить сброс пароля LAPS на клиентской машине windows используя Power Shell для этого необходимо выполнить: Reset-LapsPassword -Debug -Verbose .

Ключи -Debug и -Verbose используются для получения расширенной отладочной информации.

- https://learn.microsoft.com/en-us/powershell/module/laps/reset-lapspassword?view=windowsserver2025-ps
- https://learn.microsoft.com/ru-ru/windows-server/administration/windows-commands/gpupdate

1. Спасибо.

3. ОК, уже выполнил в пункте 4.

4. Попробовал и Reset-LapsPassword -Debug -Verbose, показывает ту же ошибку 0x80090034.

Полный вывод (запускаю в PowerShell от имени администратора домена):

> PS C:\Windows\system32> Reset-LapsPassword -Verbose -Debug
> ПОДРОБНО: BeginProcessing started
> ПОДРОБНО: Verifying that current process is running as a local administrator
> ПОДРОБНО: Success: current process is running as a local administrator
> ПОДРОБНО: Verifying that current process is elevated
> ПОДРОБНО: Success: current process is elevated
> ПОДРОБНО: BeginProcessing completed
> ПОДРОБНО:
> ПОДРОБНО: ProcessRecord started
> ПОДРОБНО: Calling ResetPassword RPC method
> ПОДРОБНО: ResetPassword RPC method returned hr:0x80090034
>
> Подтверждение 2148073524 failed with hr:0x80090034
> [Y] Да - Y  [A] Да для всех - A  [H] Прервать команду - H  [S] Приостановить - S  [?] Справка (значением по умолчанию является "Y"):
>
> Reset-LapsPassword : 2148073524 failed with hr:0x80090034
> строка:1 знак:1
> + Reset-LapsPassword -Verbose -Debug
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + CategoryInfo
> : InvalidOperation: (:) [Reset-LapsPassword], LapsPowershellException
> + FullyQualifiedErrorId : 2148073524 failed with hr:0x80090034,Microsoft.Windows.LAPS.ResetLapsPassword
> ПОДРОБНО: ProcessRecord completed
> ПОДРОБНО:
> ПОДРОБНО: EndProcessing started
> ПОДРОБНО: EndProcessing completed
> ПОДРОБНО:

gpupdate-0.14.0-alt1
gpui-0.2.55-alt1

Для DC на Windows 2019 c обновлением KB5025229 проблему удалось решить, дополнив настройку следующим образом: 
Включить службу распространения ключей Майкрософт: Диспетчер серверов -> Средства -> Службы -> Служба распространения ключей (Майкрософт) -> Запустить

Расширение схемы должно выглядеть так:
PS C:\> Update-LapsADSchema
PS C:\> Set-LapsADComputerSelfPermission -Identity "OU=LAPSOU,DC=windowsad,DC=testdomain" 
PS C:\> Set-LapsADReadPasswordPermission -Identity "OU=LAPSOU,DC=windowsad,DC=testdomain" -AllowedPrincipals "WINDOWSAD\LapsPasswordReadersGroup"

После этого для пользователей, состоящих в группе "LapsPasswordReadersGroup" вкладка в ADMC появилась.

Для домена с DC на Alt Server не проверялось. В связи с тем, что там нет служб Майкрософт, оставляю баг открытым, пока не будет проверен домен Samba DC.