Поделиться через

Устранение неполадок локальной функции защиты паролем Microsoft Entra

  • Статья

После развертывания защиты паролей Microsoft Entra может потребоваться устранение неполадок. В этой статье подробно рассматриваются некоторые общие шаги по устранению неполадок.

Агенту контроллера домена не удается найти расположение прокси-сервера в каталоге

Основным симптомом этой проблемы является наличие событий 30017 в журнале событий администратора агента контроллера домена.

Обычно причина этой проблемы заключается в том, что прокси-сервер еще не зарегистрирован. Если прокси-сервер зарегистрирован, возможно, в связи с задержкой репликации AD он станет виден для конкретного агента контроллера домена с определенной задержкой.

Агенту контроллера домена не удается связаться с прокси-сервером

Основным симптомом этой проблемы является наличие событий 30018 в журнале событий администратора агента контроллера домена. Эта проблема может возникнуть по следующим причинам:

  1. Агент контроллера домена находится в изолированной части сети, которая не разрешает сетевое подключение к зарегистрированным прокси-серверам. Эта проблема может оказаться краткосрочной, если другие агенты контроллера домена могут обмениваться данными с прокси-сервером для скачивания политик паролей из Azure. После скачивания эти политики будут получены изолированным контроллером домена благодаря репликации файлов политики в общую папку sysvol.

  2. Прокси-компьютер блокирует доступ к конечной точке сопоставителя конечных точек RPC (порт 135).

    Установщик прокси-сервера защиты паролей Microsoft Entra автоматически создает правило входящего трафика брандмауэра Windows, позволяющее получить доступ к порту 135. Если это правило будет в дальнейшем удалено или отключено, агенты контроллера домена не смогут взаимодействовать с прокси-службой. Если встроенный брандмауэр Windows был отключен, чтобы вместо него использовался другой брандмауэр, необходимо настроить этот брандмауэр, разрешив в нем доступ к порту 135.

  3. Прокси-компьютер блокирует доступ к конечной точке RPC (динамической или статической), прослушиваемой прокси-службой.

    Установщик прокси-сервера защиты паролей Microsoft Entra автоматически создает правило входящего трафика брандмауэра Windows, которое позволяет получать доступ к любым входящим портам, прослушиваемым службой прокси-сервера защиты паролей Microsoft Entra. Если это правило будет в дальнейшем удалено или отключено, агенты контроллера домена не смогут взаимодействовать с прокси-службой. Если встроенный брандмауэр Windows отключен вместо другого продукта брандмауэра, необходимо настроить этот брандмауэр, чтобы разрешить доступ к любым входящим портам, прослушиваемым службой прокси-сервера Защиты паролей Майкрософт. Эту конфигурацию можно уточнить, если в прокси-службе настроено прослушивание определенного статического порта RPC (с помощью командлета Set-AzureADPasswordProtectionProxyConfiguration).

  4. Прокси-компьютер не настроен так, чтобы контроллерам домена был разрешен вход на компьютер. Это поведение контролируется с помощью назначения привилегии пользователя "Сетевой доступ к этому компьютеру". Эта привилегия должна быть предоставлена всем контроллерам домена во всех доменах леса. Этот параметр часто ограничивается в рамках более масштабных проектов по усилению защиты сети.

Прокси-службе не удается установить связь с Azure

  1. Убедитесь, что на прокси-компьютере есть подключение к конечным точкам, указанным в требованиях к развертыванию.

  2. Убедитесь, что лес и все прокси-серверы зарегистрированы в одном клиенте Azure.

    Чтобы проверить выполнение этого требования, запустите командлеты PowerShell Get-AzureADPasswordProtectionProxy и Get-AzureADPasswordProtectionDCAgent, а затем сравните свойство AzureTenant всех возвращенных элементов. Для правильной работы сообщаемое имя клиента должно быть одинаковым для всех агентов контроллера домена и прокси-серверов.

    В случае несоответствия регистрации клиента Azure эту проблему можно устранить, запуская командлеты PowerShell Register-AzureADPasswordProtectionProxy и (или) Register-AzureADPasswordProtectionForest по мере необходимости. При этом для всех регистраций следует использовать учетные данные из одного и того же клиента Azure.

