Руководство по развертыванию доверия Для облака Kerberos

В этой статье описаны Windows Hello для бизнеса функциональные возможности или сценарии, которые применяются к:


Требования

Перед началом развертывания ознакомьтесь с требованиями, описанными в статье Планирование Windows Hello для бизнеса развертывания.

Перед началом работы убедитесь, что выполнены следующие требования:

Важно.

При реализации облачной модели развертывания доверия Kerberos необходимо убедиться, что на каждом сайте Active Directory имеется достаточное количество контроллеров домена чтения и записи, где пользователи будут выполнять проверку подлинности с помощью Windows Hello для бизнеса. Дополнительные сведения см. в статье Планирование емкости для Active Directory.

Шаги развертывания

После выполнения предварительных требований развертывание Windows Hello для бизнеса состоит из следующих шагов:

Развертывание Microsoft Entra Kerberos

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

Если вы еще не развернули Microsoft Entra Kerberos, следуйте инструкциям в документации по включению входа с помощью ключа безопасности без пароля. На этой странице содержатся сведения об установке и использовании модуля PowerShell Microsoft Entra Kerberos. Используйте модуль, чтобы создать объект сервера Kerberos Microsoft Entra для доменов, в которых вы хотите использовать Windows Hello для бизнеса облачное доверие Kerberos.

Microsoft Entra проверки подлинности kerberos и облачной проверки подлинности Kerberos

Если Microsoft Entra Kerberos включен в домене Active Directory, в домене создается объект-компьютер AzureADKerberos. Этот объект:

  • Отображается как объект контроллера домена только для чтения (RODC), но не связан с физическими серверами.

  • Используется только Microsoft Entra ID для создания TGT для домена Active Directory.

    Примечание.

    Аналогичные правила и ограничения, используемые для RODC, применяются к объекту-компьютеру AzureADKerberos. Например, пользователи, которые являются прямыми или непрямыми членами привилегированных встроенных групп безопасности, не смогут использовать облачное доверие Kerberos.

Снимок экрана: консоль Пользователи и компьютеры Active Directory с объектом-компьютером, представляющим сервер Kerberos Microsoft Entra.

Дополнительные сведения о том, как Microsoft Entra Kerberos работает с Windows Hello для бизнеса облачным доверием Kerberos, см. в техническом обзоре Windows Hello для бизнеса проверки подлинности.

Примечание.

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

Из-за возможных векторов атак из Microsoft Entra ID в Active Directory не рекомендуется разблокировать эти учетные записи, ослабляя политику репликации паролей объекта CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>компьютера .

Настройка параметров политик Windows Hello для бизнеса

После настройки объекта Kerberos Microsoft Entra необходимо включить и настроить Windows Hello для бизнеса для использования облачного доверия Kerberos. Для настройки Windows Hello для бизнеса в облачной модели доверия Kerberos требуются два параметра политики:

Другой необязательный, но рекомендуемый параметр политики:

Важно.

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

В следующих инструкциях объясняется, как настроить устройства с помощью Microsoft Intune или групповой политики (GPO).

Примечание.

Сведения о различных параметрах, предлагаемых Microsoft Intune для настройки Windows Hello для бизнеса, см. в статье Настройка Windows Hello для бизнеса с помощью Microsoft Intune.

Если политика Intune на уровне клиента включена и настроена в соответствии с вашими потребностями, необходимо только включить параметр политики Use Cloud Trust For On Prem Auth. В противном случае необходимо настроить оба параметра.

Чтобы настроить устройства с помощью Microsoft Intune, создайте политику каталога параметров и используйте следующие параметры:

Категория Имя параметра Значение
Windows Hello для бизнеса Использование Passport для работы true
Windows Hello для бизнеса Использование доверия к облаку при предварительной проверке подлинности Enabled
Windows Hello для бизнеса Требовать устройство безопасности true

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

Кроме того, можно настроить устройства с помощью настраиваемой политики с помощью поставщика CSP PassportForWork.

Параметр
- OMA-URI:./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork
- Тип данных:bool
- Значение:True
- OMA-URI:./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
- Тип данных:bool
- Значение:True
- OMA-URI:./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice
- Тип данных:bool
- Значение:True

При развертывании конфигурации Windows Hello для бизнеса с помощью групповая политика и Intune приоритет имеют параметры групповая политика, а параметры Intune игнорируются. Дополнительные сведения о конфликтах политик см. в разделе Конфликты политик из нескольких источников политик.

Дополнительные параметры политики можно настроить для управления поведением Windows Hello для бизнеса. Дополнительные сведения см. в разделе параметры политики Windows Hello для бизнеса.

Регистрация в Windows Hello для бизнеса

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

Состояние необходимых проверка можно определить, просмотрев журнал администратора регистрации устройств пользователей в разделе Журналы> приложений и службMicrosoft>Windows.
Эти сведения также доступны с помощью dsregcmd.exe /status команды из консоли. Дополнительные сведения см. в разделе dsregcmd.

