Windows hello для бизнеса что это

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

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

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

Everyone can use Windows Hello, but how about its business-based counterpart? Here’s everything you need to know.

You’ve probably heard of Windows Hello before. It’s a convenient feature that lets you unlock your device using biometrics (such as fingerprints or facial recognition).

Now, there’s another incredible tool called Windows Hello for Business. But what are its benefits, and how is it different from Windows Hello? Let’s explore everything about the “Windows Hello for Business” tool, how it works, why you should use it, and more.

What Is Windows Hello for Business?

Windows Hello for Business is a tool that allows you to unlock your device using biometrics or a PIN. It lets you access your device via fingerprint, facial recognition, and iris recognition. Each one of these has its own strengths and weaknesses, so be sure to check out our article on the most secure login option between face, iris, fingerprint, password, or PIN logins. It also uses multi-factor authentication (MFA) to ensure that your device is secure.

Although the tool might sound a bit similar to Windows Hello, it’s actually more secure. You can use Windows Hello for Business for both on-premise and cloud resources. For example, you can use it with Hybrid Azure Active Directory-joined, Azure AD, and Azure Active Directory-joined devices.

Interestingly, you can also use this tool on domain-joined devices (the devices that are connected to a specific domain such as a company intranet).

Let’s take a look at how this tool works.

Registration

This is the phase where the device registers with an identity provider (IDP). Simply put, an IDP refers to a service that stores and manages your digital identity.

For example, let’s say that a third-party website prompts you to log in to a certain tool using your Google account. In this case, Google is the identity provider.

Now, each “Windows Hello for Business” deployment option has a different identity provider.

For on-premise deployments, the identity provider is usually Active Directory Federation Services (AD FS). Meanwhile, Azure Active Directory is usually the identity provider for cloud and hybrid deployments.

Provisioning

After the registration part, you can now set up the «Windows Hello for Business» tool. This is where you’ll select the various methods for unlocking your device (such as using biometrics or a PIN).

From there, you should be ready to log in to your device using your preferred method. Each time you log in, the identity provider will verify your identity.

What Are the Benefits of Biometric Authentication?

Both Windows Hello and Windows Hello for Business come with these incredible features:

• Extra Layer of Security: It’s often easy for someone to crack your password and hack into your system. But the Windows Hello and Windows Hello for Business tools also give you the option to use biometrics. Now, this makes your device more secure because it’s difficult to replicate your biometric data.
• Convenience: Let’s face it—unlocking your device with a long password can often be quite irritating. And if you enter the wrong password, you have to start from scratch. But when using biometrics, you can sign in to your device within seconds.

You’re probably wondering why it might be worth picking Windows Hello for Business over Windows Hello. Well, it all comes down to security features!

Let’s now explore some of the benefits of using Windows Hello for Business.

Here’s why you might want to consider using Windows Hello for Business:

• Certificate-Based Authentication: Unlike Windows Hello, the «Windows Hello for Business» tool uses certificate-based authentication. This process uses a digital certificate to identify a user before granting them access to a resource, an app, or a network.
• Reduced Number of Password Resets: It’s common for employers to forget their login credentials. So, this means administrators might have to do frequent password resets. However, Windows Hello for Business’ multi-factor authentication ensures that you can unlock your device in various ways. So, it’s highly unlikely that you might end up locking yourself out of your device and requesting password resets.
• SSO Support: Unlike Windows Hello, the «Windows Hello for Business» tool supports single-sign-on (SSO) functionality. With SSO, you can sign in to multiple services with the same set of credentials.

By now, it’s clear that Windows Hello for Business is more secure and can be quite convenient than Windows Hello (especially if you’re a business owner).

How Do You Enable and Deploy Windows Hello for Business?

Let’s check out how you can enable and deploy Windows Hello for Business.

How to Enable Windows Hello for Business

You can enable Windows Hello for Business using the Local Group Policy Editor (LGPE).

Here are the steps you need to follow:

1. Press Win + R to open the Run command dialog box.
2. Type gpedit.msc and press Enter to open the LGPE.
3. Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business.
4. Double-click on the Use Windows Hello for Business option on the right-hand side.

