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 кода, отпечатка пальцев и т.д.

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

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 создан программно.

Представьте, что кто-то подсматривает через ваше плечо при получении денежных средств из банкомата и видит вводимый вами 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-кода и биометрия:

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

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

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

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

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

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

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

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

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

Как работает 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. Если у вас остались вопросы, задавайте в комментариях.

Anyone who has purchased a Windows device from Microsoft or several other vendors in the last few years might have been presented with Windows Hello. A biometrics-based technology (face or fingerprint scans), it lets you securely and quickly sign in to your device. In this article, we’ll look at a real-world deployment of Windows Hello for Business at a small independent school in Australia.

This won’t offer complete coverage of all Windows Hello for Business options, as there are quite a few paths you can take, depending on your starting environment. Instead, I’ll share my learnings from this particular deployment.

A few words about the client—they’re an independent school with approximately 90 students in grades 1–12 and about 20 staff. They use Microsoft 365 A3 (equivalent to commercial E3), Microsoft Endpoint Manager, and Windows 10 across all devices.

The device fleet comprises 13 Surface Book devices for teachers, 16 Surface Pros for senior students, and just over 50 Dell laptops (not Windows Hello for Business-capable) for the rest of the students, plus a smattering of Dell desktop PCs for admin staff. Server infrastructure is a R440 Dell Server, running Windows Server 2019 Hyper-V and seven VMs: two domain controllers, a file/print server, a LOB application, a WSUS server, Microsoft’s Advanced Threat Analytics (ATA), and a Linux Syslog server.

There’s also an older Dell server that’s the Hyper-V replica target for all VMs, located in a different building on campus. Each of the six buildings has a managed switch, which is connected with fiber optic cabling to the others. Each of these has a NetGear Wi-Fi access point in an ensemble, providing roaming indoor network access. Active Directory synchs user and computer accounts to Azure AD using AAD Connect.

Windows Hello vs. Windows Hello for Business

I’ve used Windows Hello for Business on every device since my first Surface Book, and it’s incredibly convenient. Most times I’m signed in before I’ve even sat down in the chair to start working. Setup is also quite quick: a few scans of your face (with and without glasses) and you’re good to go.

While Windows Hello for Business uses the same underlying technology, it’s quite a different beast. When the school decided to purchase Surface Books and later Surface Pros, I mentioned how great I found Windows Hello and said, «You can do this too.» IT consultant mistake number one: don’t promise until you’ve checked the prerequisites 😊.

Deployment prerequisites

Taking Windows Hello to Active Directory and using it on domain-joined PCs is a lot more complex than on consumer devices. When this first was discussed with the client, they were still running Windows Server 2008 R2 DCs, so that was the first hurdle—now their DCs are Windows Server 2019. Other requirements are Windows 10 1709 or later, either AD and AAD joined (hybrid) or AAD joined, Windows Server 2016 or later DCs (you can use 2008 R2/2012 but only with certificate trust—see below), with a Windows Server 2016 schema.

Windows Hello for Business isn’t just biometrics but an umbrella term for various stronger authentication methods, and you always have the option of falling back to a PIN that’s unique to that device, unlike a username/password pair.

As mentioned, there are a few paths to take in the quest toward Windows Hello for Business nirvana. Your first decision is between key-based and certificate-based authentication. The former is easier to deploy but doesn’t support Remote Desktop connections; the latter requires a public key infrastructure (PKI) for certificate deployment, which might fit right in if your business already has that deployed but raises the bar if you don’t. Note that even if you opt for key-based, you’ll still need a minimal PKI/AD Certificate Services (AD CS) service to deploy updated certificates to your DCs.

A second decision is whether you’re going to do a cloud-only deployment (Windows 10, AAD, Azure AD MFA only) or a hybrid deployment. For hybrid, you can do certificate trust and mixed managed, key trust and modern managed, or certificate trust modern managed, where «modern» means MDM (Intune/Endpoint Manager) enrolled. There is also an on-premises-only deployment path.

Microsoft provides a map for your quest in the form of a planning worksheet. Go through each question regarding your current environment in conjunction with the planning guide to gain insight into which options you have for your Windows Hello for Business deployment.

Here’s my resulting worksheet. We went with a hybrid deployment with key trust and Endpoint Manager. I automatically joined the client PCs to Azure AD using a GPO.

Another wrinkle is whether you’re still running AD Federation Services (AD FS; this client is not), which needs to be considered in your planning. As an aside, given that the SolarWinds attacks used AD FS, and Microsoft has been recommending migrating from AD FS to AAD for your federation needs, start your migration journey now if you have AD FS.

Once all devices were joined to AAD, I was ready to proceed. The documentation has clearly laid out steps, which in my case involved:

1. Checking prerequisites—AD, AAD directories, and PKI will need to be deployed for DC certificates (see below)
2. Deploying AD CS and configuring it
3. Configuring directory synchronization
4. Configuring Azure device registration
5. Configuring Windows Hello for Business settings
6. Signing in and provisioning

Certificate services

If you’re deploying AD CS in a large business with strict security requirements, be aware that there are many steps involved in planning such a deployment. One path is creating a root certificate server on a workgroup server (so that it doesn’t lose trust with the domain when it’s offline for extended periods of time), which deploys leaf certificate servers and is then shut down and locked away in a vault. This is beyond what this client needs, and I simply deployed CS on one of the DCs.

By default, the AD CA publishes a Kerberos Authentication certificate template, but it uses older and less performant crypto APIs; hence, the documentation guided me through creating a new template with updated settings such as the RSA algorithm with 20148 minimum key size. This template is then configured to supersede the older ones and published, while the older certificate templates are deleted.

AAD device registration

