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

Какие рекомендации следует предоставить пользователям о том, как выбрать безопасный пароль?

В настоящее время это руководство Майкрософт можно найти по следующей ссылке:

Руководство по паролям

Поддерживается ли локальная защита паролей Microsoft Entra в недоступных облаках?

Локальная защита паролей Microsoft Entra поддерживается как в глобальных, так и Azure для государственных организаций облаках Azure.

Центр администрирования Microsoft Entra позволяет изменять локальную конфигурацию "Защита паролем для Windows Server Active Directory" в не поддерживаемых облаках; такие изменения сохраняются, но никогда не вступают в силу. Регистрация локальных прокси-агентов или лесов не поддерживается в не поддерживаемых облаках, и любые такие попытки регистрации всегда завершаются ошибкой.

Как применить преимущества защиты паролей Microsoft Entra к подмножество локальных пользователей?

Не поддерживается. После развертывания и включения защита паролей Microsoft Entra применяется одинаково ко всем пользователям.

Какова разница между изменением пароля и заданием пароля (или его сбросом)?

Изменение пароля происходит, когда пользователь выбирает новый пароль после подтверждения старого пароля. Например, изменение пароля происходит тогда, когда пользователь входит в Windows, а затем ему предлагается выбрать новый пароль.

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

Политика проверки паролей работает одинаково, независимо от того, выполняется ли изменение или задание пароля. Служба агента контроллера домена Защиты паролей Microsoft Entra регистрирует различные события, чтобы сообщить, была ли выполнена операция изменения пароля или задания. См . сведения о мониторинге и ведении журнала защиты паролей Microsoft Entra.

Проверяет ли защита паролей Майкрософт существующие пароли после установки?

Нет. Защита паролей Microsoft Entra может применять только политику паролей для паролей с открытым текстом во время операции изменения или задания пароля. После принятия пароля Active Directory сохраняются только хэши, относящиеся к протоколу проверки подлинности. Пароль с четким текстом никогда не сохраняется, поэтому защита паролей Microsoft Entra не может проверить существующие пароли.

После первоначального развертывания Защиты паролей Microsoft Entra все пользователи и учетные записи в конечном итоге начнут использовать проверенный паролем microsoft Entra Password Protection, так как срок действия существующих паролей истекает обычно с течением времени. При необходимости вы можете ускорить этот процесс с помощью однократного истечения срока действия паролей учетной записи пользователя.

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

Почему при попытке задать ненадежный пароль с помощью оснастки "Управление пользователями и компьютерами" в Active Directory регистрируются дублирующиеся события отклонения паролей?

Оснастка управления Пользователи и компьютеры Active Directory сначала пытается задать новый пароль с помощью протокола Kerberos. При сбое оснастка выполняет вторую попытку задать пароль с помощью устаревшего протокола (SAM RPC). Используемые протоколы не важны. Если новый пароль считается слабым в службе защиты паролей Microsoft Entra, это действие создает два набора событий отказа от сброса пароля.

Почему события проверки паролей в Microsoft Entra Password Protection регистрируются с пустым именем пользователя?

Active Directory поддерживает возможность проверки пароля, чтобы узнать, соответствует ли он текущим требованиям к сложности пароля для домена, например с помощью API NetValidatePasswordPolicy. При проверке пароля таким образом тестирование также включает проверку по продуктам dll на основе паролей, например Microsoft Entra Password Protection, но имена пользователей, передаваемые в библиотеку dll фильтра паролей, пусты. В этом сценарии Защита паролей Microsoft Entra по-прежнему проверяет пароль с помощью политики паролей в настоящее время и выдает сообщение журнала событий для записи результата. Однако в сообщении журнала событий будут пустые поля имени пользователя.

У меня есть гибридные пользователи, которые пытаются изменить пароль в идентификаторе Microsoft Entra ID и получают ответ "Мы видели этот пароль слишком много раз раньше. Выберите что-нибудь, что сложнее угадать." Почему в этих случаях в локальной среде не отображаются сведения о попытке проверки?

