Windows hello active directory

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

Windows Hello — это система аутентификации в Windows 10, на основе PIN кода, биометрических данных или гравифеского пароля. Приставка для бизнеса значит, что все это будет работать в домене.

Почему пароль уже не очень хорошо? Потому что! Если серьезно, то можно почитать тут.

Что нам надо?

• Active Directory — Минимум 1 контроллер домена на базе Windows Server 2016. Уровень домена не ниже Windows Server 2012 R2.
• Public Key Infrastructure
• Azure Active Directory.
• Windows 10 в качестве клиента.

Настройка сертификатов контроллера домена

Клиенты должны доверять контроллерам домена; лучший способ это обеспечить — предоставить каждому контроллеру домена сертификат проверки подлинности Kerberos. Установка сертификата на контроллер домена позволяет центру распространения ключей (KDC) подтверждать свою подлинность другим членам домена.

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

1. Откройте консоль управления Центр сертификации.
2. Щелкните правой кнопкой мыши элемент Шаблоны сертификатов и затем выберите Управление.
3. В консоли «Шаблон сертификата» щелкните правой кнопкой мыши шаблон Проверка подлинности Kerberos в области сведений, а затем щелкните Скопировать шаблон.
4. На вкладке Совместимость снимите флажок Показать последующие изменения. Выберите Windows Server 2012 или Windows Server 2012 R2 из списка Центр сертификации. Выберите Windows Server 2012 или Windows Server 2012 R2 из списка Получатель сертификата.
5. На вкладке Общие в поле отображаемого имени шаблона введите Проверка подлинности контроллера домена (Kerberos). Измените срок действия и период обновления в соответствии с потребностями вашей организации. Примечание: если используются другие имена шаблонов, их необходимо помнить и заменить на эти имена в разных частях лаборатории.
6. На вкладке Субъект нажмите кнопку Строится на основе данных Active Directory, если она еще не нажата. Выберите пункт Нет в списке Формат имени субъекта. Выберите DNS-имя в списке Включить эту информацию в альтернативное имя субъекта. Снимите все остальные флажки.
7. На вкладке Шифрование выберите Поставщик хранилища ключей из списка Категория поставщика. Из списка Имя алгоритма выберите RSA. Введите 2048 в текстовое поле Минимальный размер ключей. Выберите SHA256 из списка Хэш запроса. Нажмите кнопку OK.
8. Закройте консоль.

Замена существующего сертификата контроллера домена

Большое количество контроллеров домена может иметь существующий сертификат контроллера домена. Службы сертификатов Active Directory предоставляют шаблона сертификата по умолчанию от контроллеров домена — шаблон сертификата контроллера домена. Более поздние версии включают новый шаблон сертификата — шаблон сертификата проверки подлинности контроллера домена. Эти шаблоны сертификатов были предоставлены до обновления спецификации Kerberos, в которой указано, что центры распространения ключей (KDC), выполняющие проверку подлинности сертификатов, должны включать расширение KDC для проверки подлинности.

Шаблон сертификата проверки подлинности Kerberos — самый новый шаблон сертификата, предназначенный для контроллеров домена, и именно его следует развернуть на всех контроллерах домена (2008 или более поздней версии). Функция автоматической регистрации в Windows позволяет легко заменить эти сертификаты контроллеров домена. Можно использовать следующую конфигурацию для замены более старых сертификатов контроллеров домена новыми сертификатами с помощью шаблона сертификата проверки подлинности Kerberos.

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