Since AAD Connect is already running at this client, it was simply a matter of configuring it. There’s a Service Connection Point (SCP) required but since we’re running an up-to-date version of AAD Connect, it was already in place.

I checked a random sample of devices in Devices for their join status in the AAD portal as well as on the devices themselves. You can use either dsregcmd /status in a command window or Get-MSolDevice in PowerShell.

Configuring Windows Hello for Business settings

After what felt like an eternity of planning, checking prerequisites, and configuring the infrastructure itself, I could now configure the single GPO setting «Enable Windows Hello for Business,» along with a second GPO for the domain controllers to automatically enroll the certificate described above.

There are a few optional additional settings in the GPO that you can use, such as Use a hardware security device, which mandates storing credentials in a TPM chip. You can optionally also require only TPM 2.0 and not 1.2. You can also use biometrics; perhaps you want to disable the use of biometrics until you’re ready to switch it on, which will leave PIN as the only option. You can require PIN Complexity (I went with a minimum of six digits) and created a Windows Hello for Business Users group to control who gets the option for Windows Hello for Business in the staged rollout.

End user experience

I learned rather late in the deployment that Windows Hello for Business requires Azure MFA (or the now-retired Azure MFA server on-premises), so apart from the steps above, users also need to use the free Microsoft Authenticator app on their phones (or SMS text messages or phone calls—I disabled those options as they’re more insecure) and need to register at aka.ms/mfasetup.

I initially deployed this to six teachers during an afternoon training session, and the experience was flawless: set up MFA, sign off, sign back on, Windows Hello for Business asks the user to set up a PIN, scans their face, and then signs them in. One of the Surface Books had trouble with the biometrics and refused to do face registration, probably due to its age (troubleshooting to follow).

Lessons learned

This was a long process, spread out over years from the initial idea to last week’s training when teachers enrolled, with more students and teachers to follow. I really like the idea of an unphishable credential that also provides a convenient user experience. Given the hardware requirements for Windows 11, I’ve advised the client that new device purchases toward the end of this year need to come with TPM 2.0 chips and Windows Hello for Business-capable biometrics. We’ll see what price premium that brings.

I’m also trialing a FIDO 2 YubiKey with one student to assess whether having a separate device (again unphishable) for authentication is preferable, rather than having it built into each PC.

Subscribe to 4sysops newsletter!

I hope this real-world deployment experience retelling was useful. Good luck in your journey to being passwordless.

In one of my last posts you will see how to disable the mandatory Windows Hello for Business Prompt (provisioning) on Azure AD joined devices and also get detailed information about what’s the difference between Windows Hello (convenient sign-in) and Windows Hello for Business.

Introduction

In this post we will see, how to set up Windows Hello for Business for Hybrid Azure AD joined devices by using the key trust model (deployment).

Windows Hello for Business was introduced in Windows 10 1703

There are also further deployments available for Windows Hello for Business as follows:

• Hybrid Azure AD Joined Certificate Trust Deployment
• On-premises Key Trust Deployment
• On-premises Certificate Trust Deployment

Whereas Windows Hello for Business for Azure AD joined devices will be provisioned and works out of the box, for Hybrid Azure AD joined devices we will first need to invest some effort to get it up and running.

To set up Windows Hello for Business for Hybrid Azure AD joined devices you can choose between two following trust models:

• Hybrid Azure AD Joined Certificate Trust Deployment
• Hybrid Azure AD Joined Key Trust New Installation

• Required domain controllers
• Issuing end entity certificates

The key trust model authenticates to Active Directory by using a raw key. Windows Server 2016 domain controllers enable this authentication. Key trust authenticate does not require an enterprise issued certificate, therefore you don’t need to issue certificates to users (domain controller certificates are still needed).

The certificate trust model authenticates to Active Directory by using a certificate. Because this authentication uses a certificate, domain controllers running previous versions of Windows Server can authenticate the user. Therefore, you need to issue certificates to users, but you don’t need Windows Server 2016 domain controllers. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise’s issuing certificate authority.

How are keys protected?
Wherever possible, Windows Hello for Business takes advantage of Trusted Platform Module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business do not require a TPM. Administrators can choose to allow key operations in software.

Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they’ll need to use MFA to re-authenticate to the IDP before the IDP allows them to re-register).

Source: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq#how-are-keys-protected

The Certificate Trust deployment only works in federated environments by using the Active Directory Federation Services (AD FS).

In contrast Windows Hello for Business key trust can be deployed in non-federated and federated environments.

Prerequisites

In this post I want to go through each step to set up the key trust model.

In the following article from Microsoft you will find all prerequisites for the key trust model.

Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs#federation-with-azure

In a nutshell these are:

• at least one 2016 Domain Controller
  only 2016 DCs enable key trust authentication
• Azure AD Connect
  The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory.
• Enterprise PKI – Active Directory Certificate Services (AD CS)
  Domain controllers for hybrid deployments need a certificate in order for Windows 10 devices to trust the domain controller.
• Device Registration
  Organizations wanting to deploy hybrid key trust need their domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory.

Set up

I assume you will still have installed and configured Azure AD Connect. If not you can use my following post about install and configure Azure AD Connect to synchronize your on-premises network with Azure AD.

Also you will find here detailed information about how to configure Azure AD Connect in order to set up Windows Hello for Business key trust model.

Configure Directory Synchronization for Hybrid Azure AD joined key trust Windows Hello for Business
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync

In my lab environment I still had a running Azure AD Connect setup and therefore I will first check if device registration is still configured as it is a prerequisite to set up Windows Hello for Business.

You will also find in my following post about how to configure Hybrid Azure AD join, the steps which will also enables the device registration.

In order to check if device registration is configured in Azure AD Connect, I will first edit the synchronization options.

Here you need to check to select all OUs where you store your computer objects which should be used for Hybrid Azure AD join and therefore must be synced to Azure AD.