Когда гибридный пользователь изменяет пароль в идентификаторе Microsoft Entra, независимо от того, используется ли Microsoft Entra SSPR, MyAccount или другой механизм изменения пароля Microsoft Entra, их пароль оценивается по глобальным и пользовательским спискам запрещенных паролей в облаке. Когда пароль достигает Active Directory с помощью обратной записи паролей, он уже проверен в идентификаторе Microsoft Entra.

Сбросы паролей и изменения, инициированные в идентификаторе Microsoft Entra, которые не прошли проверку для гибридных пользователей, можно найти в журналах аудита Microsoft Entra. См. раздел "Устранение неполадок самостоятельного сброса пароля" в идентификаторе Microsoft Entra.

Поддерживается ли она для установки Защиты паролей Microsoft Entra параллельно с другими продуктами на основе фильтров паролей?

Да. Поддержка нескольких зарегистрированных библиотек dll фильтра паролей является основной функцией Windows и не связана с защитой паролей Microsoft Entra. Все зарегистрированные библиотеки DLL для фильтрации по паролю должны подтвердить пароль, прежде чем он будет принят.

Как развернуть и настроить защиту паролей Microsoft Entra в среде Active Directory без использования Azure?

Не поддерживается. Защита паролей Microsoft Entra — это функция Azure, которая поддерживает расширение в локальная служба Active Directory среде.

Как изменить содержимое политики на уровне Active Directory?

Не поддерживается. Политику можно администрировать только с помощью Центра администрирования Microsoft Entra. См. также предыдущий вопрос.

Почему для репликации SYSVOL требуется DFSR?

Технология FRS (предшествующая технологии DFSR) имеет множество известных проблем и полностью не поддерживается в новых версиях Windows Server Active Directory. Нулевое тестирование защиты паролей Microsoft Entra выполняется в доменах, настроенных FRS.

Дополнительные сведения приведены в следующих статьях:

The Case for Migrating sysvol replication to DFSR (Вариант переноса репликации SYSVOL в DFSR)

The End is Nigh for FRS (Близится конец FRS)

Если домен еще не использует DFSR, необходимо перенести его для использования DFSR перед установкой Защиты паролей Microsoft Entra. Дополнительные сведения см. по следующей ссылке.

Руководство по миграции с репликацией для SYSVOL: репликация FRS в DFS

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

Точное использование пространства зависит от таких факторов, как количество и длина запрещенных маркеров в глобальном списке запрещенных маркеров Майкрософт и настраиваемом списке каждого клиента, а также накладные расходы на шифрование. Эти списки, вероятно, будут расширяться в будущем. Учитывая это, разумное ожидание заключается в том, что функция требует не менее пяти (5) мегабайт пространства в общей папке sysvol домена.

Почему для установки или обновления программного обеспечения агента контроллера домена требуется перезагрузка?

Это требование связано с ключевым механизмом Windows.

Можно ли настроить агент контроллера домена для использования конкретного прокси-сервера?

№ Так как прокси-сервер не учитывает состояние, не важно, какой конкретный прокси-сервер используется.

Хорошо ли развернуть службу прокси-сервера защиты паролей Microsoft Entra параллельно с другими службами, такими как Microsoft Entra Connect?

Да. Служба прокси-сервера защиты паролей Microsoft Entra и Microsoft Entra Connect никогда не должны конфликтовать напрямую друг с другом.

К сожалению, программное обеспечение microsoft Entra Password Protection Proxy устанавливает версию службы обновления агента Microsoft Entra Connect, несовместимую с версией, установленной программным обеспечением прокси приложения Microsoft Entra. Такая несовместимость может привести к тому, что службе обновления агента не удастся связаться с Azure для обновления программного обеспечения. Не рекомендуется устанавливать прокси-сервер защиты паролей Microsoft Entra и прокси приложения Microsoft Entra на том же компьютере.

В каком порядке следует устанавливать и регистрировать агенты контроллеров домена и прокси-серверы?

Поддерживается любой порядок установки прокси-агента, агента контроллера домена, регистрации леса и регистрация прокси-сервера.

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

Служба агента dc agent защиты паролей Microsoft Entra password Protection не должна существенно влиять на производительность контроллера домена в существующем работоспособном развертывании Active Directory.