Агенту контроллера домена не удалось зашифровать или расшифровать файлы политики паролей

Защита паролей Microsoft Entra имеет критически важную зависимость от функций шифрования и расшифровки, предоставляемых службой распространения ключей Майкрософт. Ошибки шифрования или расшифровки могут проявляться в виде различных симптомов и происходить по ряду причин.

  1. Убедитесь, что служба KDS включена и работает в домене на всех контроллерах домена с Windows Server 2012 и более поздних версий.

    По умолчанию для режима запуска службы KDS задано значение "Вручную" (запуск по триггеру). Такая конфигурация означает, что при первой попытке клиента использовать службу она запускается по запросу. Этот режим запуска службы по умолчанию является допустимым для работы защиты паролей Microsoft Entra.

    Если режим запуска службы KDS настроен на отключен, эта конфигурация должна быть исправлена до правильной работы защиты паролей Microsoft Entra.

    Наличие этой проблемы можно выявить с помощью простой проверки. Запустите службу KDS вручную с помощью консоли MMC для управления услугами или других средств управления (например, воспользуйтесь командой net start kdssvc в консоли командной строки). Служба KDS должна успешно запуститься и продолжать работать.

    Наиболее распространенной причиной невозможности запуска службы KDS является то, что объект контроллера домена Active Directory находится за пределами подразделения контроллеров домена по умолчанию. Эта конфигурация не поддерживается службой KDS и не является ограничением, введенным защитой паролей Microsoft Entra. Чтобы исправить это состояние, переместите объект контроллера домена в расположение в подразделении контроллеров домена по умолчанию.

  2. Проверьте совместимость при изменении формата зашифрованного буфера KDS с Windows Server 2012 R2 на Windows Server 2016.

    В Windows Server 2016 было внедрено исправление безопасности KDS, изменяющее формат зашифрованных буферов KDS. Иногда эти буферы не удается расшифровывать в Windows Server 2012 и Windows Server 2012 R2. Обратное направление допустимо. Буферы, зашифрованные KDS в Windows Server 2012 и Windows Server 2012 R2, всегда будут успешно расшифрованы в Windows Server 2016 и более поздних версиях. Если контроллеры домена в доменах Active Directory выполняют сочетание этих операционных систем, могут быть сообщены случайные ошибки расшифровки защиты паролей Microsoft Entra. Невозможно точно предсказать время или симптомы этих сбоев, учитывая характер исправления безопасности и учитывая, что он не детерминирован, который агент контроллера домена Microsoft Entra Password Protection DC Agent, на котором контроллер домена будет шифровать данные в определенное время.

    Для этой проблемы не существует обходного решения. Единственный вариант — не использовать сочетание таких несовместимых операционных систем в доменах Active Directory. Иными словами, следует запускать только контроллеры домена с Windows Server 2012 и Windows Server 2012 R2 ЛИБО только контроллеры домена с Windows Server 2016 и более новых версий.

Агент контроллера домена распознает лес как незарегистрированный

Симптомом этой проблемы является регистрация событий 30016 в канале администратора в агенте контроллера домена. Ниже приведена часть соответствующего сообщения в журнале.

The forest has not been registered with Azure. Password policies cannot be downloaded from Azure unless this is corrected.

Две возможные причины этой проблемы приведены ниже.

  1. Лес действительно не зарегистрирован. Чтобы устранить эту проблему, воспользуйтесь командой Register-AzureADPasswordProtectionForest, как описано в требованиях к развертыванию.
  2. Лес зарегистрирован, но агенту контроллера домена не удалось расшифровать данные его регистрации. Этот случай имеет ту же основную причину, что и проблема номер 2, описанная выше в разделе Агенту контроллера домена не удалось зашифровать или расшифровать файлы политики паролей. Эту теорию можно легко проверить, так как данная ошибка происходит только на агентах контроллеров домена с Windows Server 2012 или Windows Server 2012 R2, а на агентах контроллеров домена с Windows Server 2016 и более поздних версий она не наблюдается. Решение аналогично: обновите все контроллеры домена до Windows Server 2016 или более поздней версии.