1. Откройте консоль управления Центр сертификации.
2. Щелкните правой кнопкой мыши элемент Шаблоны сертификатов и затем выберите Управление.
3. В консоли «Шаблоны сертификатов» щелкните правой кнопкой мыши шаблон Проверки подлинности на контроллере домена (Kerberos) (или имя шаблона сертификата, созданного в предыдущем разделе) в области сведений и нажмите кнопку Свойства.
4. Выберите вкладку Устаревшие шаблоны. Нажмите кнопку Добавить.
5. Из диалогового окна Добавление устаревшего шаблона выберите шаблон сертификата Контроллер домена и нажмите кнопку ОК. Нажмите Добавить.
6. Из диалогового окна Добавление устаревшего шаблона выберите шаблон сертификата Проверка подлинности контроллера домена и нажмите кнопку ОК.
7. Из диалогового окна Добавление устаревшего шаблона выберите шаблон сертификата Проверка подлинности Kerberos и нажмите кнопку ОК.
8. Добавьте другие шаблоны сертификатов предприятия, настроенные ранее для контроллеров домена, на вкладку Устаревшие шаблоны.
9. Нажмите кнопку ОК и закройте консоль Шаблоны сертификатов.

Шаблон сертификата настроен для замены всех шаблонов сертификатов, перечисленных в списке устаревших шаблонов сертификатов.

Публикация шаблонов сертификатов в центр сертификации

Центр сертификации может выдавать только сертификаты, соответствующие шаблонам сертификатов, опубликованным в этот центр сертификации.

1. Откройте консоль управления Центр сертификации.
2. Разверните родительский узел в области навигации.
3. В области навигации щелкните Шаблоны сертификатов.
4. Щелкните правой кнопкой мыши узел Шаблоны сертификатов. Выберите пункт Создать и щелкните выдаваемый Шаблон сертификата.
5. В окне Включение шаблонов сертификатов выберите шаблон Проверка подлинности контроллера домена (Kerberos), созданный в предыдущих шагах. Нажмите кнопку ОК для публикации выбранного шаблона сертификатов в центр сертификации.
6. Если вы опубликовали шаблон сертификата проверки подлинности контроллера домена (Kerberos), следует отменить публикацию шаблонов сертификатов, включенных в список устаревших шаблонов.
   • Чтобы отменить публикацию шаблона сертификата, щелкните правой кнопкой мыши шаблон сертификата, публикацию которого вы хотите отменить, в области сведений консоли «Центр сертификации», а затем выберите Удалить. Нажмите кнопку Да для подтверждения операции.
7. Закройте консоль.

Настройка контроллеров домена для автоматической регистрации сертификатов

Контроллеры домена автоматически запрашивают сертификат на основе шаблона сертификата контроллера домена. Однако контроллер домена не знает о более новых шаблонах сертификатов или устаревших конфигурациях шаблонов сертификатов. Чтобы продолжить автоматическую регистрацию и обновление сертификатов контроллера домена, которые знают о более новых шаблонах сертификатов и устаревших конфигурациях шаблона сертификата, создайте и настройте объект групповой политики для автоматической регистрации сертификатов и свяжите объект групповой политики с OU контроллеров домена.

1. Запустите Консоль управления групповыми политиками (gpmc.msc).
2. В области навигации разверните домен и выберите узел Объект групповой политики.
3. Щелкните правой кнопкой мыши Объект групповой политики и выберите Создать.
4. Введите Автоматическая регистрация сертификатов контроллера домена в поле имени и нажмите кнопку ОК.
5. Щелкните правой кнопкой мыши объект групповой политики Автоматическая регистрация сертификатов контроллера домена и щелкните Изменить.
6. В области навигации в узле Конфигурация компьютера разверните Политики.
7. Разверните Параметры Windows, Параметры безопасности и выберите Политики открытого ключа.
8. В области сведений щелкните правой кнопкой мыши Клиент служб сертификации: автоматическая регистрация и выберите Свойства.
9. В окне Модель конфигурации выберите Включено.
10. Установите флажок Обновлять сертификаты с истекшим сроком действия или в состоянии ожидания и удалять отозванные сертификаты.
11. Установите флажок Обновлять сертификаты, использующие шаблоны сертификатов.
12. Нажмите кнопку OK. Закройте Редактор управления групповыми политиками.
13. В области навигации разверните домен и узел, имя которого соответствует имени вашего домена Active Directory. Щелкните правой кнопкой мыши подразделение Контроллеры домена и щелкните Связать существующий объект групповой политики…
14. В диалоговом окне Выбор объекта групповой политики выберите Автоматическая регистрация сертификатов контроллера домена или имя объекта групповой политики регистрации сертификата контроллера домена, созданный ранее, и нажмите кнопку ОК.