Для большинства развертываний Active Directory операции изменения пароля составляют небольшую долю общей рабочей нагрузки на любом конкретном контроллере домена. Например, представьте домен Active Directory с 10 000 учетными записями пользователей и политикой MaxPasswordAge, установленной в 30 дней. В среднем этот домен видит 10000/30=~333 операции изменения пароля каждый день, что является незначительным числом операций даже для одного контроллера домена. Рассмотрим потенциальный наихудший сценарий: предположим, что эти ~333 смены пароля на одном контроллере домена произошли за один час. Например, этот сценарий может возникнуть, когда много сотрудников приходят на работу утром в понедельник. Даже в этом случае мы по-прежнему просматриваем ~333/60 минут = шесть изменений паролей в минуту, что снова не является значительной нагрузкой.

Однако если текущие контроллеры домена уже работают на ограниченном уровне производительности (например, максимальное число в отношении ЦП, дискового пространства, операций ввода-вывода и т. д.), рекомендуется добавить дополнительные контроллеры домена или расширить доступное место на диске перед развертыванием этой функции. См. предыдущий вопрос об использовании пространства на диске sysvol выше.

Я хочу проверить защиту паролей Microsoft Entra на нескольких контроллерах домена. Можно ли принудительно применять изменения пароля пользователя для использования этих конкретных контроллеров домена?

№ Клиентская ОС Windows определяет, какой контроллер домена используется при изменении пароля пользователем. Контроллер домена выбирается на основе таких факторов, как назначение сайта и подсети Active Directory, конфигурация сети для конкретной среды и т. д. Защита паролей Microsoft Entra не контролирует эти факторы и не может повлиять на то, какой контроллер домена выбран для изменения пароля пользователя.

Один из способов частично достичь этой цели заключается в развертывании защиты паролей Microsoft Entra на всех контроллерах домена на определенном сайте Active Directory. Этот подход обеспечивает разумное покрытие для клиентов Windows, назначенных этому сайту, и для пользователей, которые входят в эти клиенты и изменяют свои пароли.

Если установить службу агента dc agent защиты паролей Microsoft Entra на только основной контроллер домена (PDC), все остальные контроллеры домена в домене также будут защищены?

№ Когда пароль пользователя изменяется на контроллере домена, отличном от основного, открытый пароль никогда не отправляется на основной контроллер домена (эта идея является распространенным заблуждением). Когда новый пароль будет принят на данном контроллере домена, этот контроллер домена начнет использовать его, чтобы создавать различные хэши этого пароля для конкретного протокола аутентификации, а затем сохранять их в каталоге. Пароль с четким текстом не сохраняется. Затем обновленные хэши реплицируются в этот основной контроллер домена. В некоторых случаях пароли пользователей могут быть изменены непосредственно на основном контроллере домена в зависимости от различных факторов, таких как топология сети и структура сайта Active Directory. (См. предыдущий вопрос.)

В итоге развертывание службы агента КОНТРОЛЛЕРа домена защиты паролей Microsoft Entra в PDC требуется для достижения 100 % покрытия безопасности функции в домене. Развертывание функции только на PDC не обеспечивает преимущества безопасности защиты паролей Microsoft Entra для других контроллеров домена.

Почему настраиваемая интеллектуальная блокировка не работает даже после установки агентов в локальной среде Active Directory?

Настраиваемая смарт-блокировка поддерживается только в идентификаторе Microsoft Entra. Изменения настраиваемых параметров интеллектуальной блокировки в Центре администрирования Microsoft Entra не влияют на среду локальная служба Active Directory даже с установленными агентами.

Доступен ли пакет управления System Center Operations Manager для защиты паролей Microsoft Entra?

№

Почему идентификатор Microsoft Entra по-прежнему отклоняет слабые пароли, даже если политика настроена в режиме аудита?

Режим аудита поддерживается только в локальной среде Active Directory. Идентификатор Microsoft Entra неявно всегда находится в режиме принудительного применения при оценке паролей.

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

№ Сообщение об ошибке, отображаемое пользователям, когда пароль отклонен контроллером домена, управляется клиентским компьютером, а не контроллером домена. Это происходит, если пароль отклоняется политиками паролей Active Directory по умолчанию или решением на основе фильтра паролей, например Microsoft Entra Password Protection.

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