Further we need to check the Configure device options

Here we need to select Configure Hybrid Azure AD join

I will only have Windows 10 clients in my environment and also Windows Hello requires you to have Windows 10 clients.

The next step is to configure the public key infrastructure.

If you do not have an existing public key infrastructure, please review Certification Authority Guidance from Microsoft TechNet to properly design your infrastructure.

Configure a Production Public Key Infrastructure
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install#configure-a-production-public-key-infrastructure

My lab environment still have a running public key infrastructure, so I can skip that step.

Finally we need to enable Windows Hello for Business by using a group policy for the user’s or computers you want to enroll it.

Enable Windows Hello for Business
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy#enable-windows-hello-for-business

You can configure the Enable Windows Hello for Business Group Policy setting for computer or users.

In my lab environment, I will apply the GPO to computers, therefore I need to configure the following policy.

Computer Configuration -> Administrative Templates -> Windows Components -> Windows Hello for Business

The GPO is linked to the OU with the computers who should provision Windows Hello for Business.

From now on all Windows 10 computers (version 1703 or later) residing in that OU, should provision Windows Hello for Business, after the user signs-in the next time as follows.

Hybrid Azure AD joined Windows Hello for Business Key Trust Provisioning
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision

If you want to change your PIN later, you can go to settings -> Accounts -> Sign-in options -> Windows Hello PIN and click on Change.

The next time the user want’s to logon to the device, the PIN can be used instead the password.

By clicking on Sign-in options you can still use your password to logon to the device.

You will find your Hybrid Azure AD joined devices in the Azure Portal https://portal.azure.com under

Azure Active Directory -> Devices -> All devices

Here you will see the device win10, which is used from John Doe for the logon and provisioning above.

To only disable the Windows Hello for Business provisioning process after sign-in on the device, which prompts the following dialog, …

… you can also enable Windows Hello for Business with that GPO but also check the option Do not start Windows Hello provisioning after sign-in as shown below.

That option is available in both sections of the GPO, the Computer configuration and User configuration.

Determine if Windows Hello for Business is used for your Windows Sign In

To finally check if Windows Hello for Business is used for the Windows Sign In on a Azure AD joined device, you can check the Sign-in logs from Azure AD as follows.

Azure Active Directory -> Sign-in logs

You can also add a filter to limit the logs only on Windows Sign In events as follows.

Click on Add filters

Select Application and click on Apply.

Add the name of the application in our case Windows Sign In and click on Apply.

Removing your Windows Hello for Business PIN Registration

As far as I know, at the moment you have only two options to remove your Windows Hello for Business PIN registration, which both of them a little bit odd in my opinion.

The Windows Hello (convenient sign-in) registration in contrast can be removed as expected by using the Remove button as follows. The button here is not greyed out and you can click on it to remove the registration.

For Windows Hello for Business PIN this button is greyed out by default as you can see in the screenshots below. The GPO itself does also not provide a setting to enable the user to remove the registration, only to not start Windows Hello provisioning after sign-in.

In order to remove Windows Hello for Business PIN, you can either use the certutil command or the I forgot my PIN link and cancel the process afterwards, as shown below. Both options will remove the registration, but keep in mind, that if the Windows Hello for Business GPO above doesn’t have checked the option Do not start Windows Hello provisioning after sign-in, after removing you will be prompted after the next logon to your device again to set up Windows Hello for Business.

certutil.exe -DeleteHelloContainer
logoff.exe

Remove button is greyed out for Windows Hello for Business as mentioned.

The registration is removed

Removing your Windows Hello for Business registration by using the I forgot my PIN link

Click on the link

Click on Continue

Click on Cancel

Click on the link I’ll set up a PIN later

The registration is removed.

Identify if you register your Account for Windows Hello (convenient sign-in) or Windows Hello for Business

If you want to know if you register your account for Windows Hello (convenient sign-in) or Windows Hello for Business, you can distinguish them easily by the dialog itself for the password verification as follows.

Windows Hello (convenient sign-in) dialog
You only get prompted from your local device itself to verify your local cached domain or standalone password and storing them within a sort of wrapper on that device. The PIN only releases that wrapper on the local device to use the credentials within for authentication as usual.

The Windows Hello (convenient sign-in) registration you can also remove by using the Remove button.

Windows Hello for Business dialogs
Here you can see from the dialogs that you need to verify the password directly with Azure AD.
Behind the scenes an asymmetric key pair is created and the public key is associated with your Azure AD account and then synced to your on-premises Active Directory user object and msDS-KeyCredentialLink attribute as described under troubleshooting at the end of this post.

And in contrast to the Windows Hello (convenient sign-in) registration, the Remove button is greyed out after registration for Windows Hello for Business.

In case of a hybrid Azure AD joined certificate trust, on-premise key trust or on-premise certificate trust deployment, you will be prompted with a dialog from the internal Active Directory Federation Services (AD FS) server like this for password verification.

Source: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-provision#provisioning

Moving from Windows Hello (convenient sign-in) to Windows Hello for Business

If you still use Windows Hello (convenient sign-in) in your network and want to move to use Windows Hello for Business, you first have to change your policy settings for Turn on convenience PIN sign-in into Not Configured as follows.

Computer Configuration -> Policies -> Administrative Templates -> System -> Logon -> Turn on convenience PIN sign-in

Now you can enable the Windows Hello for Business policy as follows if you already had configured your environment for Windows Hello for Business as described in this post.

You can choose here between computer or user policy.

Computer Configuration -> Administrative Templates -> Windows Components -> Windows Hello for Business

User Configuration -> Administrative Templates -> Windows Components -> Windows Hello for Business