Групповая политика «Включить Windows Hello для бизнеса»

Параметр групповой политики «Включить Windows Hello для бизнеса» необходим Windows для определения того, следует ли пользователю пытаться регистрироваться в Windows Hello для бизнеса. Пользователь будет пытаться регистрироваться только в случае, если этот параметр политики включен.

Создание объекта групповой политики Windows Hello для бизнеса

Объект групповой политики содержит параметры политики, необходимые для запуска подготовки Windows Hello для бизнеса, а также для обеспечения автоматического продления сертификатов проверки подлинности Windows Hello для бизнеса.

1. Запустите Консоль управления групповыми политиками (gpmc.msc).
2. В области навигации разверните домен и выберите узел Объект групповой политики.
3. Щелкните правой кнопкой мыши Объект групповой политики и выберите Создать.
4. Введите Включить Windows Hello для бизнеса в поле имени и нажмите кнопку ОК.
5. В области содержимого щелкните правой кнопкой мыши объект групповой политики Включить Windows Hello для бизнеса и выберите Изменить.
6. В области навигации в узле Конфигурация пользователя разверните Политики.
7. Разверните Административные шаблоны, Компонент Windows и выберите Windows Hello для бизнеса.
8. В области содержимого дважды щелкните Использовать Windows Hello для бизнеса. Щелкните Включить и нажмите кнопку ОК.
9. Закройте Редактор управления групповыми политиками.

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

Самый лучший способ развертывания объекта групповой политики Windows Hello для бизнеса— это использование фильтрации по группам безопасности. Благодаря этому можно легко управлять пользователями, которые должны получить Windows Hello для бизнеса, просто добавляя их в группу. Это позволяет развернуть Windows Hello для бизнеса в несколько этапов.

1. Запустите Консоль управления групповыми политиками (gpmc.msc).
2. В области навигации разверните домен и выберите узел Объект групповой политики.
3. Дважды щелкните объект групповой политики Включить Windows Hello для бизнеса.
4. В разделе Фильтрация ограничений безопасности области содержимого нажмите кнопку Добавить. Введите Пользователи Windows Hello для бизнеса или имя ранее созданной группы безопасности и нажмите кнопку ОК.
5. Перейдите на вкладку Делегирование, выберите Прошедшие проверку и нажмите кнопку Дополнительно.
6. В списке Группы или пользователи выберите Прошедшие проверку. В списке Разрешения для прошедших проверку пользователей снимите флажок Разрешить для разрешения Применить групповую политику. Нажмите кнопку OK.

Развертывание объекта групповой политики Windows Hello для бизнеса

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

1. Запустите Консоль управления групповыми политиками (gpmc.msc).
2. В области навигации разверните домен, щелкните правой кнопкой мыши узел с именем вашего домена Active Directory и выберите Связать существующий объект групповой политики…
3. В диалоговом окне Выбор объекта групповой политики выберите Включить Windows Hello для бизнеса или имя ранее созданного объекта групповой политики Windows Hello для бизнеса и нажмите кнопку ОК.

Azure Active Directory

Теперь важно обновить структуру синхронизации Active Directory с Azure Active Directory. Если этого не сделать, то при вводе PIN кода, пользователи будут видеть ошибку вида «функция (входа по PIN коду) временно недоступна».

Windows 10

Можно приступать к настроке PIN кода, отпечатка пальцев и т.д.

Время на прочтение8 мин

Количество просмотров26K

Делимся с вами обзорным материалом про службу Windows Hello, обеспечивающую двухфакторную проверку на Windows 10. Также вы узнаете, чем она будет полезна для крупных компаний, почему стоит выбирать PIN-код, а не пароль и как её настроить.

Картинка с сайта: habr.com