Зачем нужно выполнять эти действия? Существует несколько факторов, которые затрудняют выполнение управляемого, повторяемого тестирования паролей в среде локальная служба Active Directory:

• Политика паролей настроена и хранится в Azure, а копии политики периодически синхронизируются локальными агентами контроллера домена с помощью механизма опроса. Задержка, характерная для данного цикла опроса, может вызвать путаницу. Например, если вы настроили политику в Azure, но забыли синхронизировать ее с агентом контроллера домена, тесты могут не дать ожидаемых результатов. В настоящее время интервал опроса задан жестко и составляет один час, однако ожидание изменений политики может быть разным для интерактивного сценария тестирования.
• После синхронизации новой политики паролей с контроллером домена возникает дополнительная задержка при репликации на другие контроллеры домена. Эти задержки могут вызвать непредвиденные результаты, если проверить изменение пароля на контроллере домена, который не получил последнюю версию политики.
• Проверка изменений паролей с помощью пользовательского интерфейса не гарантирует точность результатов. Например, легко ввести недопустимый пароль в пользовательский интерфейс, особенно так как большинство пользовательских интерфейсов паролей скрывают входные данные пользователя (например, windows CTRL-ALT-Delete —> изменение пользовательского интерфейса пароля).
• Невозможно строго контролировать, какой контроллер домена используется при тестировании изменений паролей от клиентов, присоединенных к домену. Ос клиента Windows выбирает контроллер домена на основе таких факторов, как назначения сайта и подсети Active Directory, конфигурация сети для конкретной среды и т. д.

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

В следующих шагах предполагается, что агент контроллера домена установлен по крайней мере на одном контроллере домена, установлен по крайней мере один прокси-сервер и зарегистрирован как прокси,так и лес.

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

2. Откройте средство "Просмотр событий" и перейдите к разделу Журнал событий администратора агента контроллера домена.

3. Откройте окно командной строки с повышенными привилегиями.

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

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

   net.exe user <testuseraccountname> /add <password>
   

   Предположим, что мы создали тестовую учетную запись с именем ContosoUser, например:

   net.exe user ContosoUser /add <password>
   

5. Войдите в Центр администрирования Microsoft Entra как минимум администратор проверки подлинности.

6. Перейдите к методам > проверки подлинности защиты > паролей.

7. Измените политику защиты паролей Microsoft Entra при необходимости для тестирования, которое требуется выполнить. Например, можно выбрать режим принудительного применения или режим аудита или изменить список запрещенных терминов в списке заданных запрещенных паролей.

8. Синхронизируйте новую политику, остановив и перезапустив службу агента контроллера домена.

   Это действие можно выполнить различными способами. Один из способов — использовать административную консоль управления службами, щелкнув правой кнопкой мыши службу агента dc agent Защиты паролей Microsoft Entra и выбрав "Перезапустить". Другой способ подразумевает использование командной строки, как показано ниже.

   net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent
   

9. Обратитесь к средству "Просмотр событий", чтобы убедиться, что новая политика загружена.

   Каждый раз, когда служба агента контроллера домена останавливается и запускается, должно отображаться два события 30006, выданных в случае закрытия. Первое событие 30006 будет отражать политику, которая была кэширована на диск на общем ресурсе Sysvol. Второе событие 30006 (если оно есть) должно иметь обновленную политику клиента, и, если оно есть, оно будет отражать политику, скачанную из Azure. Значение даты политики клиента в настоящее время кодируется для вывода приблизительной метки времени загрузки политики из Azure.

   Если второе событие 30006 не отображается, перед продолжением необходимо устранить проблему.

   События 30006 будут выглядеть так, как в следующем примере.

   The service is now enforcing the following Azure password policy.
   
   Enabled: 1
   AuditOnly: 0
   Global policy date: ‎2018‎-‎05‎-‎15T00:00:00.000000000Z
   Tenant policy date: ‎2018‎-‎06‎-‎10T20:15:24.432457600Z
   Enforce tenant policy: 1
   

   Например, изменение режима принудительного и аудита приведет к изменению флага AuditOnly (политика, указанная с помощью AuditOnly=0, находится в режиме принудительного применения). Изменения в пользовательском списке запрещенных паролей не отражаются непосредственно в приведенном выше событии 30006 и не регистрируются ни в другом месте по соображениям безопасности. После этого изменения политика успешно скачивание политики из Azure также будет включать измененный пользовательский список запрещенных паролей.