Select Enabled in the top-left corner. Finally, press Apply and then press OK.

Besides enabling the tool, you can also configure some of its settings in the LGPE. For example, you can configure the tool to use PIN recovery. Additionally, you can choose to use a certificate for on-premise authentication.

Here’s how to configure additional «Windows Hello for Business» settings using the LGPE:

1. Open the Local Group Policy Editor as per the previous steps.
2. Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business.
3. Select any of the options on the list (except for the «Use Windows Hello for Business» option).
4. To enable the option you’ve picked, select Enabled on the next screen. Finally, press Apply and then press OK.

Additionally, you can configure some LGPE settings by checking out the Windows Hello for Business Policy Settings on the Microsoft website.

How to Deploy Windows Hello for Business

There are various ways to deploy Windows Hello for Business. If you want to deploy it for cloud devices, the process will depend on your organization’s cloud-based identity and access management (IAM) service. An example of an IAM is Azure AD.

And if you want to deploy the tool for on-premise devices, there are different methods for that too.

To get started, check out the infrastructure requirements for deploying Windows Hello for Business on the Microsoft website. From there, check out the Windows Hello for Business Deployment tips to find out how you can deploy this tool for your business.

Easily Access Your Device With Windows Hello for Business

Using long and complicated passwords on Windows is a thing of the past. You can now easily unlock your device using biometrics.

Wondering which tool can help you access Windows via biometrics? Try the “Windows Hello for Business” tool, especially if you’re a business owner.

But if you’re looking for something simple, give Windows Hello a try. And in case this tool runs into issues, there are some solutions you can check out.

Доброго времени суток, Уважаемый. Сейчас я постараюсь рассказать что такое 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 кода, отпечатка пальцев и т.д.

Turning on and logging into a Microsoft Windows-based PC is a much quicker and more streamlined process than it used to be.

Years ago, it usually entailed sitting through a lengthy startup operation and then needing to key in a complicated password just to gain access to the system. Forgetting the right login credentials was naturally a major setback, requiring either an administrator-initiated reset for a domain account, or the use of a password hint or a reset disk stored on a USB flash drive.

The use of non-local Microsoft accounts, with straightforward reset mechanisms, as login accounts for Windows 10 devices has made life a bit easier. Plus, the replacement of hard-disk drives with solid-state drives has greatly sped up the overall startup process. But the password bottleneck is still there.

Password-based security puts a burden on both end-users and IT admins:

• Users have to remember and enter complex and unique passwords that meet minimum requirements for length, use of special characters and exclusion of their account names.
• Admins have to configure the appropriate password settings and perform frequent resets. Gartner has estimated that between 20% and 50% of all help desk calls are for password resets.

In this context, Windows Hello for Business and its consumer-oriented counterpart Windows Hello provide immense relief.

What is Windows Hello for Business

At its core, Windows Hello for Business provides a new, non-password credential for Windows 10 devices. It implements 2FA/MFA, meaning multilayered security that is much more difficult to bypass than protection that hinges solely on a correct username and password combination.

Why Windows Hello for Business is more secure

A desktop or mobile device that is secured only with that type of single-factor authentication is vulnerable if its login information is ever stolen or successfully guessed, allowing for unauthorized access and possible data exfiltration. Single-factor accounts are particularly at risk from phishing attacks that attempt to harvest logins via email.

According to PhishMe research, over 90% of data breaches begin with a spear-phishing email. Phishing has grown more sophisticated over time, in some cases using real-looking login pages that are actually malicious sites. In addition to phishing, passwords are also vulnerable to other threats such as replay attacks or any campaign that could potentially expose credentials stored on a server.

With strong 2FA through Windows Hello for Business, these particular risks don’t apply. Authenticating into a targeted user’s account would require more than just possessing their physical device and its private key (strong credential). Any attacker would also need to know either the specific PIN or have the biometric credential associated with it, to access that same key. A model Windows Hello for Business implementation has multilayered defenses, each of which is difficult for any unauthorized user to bypass.

How Windows Hello for Business works