In case you check the option Do not start Windows Hello provisioning after sign-in for that policy, the user’s will still use Windows Hello (convenient sign-in) and first have to remove that registration in order to add afterwards a new Windows Hello for Business registration as follows.

Now the user can add a new Windows Hello for Business registration.

If that option, Do not start Windows Hello provisioning after sign-in, is not checked, the next time the user logs on to its device, can indeed still use its existing convenient PIN to sign-in, but then will be prompted to set up Windows Hello for Business as usual. The user also can cancel that process, but then will be prompted for each logon again.

Troubleshooting

That option is temporarily unavailable. For now, please use a different method to sign in.

If you run into the following error directly after provisioning Windows Hello for Business key trust model, the reason for is supposedly that the key is not already synced from Azure AD to your on-premises Active Directory. The user’s public key will be written to the msDS-KeyCredentialLink attribute of the user object in your on-premises Active Directory as shown below.

In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure. Azure AD Connect synchronizes the Windows Hello for Business public key to your on-premises Active Directory.

Here you can see the from Azure AD to the on-premises Active Directory synced msDS-KeyCredentialLink attribute as mentioned above.

Here you can see that the msDS-KeyCredentialLink attribute is exported by the Windows Azure Active Directory connector to on-premises.

More about the Azure AD Connect architecture and how it works you will find in my following post.

Your credentials could not be verified

Something went wrong and your PIN isn’t available (status: 0x000005e, substatus:0x0). Click to set up your PIN again.

This error appears on Hybrid Azure AD joined devices (both, key and certificate trust) for the first logon after provisioning Windows Hello for Business and if the device doesn’t have a connection to the internal domain controllers from your on-premises network.

For example you provision Windows Hello for Business on your notebook from external.

You can use here a simple workaround to solve this issue:

• logon to your device by using your password
• establish a vpn connection to your network
  (if you already establish the vpn connection at the logon screen by using the -AllUserConnection flag for the native windows vpn, and therefore logon directly against your internal domain controllers, or after the logon, doesn’t matter in this case)
• lock your screen
• unlock your screen by using the (PIN or biometrics)
• done!

After that the next second logon from external should also work by using the (PIN or biometrics).

Deleting the Ngc Folder

Sometimes you encounter problems where nothing else works, in this case you could try to solve them by deleting the Ngc folder. By deleting this folder, all Windows Hello registrations on the device will be removed.

Windows 10 stores all information about the Windows Hello PIN registration among the Trusted Platform Module (TPM) and the local Ngc folder:
C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNgc

If you can’t delete this folder because of missing permissions, you can execute one or all of the following commands in order to be able to.

takeown /F C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNgc /R /D Y

# This tool allows an administrator to recover access to a file that was denied by re-assigning file 
# ownership.
# /F filename
# /R recursive
# /D prompt Default answer used when the current userdoes not have the "list folder" permission on a 
#  directory. This occurs while operating recursively (/R) on sub-directories. Valid values "Y" to 
#  take ownership or "N" to skip.


# If necessary also execute the following command, your account should be a member of the local 
# administrators group.

icacls C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNgc /T /C /GRANT administrators:f

# Displays or modifies discretionary access control lists (DACLs) on specified files, and applies 
# stored DACLs to files in specified directories.
# /T Performs the operation on all specified files in the current directory and its subdirectories.
# /C Continues the operation despite any file errors. Error messages will still be displayed.
# /GRANT Grants specified user access rights. Permissions replace previously granted explicit 
# permissions.

Now you should be able to delete this folder. After that try the provisioning again, the Ngc folder will be created automatically during this process.

Windows Hello for Business Logon Process Flow

You will find detailed information about how the logon process in Windows Hello for Business will work by the following Microsoft article.

Windows Hello for Business and Authentication
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication

Security aspects

By using both technologies side by side, the Primary Refresh Token (requesting access and refresh tokens for registered apps in Azure AD) and Windows Hello for Business for Azure AD joined or Hybrid Azure AD joined devices, the username and password will never be transmitted to the identity provider (IdP), instead tokens will be sent and used.

This is also true for the Windows Hello for Business provisioning process, instead username and password, the PRT will be used for authentication from Azure AD joined or Hybrid Azure AD joined devices

You can check if a PRT is issued to your user and device by using the command dsregcmd /status

Under SSO State you will find AzureAdPrt yes or no.

The device is Hybrid Azure AD joined

NgcSet: Set to “YES” if a Windows Hello key is set for the current logged on user.
WamDefaultAuthority: Set to “organizations” for Azure AD.
WamDefaultId: Always “https://login.microsoft.com” for Azure AD.

AzureAdPrt: Set to “YES” if a PRT is present on the device for the logged-on user.
AzureAdPrtUpdateTime: Set to the time in UTC when the PRT was last updated.
AzureAdPrtExpiryTime: Set to the time in UTC when the PRT is going to expire if it is not renewed.
AzureAdPrtAuthority: Azure AD authority URL
EnterprisePrt: Set to “YES” if the device has PRT from on-premises ADFS. For hybrid Azure AD joined devices the device could have PRT from both Azure AD and on-premises AD simultaneously. On-premises joined devices will only have an Enterprise PRT.
EnterprisePrtAuthority: ADFS authority URL

If the Windows Hello key is not set for the device, you will see the following output.

Further you will see an additional section at the end with Ngc Prerequisites Check as follows.

This section performs the prerequisite checks for the provisioning of Windows Hello for Business (WHFB).