Ненадежные пароли принимаются, хотя и не должны

Эта проблема может быть вызвана несколькими причинами.

  1. На агентах контроллера домена запущена общедоступная предварительная версия программного обеспечения с истекшим сроком действия. См. раздел Срок действия программного обеспечения агента контроллера домена общедоступной предварительной версии истек.

  2. Агентам контроллера домена не удается скачать политику или расшифровать имеющиеся политики. Возможные причины приведены в разделах выше.

  3. Режим принудительного применения политики паролей по-прежнему имеет значение "Аудит". Если эта конфигурация действует, перенастройка ее для принудительного применения с помощью портала защиты паролей Microsoft Entra. Дополнительные сведения см. в разделе Режимы работы.

  4. Политика паролей отключена. Если эта конфигурация действует, перенастроите ее, чтобы включить ее с помощью портала защиты паролей Microsoft Entra. Дополнительные сведения см. в разделе Режимы работы.

  5. Не на всех контроллерах домена в домене установлено программное обеспечение агента контроллера домена. В этом случае трудно убедиться, что во время операции смены пароля для удаленных клиентов Windows целевым является конкретный контроллер домена. Если вы считаете, что конкретный контроллер домена, на котором установлено программное обеспечение агента контроллера домена, успешно задан в качестве целевого, вы можете дополнительно это проверить, просмотрев журнал событий администратора агента контроллеров доменов. Независимо от результата, в нем будет зарегистрировано по крайней мере одно событие, фиксирующее результаты проверки пароля. Если для пользователя, чей пароль изменен, такое событие отсутствует, изменение пароля, скорее всего, было обработано другим контроллером домена.

    Альтернативный способ проверки — попробовать задать или изменить пароли, войдя непосредственно в контроллер домена, где установлено программное обеспечение агента контроллера домена. Этот метод не рекомендуется для доменов Active Directory в рабочей среде.

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

  6. Алгоритм проверки паролей фактически может работать должным образом. См. раздел Оценка паролей.

Ntdsutil.exe не удалось задать ненадежный пароль DSRM

Active Directory всегда проверяет новый пароль режима восстановления служб каталогов, чтобы убедиться, что он соответствует требованиям к сложности пароля домена; эта проверка также вызывает библиотеки dll фильтра паролей, такие как Защита паролей Microsoft Entra. Если новый пароль DSRM отклоняется, появляется следующее сообщение об ошибке:

C:\>ntdsutil.exe
ntdsutil: set dsrm password
Reset DSRM Administrator Password: reset password on server null
Please type password for DS Restore Mode Administrator Account: ********
Please confirm new password: ********
Setting password failed.
        WIN32 Error Code: 0xa91
        Error Message: Password doesn't meet the requirements of the filter dll's

Если Microsoft Entra Password Protection регистрирует события журнала событий проверки пароля для пароля Active Directory DSRM, ожидается, что сообщения журнала событий не будут содержать имя пользователя. Такое поведение связано с тем, что учетная запись DSRM — это локальная учетная запись, не входящая в фактический домен Active Directory.

Сбой повышения уровня реплики контроллера домена из-за ненадежного пароля DSRM

Во время процесса повышения уровня контроллера домена новый пароль режима восстановления служб каталогов будет отправлен в имеющийся контроллер домена в домене для проверки. Если новый пароль DSRM отклоняется, появляется следующее сообщение об ошибке:

Install-ADDSDomainController : Verification of prerequisites for Domain Controller promotion failed. The Directory Services Restore Mode password does not meet a requirement of the password filter(s). Supply a suitable password.

Как и в приведенной выше проблеме, любое событие проверки пароля Защиты паролем Microsoft Entra будет иметь пустые имена пользователей для этого сценария.

Сбой понижения уровня роли контроллера домена из-за ненадежного пароля локального администратора

Поддерживается понижение контроллера домена, который все еще запускает программное обеспечение агента контроллера. Администраторы должны знать, что программное обеспечение агента контроллера домена продолжает применять текущую политику паролей во время процедуры понижения. Новый пароль учетной записи локального администратора (указанный как часть операции понижения) проверяется, как и любой другой пароль. В ходе процедуры понижения контроллера домена корпорация Майкрософт рекомендует выбирать безопасные пароли для локальных учетных записей администратора.