10. Запустите тест, попытавшись сбросить новый пароль учетной записи тестового пользователя.

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

    net.exe user ContosoUser <password>
    

    После выполнения команды можно получить дополнительные сведения о результатах выполнения команды, выполнив поиск в средстве просмотра событий. События результатов проверки паролей описаны в разделе журнала событий администратора агента контроллера домена. Эти события будут использоваться для проверки результатов теста в дополнение к интерактивным выходным данным из команд net.exe.

    Давайте рассмотрим пример: попытка задать пароль, который находится в глобальном списке запрещенных паролей Майкрософт (обратите внимание, что этот список не задокументирован, однако мы можем протестировать его в отношении известного запрещенного термина). В этом примере предполагается, что вы настроили политику на работу в режиме принудительного применения и оставили список заданных запрещенных паролей пустым.

    net.exe user ContosoUser PassWord
    The password doesn't meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements.
    
    More help is available by typing NET HELPMSG 2245.
    

    В соответствии с документацией, поскольку наш тест был операцией сброса пароля, отобразятся события 10017 и 30005 для пользователя ContosoUser.

    Событие 10017 должно выглядеть так, как показано в этом примере.

    The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message.
    
    UserName: ContosoUser
    FullName: 
    

    Событие 30005 должно выглядеть так, как показано в этом примере.

    The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy.
    
    UserName: ContosoUser
    FullName: 
    

    Неплохо! Теперь попробуем еще один пример. Теперь мы попытаемся задать пароль, запрещенный настраиваемым списком запрещенных, пока политика находится в режиме аудита. В этом примере предполагается, что вы выполнили следующие действия: настроили политику в режиме аудита, добавили термин "lachrymose" в настраиваемый список запрещенных паролей и синхронизировали результирующая новая политика с контроллером домена путем велоспорта службы агента контроллера домена, как описано ранее.

    Теперь зададим вариант запрещенного пароля.

    net.exe user ContosoUser LaChRymoSE!1
    The command completed successfully.
    

    Помните, что в этот раз все удалось, поскольку политика находится в режиме аудита. Отобразятся события 10025 и 30007 для пользователя ContosoUser.

    Событие 10025 должно выглядеть так, как показано в этом примере.

    The reset password for the specified user would normally have been rejected because it didn't comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details.
    
    UserName: ContosoUser
    FullName: 
    

    Событие 30007 должно выглядеть так, как показано в этом примере.

    The reset password for the specified user would normally be rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.
    
    UserName: ContosoUser
    FullName: 
    

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

Мы рассмотрели процедуры, позволяющие выполнять контролируемое тестирование поведения проверки паролей Microsoft Entra Password Protection. Сброс паролей пользователей из командной строки непосредственно на контроллере домена может показаться нечетным средством выполнения такого тестирования, но как описано ранее, предназначено для получения повторяемых результатов. При тестировании различных паролей учитывайте алгоритм оценки паролей, так как это может помочь объяснить результаты, которые вы не ожидали.

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

Защита паролей Microsoft Entra теперь общедоступна!

Руководство по защите фишинга электронной почты— часть 15. Реализация службы защиты паролей Microsoft Entra (для локальной среды!)

Защита паролей Microsoft Entra и Smart Lockout теперь доступны в общедоступной предварительной версии!

Если вы хотите узнать больше о защите паролей Microsoft Entra и его развертывании, можно использовать упреждающая служба Майкрософт. Эта служба доступна клиентам с контрактом поддержки Premier или Unified. Служба называется Идентификатором Microsoft Entra: Защита паролем. Свяжитесь со своим менеджером по обеспечению успеха клиента, чтобы получить дополнительные сведения.

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

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

Развертывание защиты паролей Microsoft Entra