The device itself

Windows Hello for Business’s strong credentials are bound to particular devices, with private keys or certificates. It may use either an enterprise’s public key infrastructure (PKI) or certificate-based authentication for trust. Which one is preferable will depend on whether an organization wants to issue end-entity certificates to its users and what specific version of Windows Server Domain Controllers it has in place. Certificate-oriented deployments are similar to smart cards/virtual smart cards in that they have managed expirations and renewals.

Exploring all the possible implementation options is beyond our scope, so let’s examine just one in more depth. For a hardware-oriented setup with PKI, Windows Hello for Business will draw upon the unique, tamper-proof trusted platform module (TPM) chip contained in the device to generate and protect the private key. Since the TPM chip is a dedicated cryptographic hardware element integrated into a PC or mobile device’s motherboard, the private key never leaves the device. Likewise, fingerprint profiles in VeriMark solutions are stored in a TPM.

Meanwhile, a Windows Hello for Business public key is mapped to the device by the authentication server, which may use Active Directory, Azure Active Directory or a Microsoft account as its identity provider. The resulting user key (i.e., the TPM-protected private key on an enrolled device, and the server-registered public key) is one factor in Windows Hello for Business’s strong second-factor authentication structure.

The pairing of the two keys authenticates the user into their account, but only after they have provided something else to prove they are the trusted possessor of the private key, namely a PIN or biometric credential. The total combination ensures that each login includes something the user has (the device/private key), knows (the PIN), and/or is (biometrics).

The PIN

At first glance, it might seem like a Windows Hello for Business PIN is just a password by another name, since it’s textual and must be remembered. But they’re nothing alike in practice.

For starters, a PIN is tied to a specific device. Even if someone knows the PIN, they would need the hardware it corresponds to as well. That’s not the case with passwords, which can be used for logging in from virtually anywhere regardless of device.

The PIN is also stored locally and never reaches a remote server. As a result, there is no prospect of a massive data breach that would expose the PIN. A correct PIN simply unlocks the private key that signs the request to the authentication server.

For devices with TPM chips, built-in anti-hammering measures prevent brute-force guessing of even simple PINs, were the device to be lost or stolen. A series of incorrect guesses will lock the device, rendering the private key inaccessible.

Admins may also set complexity requirements for PINs within Microsoft Intune, as with passwords. The PIN is required even if biometric sign-in is preferred, since it provides recourse if the fingerprint reader or other specialized technology isn’t working or is otherwise unavailable.

The biometrics

Biometric authentication provides the most convenient and secure second factor for Windows Hello for Business. A user provides a fingerprint or face/iris scan as the primary gesture for accessing their device-specific credentials, while the PIN serves as a required backup option.

Using Windows Hello for Business compliant biometric devices is beneficial for multiple reasons:

• Someone’s fingerprint or face shape is difficult to steal or spoof in any reliable fashion, as it is unique to each individual.
• Logging in with biometrics is very streamlined, requiring only a quick glance or placement of the finger.
• The biometric data itself is stored only on the local device and never transmitted to a server, thereby avoiding the creation of a remotely accessible and breachable credential repository.

Additionally, there is flexibility in what types of hardware can be used to implement biometrics in Windows Hello for Business. Important features to consider include false acceptance and false rejection rates for the biometric login.

The Kensington VeriMark IT Fingerprint Key has rates that far exceed the minimum requirements for Windows Hello-compliant solutions. Its Match-in-Sensor technology, compatibility with FIDO2 passwordless authentication standards and compact design also make it highly reliable and portable in multiple possible contexts. VeriMark solutions are tightly aligned with Windows Hello for Business and are crucial components in implementing the platform in an enterprise context.

Additional benefits from Windows Hello for Business

Beyond its considerable advantages over password-based authentication, Windows Hello for Business is also appealing because of its broad compatibility with existing enterprise infrastructures and functions.

Flexible on-prem, cloud and hybrid options

Enterprises may deploy Windows for Business on-premises, in the cloud, or in a hybrid deployment that blends the two. The implementation type will affect the usable identity providers and what types of additional factors can be used for 2FA/MFA during the initial provisioning of the strong credential.