После успешного понижения роли контроллера домена и перезагрузки и повторного запуска в качестве обычного рядового сервера программное обеспечение агента контроллера домена возвращается к работе в пассивном режиме. Затем его можно удалить в любое время.

Загрузка в режиме восстановления служб каталогов

Если контроллер домена загружен в режиме восстановления служб каталогов, библиотека DLL фильтра паролей агента контроллера домена обнаружит это состояние и отключит все проверки паролей или принудительные действия, независимо от текущей активной конфигурации политик. Библиотека DLL фильтра паролей агента контроллера домена регистрирует событие предупреждения 10023 в журнале событий администратора, например:

The password filter dll is loaded but the machine appears to be a domain controller that has been booted into Directory Services Repair Mode. All password change and set requests will be automatically approved. No further messages will be logged until after the next reboot.

Срок действия программного обеспечения агента контроллера домена общедоступной предварительной версии истек

В период общедоступной предварительной версии microsoft Entra Password Protection программное обеспечение агента контроллера домена было жестко закодировано, чтобы остановить обработку запросов на проверку паролей на следующие даты:

  • Версия 1.2.65.0 прекратила обработку запросов на проверку пароля 1 сентября 2019 года.
  • Версия 1.2.25.0 и более ранние прекратили обработку запросов на проверку пароля 1 июля 2019 года.

По мере приближения крайнего срока все версии агента контроллера домена с ограниченным временем выдавали событие 10021 в журнале событий администратора агента контроллера домена во время загрузки. Сообщение о нем выглядит следующим образом:

The password filter dll has successfully loaded and initialized.

The allowable trial period is nearing expiration. Once the trial period has expired, the password filter dll will no longer process passwords. Please contact Microsoft for a newer supported version of the software.

Expiration date:  9/01/2019 0:00:00 AM

This message will not be repeated until the next reboot.

После наступления крайнего срока все версии агента контроллера домена с ограниченным временем выдают событие 10022 в журнале событий администратора агента контроллера домена во время загрузки. Сообщение о нем выглядит следующим образом:

The password filter dll is loaded but the allowable trial period has expired. All password change and set requests will be automatically approved. Please contact Microsoft for a newer supported version of the software.

No further messages will be logged until after the next reboot.

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

Важно!

Корпорация Майкрософт рекомендует немедленно обновить общедоступные агенты контроллера домена с истекшим сроком действия до новейшей версии.

Агенты контроллеров домена можно легко обнаружить в среде, которую необходимо обновить, с помощью командлета Get-AzureADPasswordProtectionDCAgent, например:

PS C:\> Get-AzureADPasswordProtectionDCAgent

ServerFQDN            : bpl1.bpl.com
SoftwareVersion       : 1.2.125.0
Domain                : bpl.com
Forest                : bpl.com
PasswordPolicyDateUTC : 8/1/2019 9:18:05 PM
HeartbeatUTC          : 8/1/2019 10:00:00 PM
AzureTenant           : bpltest.onmicrosoft.com

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

PS C:\> $LatestAzureADPasswordProtectionVersion = "1.2.125.0"
PS C:\> Get-AzureADPasswordProtectionDCAgent | Where-Object {$_.SoftwareVersion -lt $LatestAzureADPasswordProtectionVersion}

Программное обеспечение прокси-сервера защиты паролей Microsoft Entra не ограничено временем в любой версии. Теме не менее корпорация Майкрософт рекомендует обновлять агенты контроллеров домена и прокси-серверов до последних версий по мере их выпуска. Командлет Get-AzureADPasswordProtectionProxy можно использовать для поиска агентов прокси-сервера, требующих обновления, аналогично приведенному выше примеру для агентов контроллеров домена.

Дополнительные сведения о конкретных процедурах обновления см. в разделах Обновление агента контроллера домена и Обновление службы прокси-сервера.

Аварийное исправление