Предварительный компонент доверия Kerberos в облаке проверка определяет, имеет ли пользователь частичный TGT, прежде чем разрешить подготовку. Цель этого проверка — проверить, настроен ли Microsoft Entra Kerberos для домена и клиента пользователя. Если настроен Microsoft Entra Kerberos, пользователь получает частичное TGT во время входа с помощью одного из других методов разблокировки. Этот проверка имеет три состояния: "Да", "Нет" и "Не протестировано". Состояние "Не протестировано" отображается, если политика не применяет доверие к облачную службу Kerberos или устройство Microsoft Entra присоединено.

Примечание.

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

Взаимодействие с пользователем

После входа пользователя начинается процесс регистрации Windows Hello для бизнеса:

  1. Если устройство поддерживает биометрическую проверку подлинности, пользователю будет предложено настроить биометрический жест. Этот жест можно использовать для разблокировки устройства и проверки подлинности для ресурсов, которым требуется Windows Hello для бизнеса. Пользователь может пропустить этот шаг, если не хочет настраивать биометрический жест
  2. Пользователю будет предложено использовать Windows Hello с учетной записью организации. Пользователь нажимает кнопку ОК.
  3. Поток подготовки переходит к части регистрации с многофакторной проверкой подлинности. Подготовка информирует пользователя о том, что он активно пытается связаться с пользователем через настроенную форму MFA. Процесс подготовки не продолжается до тех пор, пока проверка подлинности не будет выполнена успешно, не произойдет сбой или не истекает время ожидания. Сбой или истечение времени ожидания MFA приводит к ошибке и просит пользователя повторить попытку.
  4. После успешной многофакторной идентификации в рамках процесса подготовки пользователь получает запрос на создание и проверку PIN-кода. Этот ПИН-код должен соблюдать все политики сложности ПИН-кода, настроенные на устройстве.
  5. На завершающем этапе подготовки служба Windows Hello для бизнеса запрашивает пару асимметричных ключей для пользователя, предпочтительно (или обязательно, если этого явно требует политика) от доверенного платформенного модуля. После получения пары ключей Windows взаимодействует с поставщиком удостоверений для регистрации открытого ключа. После завершения регистрации ключа Windows Hello для бизнеса подготовки уведомляет пользователя о том, что он может использовать свой ПИН-код для входа. Пользователь может закрыть приложение подготовки и получить доступ к рабочему столу.

После завершения регистрации с облачным доверием Kerberos для входа можно сразу же использовать жест Windows Hello. На Microsoft Entra устройстве с гибридным присоединением для первого использования ПИН-кода требуется прямой видимость контроллера домена. После входа пользователя или разблокировки с контроллером домена кэшированный вход можно использовать для последующих разблокировок без прямой видимости или сетевого подключения.

После регистрации Microsoft Entra Connect синхронизирует ключ пользователя из Microsoft Entra ID в Active Directory.

Схемы последовательностей

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

Чтобы лучше понять потоки проверки подлинности, просмотрите следующую схему последовательностей:

Переход с модели развертывания доверия к ключу на облачную модель доверия Kerberos

Если вы развернули Windows Hello для бизнеса с помощью модели доверия ключей и хотите перейти на облачную модель доверия Kerberos, выполните следующие действия.

  1. Настройка Microsoft Entra Kerberos в гибридной среде
  2. Включение доверия в облаке Kerberos через групповая политика или Intune
  3. Для устройств, присоединенных к Microsoft Entra, выйдите и войдите на устройство с помощью Windows Hello для бизнеса

Примечание.

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

Миграция с модели развертывания доверия сертификатов на облачную модель доверия Kerberos

Важно.

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

Если вы развернули Windows Hello для бизнеса с помощью модели доверия сертификатов и хотите использовать облачную модель доверия Kerberos, необходимо повторно развернуть Windows Hello для бизнеса, выполнив следующие действия.

  1. Отключение политики доверия сертификатов
  2. Включение доверия в облаке Kerberos через групповая политика или Intune
  3. Удаление учетных данных доверия сертификата с помощью команды certutil.exe -deletehellocontainer из контекста пользователя
  4. Выход и вход в систему
  5. Подготовка Windows Hello для бизнеса с помощью выбранного метода

Примечание.

Для Microsoft Entra устройств с гибридным присоединением пользователи должны выполнить первый вход с новыми учетными данными при наличии прямой видимости контроллера домена.

Часто задаваемые вопросы

Список часто задаваемых вопросов о доверии Windows Hello для бизнеса cloud Kerberos см. в разделе Windows Hello для бизнеса часто задаваемые вопросы.

Неподдерживаемые сценарии

Следующие сценарии не поддерживаются с использованием Windows Hello для бизнеса облачного доверия Kerberos:

  • Сценарии RDP/VDI с использованием предоставленных учетных данных (RDP/VDI можно использовать с remote Credential Guard или если сертификат зарегистрирован в контейнере Windows Hello для бизнеса)
  • Использование доверия Kerberos в облаке для запуска от имени
  • Вход с помощью cloud Kerberos trust на Microsoft Entra гибридном присоединенном устройстве без предварительного входа с подключением к контроллеру домена