Windows Hello — что это и зачем?

В Windows 10 служба Windows Hello для бизнеса заменяет пароли на строгую двухфакторную проверку подлинности на компьютерах и мобильных устройствах. Она заключается в создании нового типа учетных данных пользователя в привязке к устройству, использовании биометрических данных или PIN-кода.

В первых версиях Windows 10 были службы Microsoft Passport и Windows Hello, которые обеспечивали многофакторную проверку подлинности. Чтобы упростить развертывание и расширить возможности поддержки, Microsoft объединила эти технологии в единое решение — Windows Hello. Если вы уже выполнили развертывание этих технологий, то вы не заметите никаких изменений в функционировании служб. Для тех, кому еще предстоит оценить работу Windows Hello, выполнить развертывание будет гораздо проще благодаря упрощенным политикам, документации и семантике.

Служба Hello призвана решать типичные проблемы пользователей, возникающие при работе с паролями:

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

Hello позволяет выполнить проверку подлинности учетной записи Microsoft, учетной записи Active Directory, учетной записи Microsoft Azure Active Directory (Azure AD) и службы поставщика удостоверений или службы проверяющей стороны, которые поддерживают проверку подлинности Fast ID Online (FIDO) v2.0.

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

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

Разница между Windows Hello и Windows Hello для бизнеса

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

Служба Windows Hello для бизнеса, которая настраивается групповой политикой или политикой MDM, использует проверку подлинности на основе ключа или сертификата.

В настоящее время в учетных записях Active Directory с использованием Windows Hello не поддерживается проверка подлинности на основе ключа или сертификата. Эта функция должна появиться в будущем выпуске.

Почему PIN-код, а не пароль?

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

В Windows 10, в процессе подготовки, служба Hello создает пару криптографических ключей, привязанных к доверенному платформенному модулю (TPM), если устройство оснащено таким модулем, или в программной реализации. Доступ к этим ключам и получение подписи для проверки того, что пользователь владеет закрытым ключом, предоставляется только при вводе PIN-кода или биометрического жеста. Двухэтапная проверка, которая происходит при регистрации в службе Hello, формирует доверительные взаимоотношения между поставщиком удостоверений и пользователем, когда открытая часть пары «открытый/закрытый ключ» отправляется поставщику удостоверений и связывается с учетной записью пользователя. Когда пользователь выполняет жест на устройстве, поставщик удостоверений определяет по комбинации ключей Hello и жеста, что это проверенное удостоверение, и предоставляет маркер проверки подлинности, с помощью которого Windows 10 получает доступ к ресурсам и службам. Кроме того, в процессе регистрации генерируется претензия по удостоверению для каждого поставщика удостоверений, чтобы криптографически подтвердить, что ключи Hello привязаны к TPM. Если претензия по удостоверению во время регистрации не выставляется поставщику удостоверений, поставщик удостоверений должен предполагать, что ключ Hello создан программно.

Картинка с сайта: habr.com

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

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

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

Функция входа через телефон в данный момент доступна только отдельным участникам программы принятия технологий (TAP).

Так как же PIN-код помогает защитить устройство лучше, чем пароль?

Преимущества PIN-кода в сравнении с паролем связаны не с его структурой (длиной и сложностью), а с принципом работы.

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

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

3. PIN-код поддерживается оборудованием. PIN-код Hello поддерживается микросхемой доверенного платформенного модуля (TPM), представляющей собой надежный криптографический процессор для выполнения операций шифрования. Эта микросхема содержит несколько механизмов физической защиты для предотвращения взлома, и вредоносные программы не могут обойти функции безопасности TPM. TPM применяется во всех телефонах с Windows 10 Mobile и во многих современных ноутбуках.

Материал ключа пользователя создается и становится доступным в доверенном платформенном модуле (TPM) на устройстве пользователя, что защищает материал от перехвата и использования злоумышленниками. Поскольку технология Hello подразумевает использование пар асимметричных ключей, учетные данные пользователей не будут похищены в случае нарушения безопасности поставщика удостоверений или веб-сайтов, к которым пользователь осуществляет доступ.

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