Если служба агента контроллера домена вызывает проблемы, ее можно немедленно отключить. Библиотека DLL фильтрации паролей агента контроллера домена по-прежнему пытается вызвать нерабочую службу и регистрирует события предупреждения (10012, 10013), но все входящие пароли принимаются в течение этого времени. Затем служба агента контроллера домена также может быть настроена с помощью диспетчера управления службами Windows с типом запуска "Отключено" при необходимости.

Еще одной мерой исправления будет установка режима "Включить" на портале защиты паролей Microsoft Entra. Как только обновленная политика будет скачана, каждая служба агента контроллера домена перейдет в режим бездействия, в котором все пароли принимаются как есть. Дополнительные сведения см. в разделе Режимы работы.

Удаление

Если вы решили удалить программное обеспечение защиты паролей Microsoft Entra и очистить все связанные состояния из домена и леса, эту задачу можно выполнить, выполнив следующие действия.

Важно!

Важно выполнить эти шаги по порядку. Если какой-либо экземпляр службы прокси-сервера остается включенным, он будет периодически повторно создавать объект serviceConnectionPoint. Если какой-либо экземпляр службы агента контроллера домена остается включенным, он будет периодически повторно создавать объект serviceConnectionPoint и состояние sysvol.

  1. Удалите программное обеспечение прокси-сервера со всех компьютеров. Для этого шага не требуется перезагрузка компьютера.

  2. Удалите программное обеспечение агента контроллера домена со всех контроллеров. Для этого шага требуется перезагрузка компьютера.

  3. Вручную удалите все точки подключения службы прокси-сервера в каждом контексте именования домена. Расположение этих объектов можно обнаружить с помощью следующей команды PowerShell Active Directory:

    $scp = "serviceConnectionPoint"
$keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    Не опускайте звездочку (*) в конце значения переменной $keywords.

    Полученные объекты, найденные с помощью команды Get-ADObject, затем можно переадресовать в Remove-ADObject или удалить вручную.

  4. Вручную удалите все точки подключения агента контроллера домена в каждом контексте именования домена. В лесу может быть по одному такому объекту на контроллер домена, в зависимости от того, насколько широко развернуто программное обеспечение. Расположение этого объекта можно обнаружить с помощью следующей команды PowerShell Active Directory:

    $scp = "serviceConnectionPoint"
$keywords = "{2bac71e6-a293-4d5b-ba3b-50b995237946}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    Полученные объекты, найденные с помощью команды Get-ADObject, затем можно переадресовать в Remove-ADObject или удалить вручную.

    Не опускайте звездочку (*) в конце значения переменной $keywords.

  5. Вручную удалите состояние конфигурации уровня леса. Состояние конфигурации леса поддерживается в контейнере в контексте именования конфигурации Active Directory. Его можно обнаружить и удалить следующим образом:

    $passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-ADRootDSE).configurationNamingContext
Remove-ADObject -Recursive $passwordProtectionConfigContainer

  6. Вручную удалите все сведения о состоянии sysvol, удалив следующую папку и все ее содержимое:

    \\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtection

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

    %windir%\sysvol\domain\Policies\AzureADPasswordProtection

    Этот путь будет другим, если общий ресурс sysvol настроен в нестандартном местоположении.

Тестирование работоспособности с помощью командлетов PowerShell

Модуль PowerShell AzureADPasswordProtection включает в себя два связанных с работоспособностью командлета, с помощью которых можно убедиться, что программное обеспечение установлено и работает. Эти командлеты рекомендуется запускать после настройки нового развертывания, периодически в дальнейшем и при исследовании проблемы.

Каждый отдельный тест работоспособности возвращает базовый результат (пройден или не пройден), а также необязательное сообщение об ошибке. В случаях, когда причина сбоя неясна, найдите в журнале сообщения об ошибках, которые могут объяснить их причину. Возможно, полезно будет также включить текстовые сообщения журнала. Дополнительные сведения см. в разделе "Мониторинг защиты паролей Microsoft Entra".

Проверка работоспособности прокси-сервера

Командлет Test-AzureADPasswordProtectionProxyHealth поддерживает два теста на работоспособность, которые можно выполнять по отдельности. Третий режим позволяет выполнять все тесты, не требующие ввода параметров.

Проверка регистрации прокси-сервера