Cloud and hybrid deployments will use Azure Active Directory while an on-prem one will rely on a Windows Server 2016 Active Directory Federation Services. Also, cloud and hybrid implementations of Windows Hello for Business can accept a broader range of additional factors during strong credential setup, to ensure that the private key is issued to a device in the possession of a trusted user.

Certificates and customizable Microsoft Intune configurations

We mentioned certificate-based forms of Windows Hello for Business earlier. These are similar to existing smart card or virtual smart card scenarios and can be managed through Microsoft Intune.

Within Intune, it’s also possible to create an organization-wide policy during device enrollment. Admins can set specifications such as PIN and biometrics requirements and decide whether to require enrolled devices to have TPM chips onboard.

SSO and remote access for Windows Hello for Business devices

Because Windows Hello for Business can authenticate someone into an Active Directory or Azure Active Directory account, it also has support for SSO. Through SSO, users can sign into multiple services with a common set of credentials and not have to reenter them on a per-application basis.

Certificate-based Windows Hello for Business is also fully compatible with the Windows 10 VPN Client. Once the correct biometric gesture or PIN is supplied, the VPN uses the certificate to authenticate the user’s connection.

A reduced security burden on IT

Windows Hello for Business replaces passwords in every common situation except for the initial one-time provisioning of its strong credentials. That means IT doesn’t have to sink so much time into resetting users’ passwords and verifying their identities.

Every moment the help desk spends on password resets is one it can’t devote to more strategic projects. Windows Hello for Business is not only more secure than password reliance, but more scalable, sustainable and cost-effective, too.

Windows Hello for Business versus Windows Hello, explained

These two solutions implement strong second-factor authentication (2FA, or MFA for multi-factor authentication), via options such as biometrics and local PINs that replace traditional passwords during the login process; learn more about 2FA/MFA in our blog on this topic. As such, they both provide an ideal combination of convenience and security, with greater usability and stronger protection than text-based passwords could ever offer.

However, despite their almost identical names, the two are quite different from each other. Windows Hello is relatively simple and uses biometrics, namely fingerprint reading, iris scanning and facial recognition, using a device’s integrated camera or fingerprint reader, or compatible external hardware. Although Windows Hello for Business can leverage biometrics as well, it has a more complex architecture that uses asymmetric key pairs together with device PINs. We’ll discuss some of the technical details of how this works later, to show how it surpasses traditional password security.

All of this added complexity also allows it to support a much broader, more enterprise-centric set of features. Devices fully configured for Windows Hello for Business can use it to sign into an Active Directory, Azure Active Directory or Microsoft account. Support for third-party identity providers that adhere to the FIDO2 standard was in progress as of October 2019. The Kensington VeriMark IT Fingerprint Key also supports FIDO2 within the confines of a Microsoft environment.

Plus, Windows Hello for Business devices can take advantage of single sign-on (SSO) or, with certificate-based PINs, enjoy remote access through a VPN without the need for additional multifactor authentication with phone verification. Those are both pivotal benefits for today’s increasingly remote workforces, which require streamlined access to multiple critical apps and services without needing to jump through the hoops of complex passwords and drawn-out reset requests.

Overall, Windows Hello for Business incorporates its sophisticated functionality into an intuitive and uncomplicated experience for end users, not to mention a more manageable security architecture for IT admins. 

How do I set up Windows Business Hello

Microsoft has published a useful guide on how to begin planning a Windows Hello for Business deployment. As you get further into the details, it’s time to think about what modes of biometric authentication you want to incorporate into your implementation.

Kensington biometric solutions like the new VeriMark IT Fingerprint Key support Windows Hello for Business and can be used to support its strong second-factor authentication. Learn more on our biometrics page or download the eBook Moving Past the Password with VeriMark and VeriMark IT.

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:\Windows\System32\CertServer…”
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.local\crl$\<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:\System\CurrentControlSet\Control\Lsa -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:\Windows\system32\certsrv\certenroll\*.crt \\pki.brookspeppin.local\crl$

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.