4. PIN-код может быть сложным. К PIN-коду Windows Hello для бизнеса применяется тот же набор политик управления ИТ, что и к паролю, в том числе сложность, длина, срок действия и история изменений. Несмотря на уверенность большинства пользователей в том, что PIN-код представляет собой простой код из 4 цифр, администраторы могут устанавливать для управляемых устройств политики, предполагающие уровень сложности PIN-кода, сопоставимый с паролем. Вы можете сделать обязательными или запретить специальные знаки, буквы в верхнем и нижнем регистрах, а также и цифры.

Раздел меню настроек в котором задаются параметры PIN-кода и биометрия:

Картинка с сайта: habr.com

Что произойдет в случае кражи ноутбука или телефона?

Для нарушения безопасности учетных данных Windows Hello, защищаемых TPM, злоумышленнику нужно осуществить доступ к физическому устройству, найти способ похитить биометрические данные пользователя или подобрать PIN-код. Все это нужно сделать раньше, чем функциональный механизм защиты от взлома TPM заблокирует устройство. Для ноутбуков, не имеющих TPM, можно настроить дополнительную защиту, активировав BitLocker и ограничив количество неудачных попыток входа в систему.

Настройка BitLocker без TPM

С помощью редактора локальных групповых политик (gpedit.msc) активируйте следующую политику:

Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Шифрование диска BitLocker → Диски операционной системы → Требовать дополнительной проверки подлинности при запуске

В параметрах политики выберите Разрешить использование BitLocker без совместимого TPM, а затем нажмите кнопку ОК.

Картинка с сайта: habr.com

Перейдите в меню Панель управления → Система и безопасность → Шифрование диска BitLocker и выберите диск с операционной системой, который требуется защитить.

С помощью редактора локальных групповых политик (gpedit.msc) активируйте следующую политику: Конфигурация компьютера → Параметры Windows → Параметры безопасности → Политики учетных записей → Политика блокировки учетных записей → Пороговое значение блокировки.

Установите допустимое количество неудачных попыток входа в систему и нажмите ОК.

Картинка с сайта: habr.com

Как работает Windows Hello для бизнеса: основные положения

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

2. Поставщик удостоверений (например, Active Directory, Azure AD или учетная запись Майкрософт) проверяет удостоверение пользователя и сопоставляет открытый ключ Hello с учетной записью пользователя на этапе регистрации.

3. Ключи могут генерироваться в аппаратном (TPM 1.2 или 2.0 для предприятий и TPM 2.0 для потребителей) или программном обеспечении на основании политики.

4. Проверка подлинности — это двухфакторная проверка с использованием сочетания ключа или сертификата, привязанного к устройству, и информации, известной пользователю PIN-код), или идентификационных данных пользователя (Windows Hello). Жест Hello не перемещается между устройствами и не предоставляется серверу. Он хранится локально на устройстве.

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

6. Ввод PIN-кода и биометрических жестов приводит к проверке удостоверения пользователя в Windows 10 и проверке подлинности с использованием ключей или сертификатов Hello.

7. Личные (учетная запись Майкрософт) или корпоративные учетные записи (Active Directory или Azure AD) использует один контейнер для ключей. Все ключи разделены по доменам поставщиков удостоверений в целях обеспечения конфиденциальности пользователя.

8. Закрытые ключи сертификатов могут быть защищены контейнером Hello и жестом Hello.

Сравнение проверки подлинности на основе ключа и сертификата

Для подтверждения личности служба Windows Hello для бизнеса может использовать ключи (аппаратный или программный) или сертификаты с ключами в аппаратном или программном обеспечении. Предприятия с инфраструктурой открытых ключей (PKI) для выпуска и управления сертификатами могут продолжать использовать PKI вместе со службой Hello. Предприятия, у которых нет PKI или которые хотят сократить объем работ, связанных с управлением сертификатами, могут использовать для службы Hello учетные данные на основе ключа.