Этот тест проверяет, правильно ли зарегистрирован агент прокси-сервера в Azure и способен ли он пройти проверку подлинности в Azure. Результат успешного выполнения команды будет выглядеть следующим образом:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Passed

При обнаружении ошибки тест вернет неудачный результат и необязательное сообщение об ошибке. Ниже приведен пример одного из возможных сбоев.

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Failed No proxy certificates were found - please run the Register-AzureADPasswordProtectionProxy cmdlet to register the proxy.

Проверка прокси-сервера для сквозного подключения Azure

Этот тест является надмножеством теста -VerifyProxyRegistration. Для него требуется, чтобы прокси-агент был правильно зарегистрирован в Azure, мог пройти проверку подлинности в Azure и, наконец, запустил проверку успешного доставления сообщений в Azure, что свидетельствует о наличии полной сквозной связи.

Результат успешного выполнения команды будет выглядеть следующим образом:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyAzureConnectivity Passed

Проверка прокси-сервера во всех тестах

Этот режим позволяет выполнять массовый запуск всех поддерживаемых командлетом тестов, не требующих ввода параметров. Результат успешного выполнения команды будет выглядеть следующим образом:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyTLSConfiguration  Passed
VerifyProxyRegistration Passed
VerifyAzureConnectivity Passed

Тестирование работоспособности агента контроллера домена

Командлет Test-AzureADPasswordProtectionDCAgentHealth поддерживает несколько тестов на работоспособность, которые можно выполнять по отдельности. Третий режим позволяет выполнять все тесты, не требующие ввода параметров.

Тесты работоспособности базового агента контроллера домена

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

Тест на работоспособность агента контроллера домена Description
-VerifyPasswordFilterDll Проверяет, загружена ли в настоящее время библиотека DLL фильтра паролей и может ли она вызывать службу агента контроллера домена
-VerifyForestRegistration Проверяет, зарегистрирован ли лес
-VerifyEncryptionDecryption Проверяет, работает ли базовое шифрование и расшифровка при использовании службы Microsoft KDS
-VerifyDomainIsUsingDFSR Проверяет, использует ли текущий домен DFSR для репликации sysvol
-VerifyAzureConnectivity Проверяет, работает ли сквозная связь с Azure при использовании любого доступного прокси-сервера

Ниже приведен пример успешного выполнения теста -VerifyPasswordFilterDll. В случае успеха другие тесты будут выглядеть аналогично.

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyPasswordFilterDll Passed

Проверка агента контроллера домена во всех тестах

Этот режим позволяет выполнять массовый запуск всех поддерживаемых командлетом тестов, не требующих ввода параметров. Результат успешного выполнения команды будет выглядеть следующим образом:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

DiagnosticName             Result AdditionalInfo
--------------             ------ --------------
VerifyPasswordFilterDll    Passed
VerifyForestRegistration   Passed
VerifyEncryptionDecryption Passed
VerifyDomainIsUsingDFSR    Passed
VerifyAzureConnectivity    Passed

Тестирование подключения с использованием конкретных прокси-серверов

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

Проверка подключения между агентом контроллера домена и конкретным прокси-сервером

Этот тест проверяет подключение на первом участке канала связи от агента контроллера домена к прокси-серверу. Он проверяет, получает ли прокси-сервер вызов, но обмен данными с Azure при этом не предусмотрен. Успешное выполнение дает следующий результат:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Passed

Ниже приведен пример состояния сбоя, при котором была остановлена служба прокси-сервера, запущенная на целевом сервере.

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Failed The RPC endpoint mapper on the specified proxy returned no results; please check that the proxy service is running on that server.

Проверка подключения между агентом контроллера домена и Azure (с использованием конкретного прокси-сервера)

Этот тест проверяет полное сквозное подключение между агентом контроллера домена и Azure при использовании определенного прокси-сервера. Успешное выполнение дает следующий результат:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com

DiagnosticName                          Result AdditionalInfo
--------------                          ------ --------------
VerifyAzureConnectivityViaSpecificProxy Passed

Следующие шаги

Часто задаваемые вопросы о защите паролей Microsoft Entra

Для получения дополнительной информации о глобальном и пользовательском запрещенных списках паролей см. статью Запрет неверных паролей в организации.