PolicyEnabled: Set to “YES” if the WHFB policy is enabled on the device.
PostLogonEnabled: Set to “YES” if WHFB enrollment is triggered natively by the platform. If it’s set to “NO”, it indicates that Windows Hello for Business enrollment is triggered by a custom mechanism
DeviceEligible: Set to “YES” if the device meets the hardware requirement for enrolling with WHFB.
SessionIsNotRemote: Set to “YES” if the current user is logged in directly to the device and not remotely.
CertEnrollment: Specific to WHFB Certificate Trust deployment, indicating the certificate enrollment authority for WHFB. Set to “enrollment authority” if source of WHFB policy is Group Policy, “mobile device management” if source is MDM. “none” otherwise
PreReqResult: Provides result of all WHFB prerequisite evaluation. Set to “Will Provision” if WHFB enrollment would be launched as a post-logon task when user signs in next time.

See also for more information about using the dsregcmd command the following article.

Troubleshooting devices using the dsregcmd command
https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd

That doesn’t mean you will be safe from attacks at all by using token based authentication, there are also potential weaknesses like in all systems. The following links will deal about that for Windows Hello for Business as well as the Primary Refresh Token (PRT).

More technical details about how Windows Hello for Business works you will find in the following Microsoft articles.

It’s also worth to watch Microsoft’s password-less strategy.

Links

Windows Hello for Business (WHfB) is an awesome Microsoft technology that replaces traditional passwords with PIN and/or Biometrics and linked with a cryptographic certificate key pair. This is set up by default as part of the Out of Box Experience with Windows 10. These certificates grant single sign-on access to legacy Active Directory resources. There are a number of other benefits of why a PIN is more secure than passwords as well and I would encourage you to read more about it on Microsoft’s documentation.

WHfB not only provides a more secure way to sign in to Windows, but it enables cloud-joined Azure Active Directory (AAD) devices to access resources on the domain. For many organizations adopting modern deployment technologies like Autopilot, AAD-joined PCs (also called cloud-joined) aren’t joined to the on-premise domain. Accessing a file share, for example, would not be possible without constantly prompting the user for username and password. With WHfB, however, Windows 10 clients are now able to generate a Kerberos ticket and they now act almost like they are joined to the domain. Users will be able to access file shares, printer shares, and other resources that leverage Kerberos authentication without any prompts at all. Nice!

WHfB is relatively simple to set up but it does have quite a few pre-requisites that must be met in order for it to function properly. In this blog, I’ll be going over which type of WHfB deployment is best, all the prereqs associated, and then walking step-by-step on setting this up in your lab or production environment. Let’s begin!

What is the difference between Windows Hello and Windows Hello for Business?

You are probably familiar with Windows Hello by setting it up on your home PC. It allows you to log in to your PC with an easier PIN and/or Biometric login. For most people, this is just a convenience; it doesn’t do anything beyond that. Windows Hello for Business, on the other hand, takes that same convenience but adds an additional layer of security on top. It not only makes it simpler for end-users to log into their corporate PC, but it also provides a secure way to access corporate resources on the domain.

Additionally, we can also control WHfB with GPO or MDM policies and tools like Microsoft Endpoint Manager or VMware Workspace ONE.

Two Methods

Microsoft has implemented two different methods for Hello For Business: Cert-Trust and Key-Trust. Key-Trust is the default and is the easiest to set up. It leverages the built-in Azure AD certificate that gets deployed each time a device joins Azure AD through the Out of Box Experience (OOBE). The private key of this certificate gets saved in the Microsoft Passport for Work store and the public key gets synced to Azure AD. AAD then syncs it back to on-premises Active Directory and saves it to a user attribute called msDS-KeyCredentialLink.

Cert-Trust on the other hand, adds an additional device registration step to the process. When the device goes through OOBE, it must talk to Active Directory Federation Services (ADFS) which then registers the device to on-premise AD. This device object is then written up to Azure AD (called “Device Writeback” in Azure AD Connect). After this happens, the user certificate, which is deployed from your own Active Directory Certificate Server instead of Azure AD, is then paired up with the device. This method uses both Device + User trust whereas the Key-Trust is only at the user level (no device registration required).

Which method should I pick?

Key-Trust is the default method and is the method I recommend. It is much simpler to implement and doesn’t require any additional infrastructure or services. Cert-Trust requires ADFS and thus adds a significant layer of complexity. Consult your Microsoft resource if you are unsure of which method to choose.

I’ll be demonstrating the Key-Trust method. Even though these steps will all be done in a lab environment, you should be able to easily replicate these to a UAT or Production environment at your organization.

PreReqs and Assumptions

Here are the following prereqs and assumptions we’ll need before we get started. You’ll need to complete these or be ready for them before continuing.

1. Active Directory Domain Services installed on a Domain Controller running Windows Server 2016 or newer.
   1. Ensure Active Directory Schema is 2016 or higher.
2. Active Directory Certificate Services (ADCS) 2012 or newer. You can also use third-party certificate services, but I won’t be showing that here.
   • A certificate revocation list (CRL) that is accessible via HTTP. Ideally this should also be accessible on the internet.
   • Resolvable DNS for the CRL on the client.
   • A new Kerberos Authentication Template will be generated and must be installed on Domain Controllers (overwriting the previous one).
3. Azure AD Connect Setup, configured, and syncing users from on-premise AD into AAD.
4. Azure AD Premium P1 or P2 licensing or equivalent.
5. Domain Controller Root Certificate deployed to clients.

One final note: Microsoft refers to this implementation as “Hybrid Key-Trust”. This just refers to the back-end architecture of having both on-premise Active Directory syncing into Azure AD via AAD connect. It does not mean the Windows 10 client is actually hybrid-joined to on-premise AD plus AAD. You can view the full list MS list of prereqs here.

Quick Checklist

Before we get in too deep, here is a quick reference on the steps we’ll be going through to set up Windows Hello for Business using the Key Trust method.

Verify the AAD Connect Service Account Permissions

First, you will need to ensure the service account used by AAD Connect has the correct permissions to update the msDS-KeyCredentialLink attribute on the user object. If you aren’t sure what service account is being used, here is how you check:

1. Log in to the Azure AD Connect service and double-click on the Azure AD Connect icon on the desktop.
2. Once the Azure AD connect wizard application launches, click on “View or Export Current Configuration” and click Next.

1. Under Synchronized Directories, you will see the account used.

In my case, my account name is MSOL_1e05d7a78947.

Now, add this account into the KeyAdmins security group in Active Directory. This group provides the correct level of permissions needed to read and write the public key to Active Directory.

Close the Azure AD Connect wizard and perform delta sync on AAD connect after you make this change. You can do this by running the following PowerShell command from the Azure AD Connect server:

Start-ADSyncSyncCycle -PolicyType Delta

For more information on this topic, see the Microsoft documentation. Now that we have that taken care of, let’s move onto certs.

Setup CRL Distribution Point (CDP) accessible from the web

Clients will need the ability to query the certificate revocation list (CRL) in order for the authentication to happen. This may seem odd since we are not using the cert trust method, but remember that certificates are still used in the key-trust method. The domain controller is still doing authentication based on the trust between the key pair. It also needs to check to see if any domain-level certificates are revoked, including the root CA.

This CRL needs to be accessible via HTTP (not HTTPS) and ideally internet facing. Since this is primarily used to access on-premises resources you technically don’t have to make this internet-facing. Clients will need to be on the VPN in order to access internal file shares and thus will have access to an internally based CRL. However, it is best practice to put these on the internet. This may already be set up in your organization, but in case it’s not or you want to follow along in a lab here are the high-level steps:

1. Setup an web server using IIS that has a fileshare configured. You will add this as a virtual directory in IIS. The Certificate Authority will publish the CRL there and that is also where clients will check. This will be your CPD or “Certificate Distribution Point.
2. Create a CNAME record in DNS for that server which will house the CRL (i.e. pki.brookspeppin.local)
3. Update the CA template to use this HTTP location for CRL
4. Deploy (or re-deploy) your domain controller certificate as well as export the root certificate for installation on client machines.

MS has good documentation on how to properly set up a full web-based CRL and we’ll generally be following these steps.

I’m putting the Certificate Distribution Point (CPD) on the same server as my CA, but it’s not required. Any web server will do as long as the CA has write access to it in order to create the CRL files.

1. Create a folder on the C drive where the CRL will reside. I’m calling mine C:CRL
2. Right click the folder, then Properties, then Sharing tab, then Advanced Sharing. 
3. Click Share this folder and name it. Add $ to the end if you want to make it hidden from normal file browsing.
4. Then click Permissions.  Ensure Everyone has “Read” permissions 

1. Then click on Add and we will need to add the CA computer object to this.
2. Click on Object Types and ensure ​”Computers” box is checked.

1. Search for the computer name and it should resolve. Click OK and ensure the it has Full Control. In my lab, my CA is on my Domain Controller, DC01.

1. Click Apply and OK on Advanced Sharing.
2. On the security tab for your share (C:CRL), repeat the same process giving the computer object modify permissions

1. Finally, click Add and type ANONYMOUS LOGON; Everyone

1. Click ok. This allows anonymous access so that any clients can check the CRL.
2. Do a quick test by browsing to that share. It should resolve and be empty.

Configure IIS for HTTP CRL Location

Now that we have finished setting up our CDP, we need to configure IIS by adding it as a virtual directory.

1. Load the IIS console
2. In navigation tree, expand it and browse to your Default Web Site. Right click it and click Add Virtual Directory.​

1. Under Alias, type what you want your web URL to contain. I’ve just named it “CRL”. Also, browse for the CRL folder and select it. Click OK ​to close.

1. On the left hand navigation tree, select the new folder (named “CRL”). Double-click on the Directory Browsing icon.

1. Click Enable on the right hand side.

1. Go back one screen and then double-click on the Configuration Editor icon.

1. In the drop down list, type or search for system.webServer/security/requestFiltering
2. Change allowDoubleEscaping to be ​True. Then click Apply.  This is required in order for the client to download a CRL delta file which has a ‘+’ symbol in it.

1. Click on Default Web Site and then under Manage Website on the right click Restart.

1. Load up a web browser and ensure you can get to your new website: http://dc01/crl

Now this resolves because I’m doing it on the same box, but it won’t be accessible by clients until we set up DNS. We’ll do that next.

Setup DNS for the CRL

DNS may already be set up in your environment for the IIS server we just created, but if you still need to do it, follow these steps. I’ll be using Active Directory integrated DNS and setting up an alias for this called “PKI”.

1. Launch the DNS Manager mmc.
2. Expand the tree under Server > Forward Lookup Zones. Right-click the forward lookup zone where you want to add the Alias resource record, and then click New Alias (CNAME).

1. In Alias name, type the alias name you would like. I’ll be using “pki”.
2. In Fully qualified domain name (FQDN) for target host, type the FQDN of the IIS web server. Since I put it on my DC in my lab, the FQDN is “dc01.brookspeppin.local”.