Аппаратные ключи, которые создаются модулем TPM, обеспечивают наиболее высокий уровень гарантии. При изготовлении в модуль TPM помещается сертификат ключа подтверждения (EK). Этот сертификат EK создает корневое доверие для всех других ключей, которые генерируются в этом модуле TPM. Сертификация EK используется для генерации сертификата ключа удостоверения подлинности (AIK), выданного службой сертификации Microsoft. Этот сертификат AIK можно использовать как претензию по удостоверению, чтобы доказать поставщикам удостоверений, что ключи Hello генерировались одним и тем же TPM. Центр сертификации Майкрософт (CA) генерирует сертификат AIK для каждого устройства, пользователя и IDP, чтобы гарантировать защиту конфиденциальности.

Если поставщики удостоверений, например Active Directory или Azure AD, регистрируют сертификат в службе Hello, Windows 10 будет поддерживать тот же набор сценариев, что и смарт-карта. Если тип учетных данных представляет собой ключ, будет поддерживаться только доверие и операции на основе ключа.

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

Last Updated on January 3, 2025 by Deepanshu Sharma

Картинка с сайта: www.lepide.com

Biometrics technology, which uses biological features for user authentication, is gaining popularity and becoming an essential part of security technology. Methods such as facial recognition and fingerprint recognition are widely used in various industries including healthcare, banking, and hospitality to secure digital transactions and provide a seamless user experience. The global biometrics market is projected to reach $136.18 billion by 2031, with Asia and North America experiencing the highest adoption rates. The increasing use of biometrics can be attributed to factors such as the popularity of facial recognition, the convenience of voice biometrics, advancements in artificial intelligence, the need for multi-factor authentication due to terrorism and cybercrime, and the need for contactless methods of authentication during the COVID-19 pandemic. As technology continues to advance, barriers to adoption will decrease, leading to further growth and usage of biometrics.

Solution Overview

Windows Hello for Business is a solution that allows enterprise users to replace password-based sign-in with a more preferred strong authentication mechanism. Signing into Windows is simplified for the user as they can leverage fingerprints, iris, facial recognition or a pin code while the organization benefits from the increased security of a strong authentication process where a password is no part of the equation.

The easiest way for an organization to adopt Windows Hello for Business is to deploy the necessary client policies after hybrid-joining or natively joining Azure Active Directory from their Windows 10/11 endpoints. Without Azure Active Directory, deploying Windows Hello for Business in an on-premises only environment requires quite a bit of additional infrastructure and setup such as an enterprise PKI, an Active Directory Federated Services (ADFS) deployment, etc. If a Windows device is hybrid-joined or pure Azure Active Directory joined, deploying the Windows Hello for Business policy settings are all that’s required from the enterprise IT infrastructure perspective to get started.

After Windows Hello for Business is setup for the enterprise clients and users have registered their credentials on devices, they can begin using the new strong authentication methods for logging into Windows.

If users are only accessing cloud-based resources such as OneDrive, SharePoint Online, Teams, etc., you should be all set with no additional setup required. However, if your users will continue to access any on-premises, Active Directory-backed resources such as file shares, print shares, etc., your environment will need a bit more setup. This is where the cloud Kerberos authentication comes into play.

Without additional configuration of the on-premises Active Directory environment, a user who has logged into Windows with Windows Hello for Business credentials and attempts to access an AD-protected resource will be greeted with the following prompt for re-authentication:

Картинка с сайта: mjshellenberger.com

This prompt is because the user does not have a ticket-granting-ticket (TGT) from Kerberos for on-premises authentication. When the client attempts to obtain a TGT from a domain controller, they are prompted for authentication. This process can be automated/hidden from the user by deploying one of the following solutions:

• Cloud Kerberos trust deployment – the recommended deployment model when compared to the key trust model. It is also the preferred deployment model if you do not need to support certificate authentication scenarios. No additional on-premises infrastructure is required.
• Key trust deployment – An enterprise PKI is required as trust anchor for authentication. Domain controllers require a certificate for Windows clients to trust them.
• Certificate trust deployment – An enterprise public key infrastructure (PKI) is required as trust anchor for authentication. Domain controllers require a certificate for Windows clients to trust them. The enterprise PKI and a certificate registration authority (CRA) are required to issue authentication certificates to users. Hybrid certificate trust deployment uses AD FS as a CRA.

This article will focus on deploying the recommended Cloud Kerberos trust model. In this model, Azure AD Kerberos is leveraged to grant requested TGT’s for clients accessing on-premises AD protected resources. With the security exchange happening between the client and the device trusted Azure AD directory, no user prompts for authentication arise and the client obtains the necessary TGT to authenticate to the on-premises Active Directory backed resource.

After enabling Azure AD Kerberos in a Windows Server Active Directory domain, you will see an AzureADKerberos computer object when browsing the domain controllers container in Active Directory Users and Computers tool.

Картинка с сайта: mjshellenberger.com

This computer object is required for Azure AD to generate the TGT’s mentioned previously, and functions like a Read Only Domain Controller (RODC). Now, let’s dive into the deployment!

Deployment Prerequisites

• Azure AD Multifactor Authentication
• Windows 10 21H2 or later
• Windows 11 or later
• Windows Server 2016 or later domain controllers
• Microsoft Intune or another modern device management platform for deploying the Cloud Kerberos trust policy settings

Important note: users that are directly or indirectly nested in any privileged groups in Active Directory will not be able to use Cloud Kerberos authentication. You should not be using privileged user accounts to log into Windows endpoints as a best practice.

Deploy Azure AD Kerberos

1. Download and install the Azure AD Kerberos PowerShell module. You can do this by opening a Windows PowerShell prompt, running as an administrator:, and running the following:
   • First, ensure TLS 1.2 for PowerShell gallery access: [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
   • Install the Azure AD Kerberos PowerShell Module: Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
2. Create a Kerberos Server object by running the following script from Microsoft and providing credentials when prompted:

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory global administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Global Administrators group for Azure AD.'

# Enter a domain administrator username and password.
$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.'

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

3. Verify the successful creation of the Azure AD Kerberos Server by running the following command: Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred 

Картинка с сайта: mjshellenberger.com

In this guide, I’m going to assume you’ve already deployed Windows Hello for Business via either the tenant-wide settings or via individual policies deployed to clients. If you haven’t done either, this is the time to configure it. Since this is impactful for the user, it’s highly advisable to prepare users for the registration process and how Windows Hello for Business will operate. I highly advise against simply flipping the solution on in production without planning the end user rollout.

Deploy Cloud Kerberos Trust Settings to Clients

You will now need to deploy additional Cloud Kerberos trust policy settings to clients via modern device management policy deployment and OMA-URI settings. Here are the instructions for the process via Microsoft Intune:

• Create a new Windows device-based profile. For profile type, select Templates and then select the Custom template.

Картинка с сайта: mjshellenberger.com

• Provide the profile with a name and description, then click Next.
• On the configuration settings page, add a new configuration with the following values:
  • Name: Windows Hello for Business Cloud Kerberos Trust
  • Description: Enable Windows Hello for Business cloud Kerberos trust for sign-in and on-premises SSO
  • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<TENANT ID>/Policies/UseCloudTrustForOnPremAuth <TENANT ID> should be replaced with your Azure AD Tenant ID.
  • Data Type: Boolean
  • Value: True

Картинка с сайта: mjshellenberger.com

• Click Save, then Next to continue.
• Target the Windows devices that have been enabled for Windows Hello for Business for the new policy and complete the new policy wizard.

After devices receive the updated Windows Hello for Business Cloud Kerberos trust settings, users will no longer be prompted for authentication when accessing on-prem AD protected resources while signed in with Windows Hello for Business credentials!

Are you finding the content on my site particularly helpful? Please consider donating to help me offset the costs of maintaining this site. Your support is greatly appreciated!