1. Click OK to save.
2. Type in the new alias URL to ensure it resolves (Make sure it’s http:// not https://)

You can reference the Microsoft Docs for more info. Now that we have this complete, we will move onto configuring a few things on the certificate authority.

We need to add the CDP URL to the CA itself.

1. Log in to the CA if you are not already there.
2. Search for and launch certsrv.mmc. Right click the CA name and click Properties.

1. Click the Extensions tab. In the dropdown for “Select extension”, ensure you have CRL Distribution Point (CDP) selected. Before you make changes here, take a screenshot of this in case you need to revert. In the Specify locations from which users can obtain a certificate revocation list (CRL) section, remove the following enteries:
   • Entry starting with “file://\<ServerDNSName>…”
   • Entry starting with “http://<ServerDNSName>…”
   • Entry starting with “ldap:///CN=<CATruncatedName>…”
     You should only have one left starting with “C:WindowsSystem32CertServer…”
2. Now we need to add our new CDP URL that we configured earlier.
3. Click Add.
4. In Add Location, in Location, type http://[yourDNSname]/[folder]/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
   So in my case I put “http://pki.brookspeppin.local/crl/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl”. Update yours accordinly. The items in between the <> are variables and when the CRLs are generated they will be populated with real data. Click OK to save.

1. At the bottom, ensure the following boxes are selected:
   • Include in CRLs. Clients use this to find the Delta CRL locations
   • Include in the CDP extension of issued certificates

1. Click Add again.
2. in Location, type 
   file://\[dnsname][folder]<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl, (be sure to replace the value in teh brackets with your own server info). I.e. “file://\pki.brookspeppin.localcrl$<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl” (note that I have a $ at the end since I set this up as a hiddens share)
3. Click OK. This returns you to the CA properties dialog box.
4. At the bottom, select the following check boxes:
   • Publish CRLs to this location
   • Publish Delta CRLs to this location

1. Change the dropdown from “Select extension” to Authority Information Access (AIA)
2. Repeate what you did earlier by removing the three entries:
   • Entry starting with “file://\<ServerDNSName>…”
   • Entry starting with “http://<ServerDNSName>…”
   • Entry starting with “ldap:///CN=<CATruncatedName>…”

3. Click Add.
4. In the Location box type: http://[dnsname]/[folder]/<ServerDNSName>_<CaName><CertificateName>.crt, and then click OK. So for me this would be: “http://pki.brookspeppin.local/crl/<ServerDNSName>_<CaName><CertificateName>.crt”. Click OK to save.

1. At the bottom, check the box Include in the AIA of issued certificates.

1. Click OK to save all of these changes. You will be prompted to restart Active Directory Certificate Services. You can click No as we will be restarting the service later.

You can reference the Microsoft Docs for more info. Next, let’s move on to publishing the cert revocation list.

Publish the cert revocation list

1. Restart your CA service from certsrv.mmc by right-clicking your CA server name, All Tasks > Stop Service. Then Start the service again.

1. Right click Revoked Certificates > All Tasks > Publish

1. Select New CRL and click OK.

NOTE: If you are doing all of this on the same server such as in a lab environment (DC, CA, DNS, etc) you may run into this error:

This either means the configuration on the Extensions tab is incorrect or because of a loopback problem. In my case, I had to disable loopback check on the DC. You can disable loopback by running the following PowerShell command:

New-ItemProperty HKLM:SystemCurrentControlSetControlLsa -Name "DisableLoopbackCheck" -value "1" -PropertyType "DWORD"

1. Re-publish the CRL and the error should be gone.
2. Browse to your CDP and ensure the two CRL files are there:
   1. One ending in .crl (primary CRL)
   2. One ending in +.crl (delta CRL)
3. Additionally, we will need to copy the CA certificate to this location as well. You can run this command (update it with your target URL)

copy C:Windowssystem32certsrvcertenroll*.crt \pki.brookspeppin.localcrl$

A cert ending in .crt will be copied to your CDP. Once complete it should look like this:

1. Finally, load pkiview.msc to verify everything is good

OK you’ve made it this far. Great job! We’re in the home stretch — only a few more things to configure.

Create a New Domain Controller Authentication (Kerberos) Certificate Template

Active Directory Schema 2016 adds some additional attributes in order to support the key-trust authentication used with Hello for Business. We will need to create an updated template and then issue them to the domain controllers. This new template will replace and supersede the old ones. Nothing is getting removed, we are just added additional authentication purposes to it (namely KDC and Smart Card Logon).

1. On the CA server, open the Certificate Authority management console (certsrv.mmc)
2. Right-click Certificate Templates and click Manage.

1. In the Certificate Template Console, right-click the Kerberos Authentication template in the details pane and click Duplicate Template.

1. On the Compatibility tab, clear the “Show resulting changes” check box. Select Windows Server 2008 R2 from the Certification Authority list. Select Windows 7 / Server 2008 R2 from the Certification Recipient list.
   

1. On the General tab, type Domain Controller Authentication (Kerberos) in Template display name. Adjust the validity and renewal period as needed.

1. On the Subject Name tab, select the Build from this Active Directory information button if it is not already selected. Select None from the Subject name format list. Select DNS name from the Include this information in alternate subject list.

1. On the Cryptography tab, configure the following:
   • Provider Category: Key Storage Provider
   • Algorithm name: RSA
   • Minimum key size: 2048
   • Request Hash: SHA256
   • Click Apply.

Supercede Old templates

Now we need to supersede the older templates so that this new one gets automatically applied.

1. In the Domain Contoller Authentication (Kerberos) template, click the Superseded Templates tab.
2. Click Add.
3. Select Domain Controller and Domain Controller Authentication (hold shift to multi-select) certificate templates and click OK.

1. There should be three listed in the superseded list:
   • Domain Controller
   • Domain Controller Authentication
   • Kerberos Authentication
2. Click Apply and OK.
3. Close the Certificate Templates Console

You can read the Microsft Docs for additional information. Next, we need to publish this template so that it can be issued to Domain Controllers.

Publish the Template

1. In the Certificate Authority management console (certsrv.mmc), right-click the Certificate Templates node. Click New, and click Certificate Template to issue.

1. In the Enable Certificates Templates window, select the Domain Controller Authentication (Kerberos) template you created in the previous steps. Click OK to publish the selected certificate templates to the certificate authority.

1. It’s a good idea to unpublish the old, superceded templates. Select both the Domain Contoller and Domain Controller Authentication templates, right click and delete. Only the new “Domain Controller Authentication (Kerberos)” template should remain. The other templates in the list unrelated to this can also remain.

Now let’s deploy these to our domain controllers. You’ll want to do this on every domain controller.

Deploy new certificate to Domain Controller

You have two options here: manually deploy to each DC or configure group policy for automatic certificate enrollment. I’ll show you how to do it manually but in production, you’ll probably want to set up the GPO since you’ll have way more than one or two. To set up the GPO, follow the Microsoft docs here

Manual Steps

1. Login to the DC and open the Local Computer cert store on the DC
2. Expand Personal > Certificates. Right click the Certificates folder then All Tasks > Request new Certificate

1. Click Next in the window
2. Select Active Directory Enrollment Policy and Click Next.

1. Select Domain Controller Authenticate (Kerberos). You may need to select “show all templates” for it to appear. Then click Enroll.
   

1. You should see the new cert deployed and it should have “KDC Authentication” and “Smart Card Logon” added to it under the intended purposes column

1. Select the older cert (the one that says just “Client Authentication, Server Authentication”) and delete it.
2. Double click the newly issued cert to open it
3. Click on Details tab
4. Scroll down to CRL Distribution Points and ensure that it has the correct CRL information (it should show your http location)

The last step in the process is to ensure the Root CA is installed on the Windows 10 client machines. This will enable them to trust the DCs when making authentication requests.

Install ROOT CA on clients

Successful Connection

The easiest way to do this is to export the root certificate from the DC itself.

Export Root CA From DC

1. In the certificates store, expand the “Trusted Root Certificate Authorities” node on the left and click on Certificates.
2. Select the root certificate for you domain.

1. Right click it > All Tasks > Export

1. On the Export File Format, select DER encoded binary x.509 (.CER).

1. Click next, name the file and finish the wizard to save the file.

Install Root CA on Client

For now, we will just install this manually on the client. Once you have validated the full Windows Hello for Business process, you will want to deploy this certificate automatically with a management tool such as MEM or Workspace ONE. For Workspace ONE, you can check out this video on how to deploy certs. You will want to ensure this certificate comes down automatically during the Out of Box Experience

1. On the Windows 10 client, ensure you have fully completed the Out of Box Experience and enrolled into Windows Hello for Business.
2. Copy the Root Certificate to the client, such as the desktop.
3. Right-click the cert and click Install Certificate.
4. In the Certificate Import Wizard screen, select Local Machine as the Store Location.

1. Click Next and the Yes if prompted by UAC.
2. Select Place all certificates in the following store. Click Browse and select Trusted Root Certification Authorities. Click Next and Finish to complete the wizard.

1. Load up the certificate store on the client and ensure it got successfully installed

How to Check for Successful Hello

First, ensure that you have successfully registered for Hello for Business by setting up your PIN and completing Azure MFA.

After you complete these screens, Windows Hello for Business is successfully initialized. Let’s check to see if the key is successfully registered to Azure AD.

Check for Successful Key Registration

1. Open Event Viewer
2. Expand Applications and Services Logs > Microsoft > Windows. Navigate to User Device Registration. Click on Admin to view the log.
3. Look for a record with Event ID 300. You should see a “The Microsft Passport key was successfully registered with Azure AD”. This indicates that the public key was sent to Azure and AAD connect will then attempt to sync it back to on-premises Active Directory.

NOTE: The AAD Connect process, by default, is a sync every 30 min. Your organization may have changed this sync policy and so it may take longer. If you attempt to authenticate to on-premises resources such as a file share before the sync happens, you will probably see this popup:

Don’t type your username and password as that will NOT use Windows Hello for Business. Wait until the key has synchronized to AD. You can speed up the process by running a delta sync on AAD connect (see earlier in this article for the command)

Check for msDS-KeyCredentialLink

You will want to validate that the user object in Active Directory has the msDS-KeyCredentialLink attribute available and that it is populated with the key. There are a couple of ways to do this.

Check via ADUC

1. Open Active Directory Users and Computers
2. Click View > Advanced Features
3. Find the user object
4. Click on Member Of tab. Double-click one of the groups to bring up the group membership page (doesn’t matter which group).
5. While this is open, close the user properties page.
6. Go back to the group properties page and click on the Members tab.
7. Find the user and double click it.
8. The attribute editor tab should be visible now. Click Attribute Editor Tab
9. Scroll down and find the msDS-KeyCredentialLink value. It should be populated with the public key of the hello for business certificate. The private key is saved on the device in the Windows Passport store.

Check via PowerShell

An easier and quicker method is to use PowerShell. You must have the Active Directory PowerShell Module installed for this to work.

get-aduser bpeppin -Properties msDS-KeyCredentialLink

If this is empty, you will need to wait until the synchronization has been completed on AAD Connect.

Additionally, the user can have more than one entry here as well. Each time they go through the Out of Box experience and set up WHfB, a new key pair will be generated and synced back to AD.

A Successful Attempt

Once both of these things are completed, an authentication request to an on-premises file share should go through automatically without any prompting! Pretty slick. Also, if you run klist from the command prompt you will also see that a Kerberos ticket has been granted by the domain controller.

Check it out below!

Troubleshooting

If you followed this guide extremely close and were able to get this working on the first try, congratulations! You are awesome. However, due to the number of little things that need to be in place for this to work, there’s a good chance you have probably overlooked something. Since this blog is already so long, you’ll need to check out my troubleshooting Hello for Business blog for more details.

Conclusion

Wow, you made it! Well done on getting to the end. Now you know how to set up Windows Hello for Business and you should be proud. If you have been successful, let me know if the comments below! In my opinion, this is one of the coolest technologies that Microsoft has developed and is a must-have when doing Out of Box Experience. Enjoy using your PIN to access file shares.