EN 
05.11.2024 Miriam WELCOME IN MY WORLD

This website is originally written in the Czech language. Only part of the content is machine (AI) translated into English. The translation may not be exact and may contain errors.

Tento článek si můžete zobrazit v originální české verzi. You can view this article in the original Czech version.
Windows Hello for Business - nasazení Cloud Kerberos Trust

Windows Hello for Business - Cloud Kerberos Trust deployment

Edited 11.06.2023 19:20 | created | Petr Bouška - Samuraj |
Windows Hello creates a login credential (an asymmetric key pair, often protected by a TPM) for a user account in Azure AD (or AD) that is hard-coded to a specific device. The user sets a fingerprint (most often) to log in, with a PIN as a backup. In this article, we will describe a possible way to deploy Windows Hello for Business in a hybrid enterprise environment. This is the latest and very simple deployment method called Cloud Kerberos Trust.
displayed: 3 669x (3 398 CZ, 271 EN) | Comments [0]

Note: The second part of a mini-series focusing on Windows Hello for Business with Cloud Kerberos Trust deployment in a hybrid environment with Hybrid Azure AD Joined devices.

Windows Hello for Business Deployment

We can deploy Windows Hello for Business in various ways (models). It mostly depends on what environment we operate. Whether it's cloud-only, On-Premises only or hybrid. That is, whether our computers are AD Domain Joined, Azure AD Joined or Hybrid Azure AD Joined. Other circumstances can also influence the decision, such as whether we use AD FS or another Identity Federation Service, whether we require the use of cert-based authentication, etc.

Within the Microsoft 365 admin center, there is a guide Plan your passwordless deployment (Setup - Advanced deployment guides & assistance), where we answer several questions about our environment and receive recommendations on which deployment model to use.

There are three possible deployment models and various trust models that determine how users authenticate against AD:

  • Cloud-only deployment
  • On Premises deployment
    • Key Trust
    • Certificate Trust
  • Hybrid deployment
    • Key Trust
    • Certificate Trust
    • Cloud Kerberos Trust

Windows Hello for Business certificate (Smart Card Logon)

When we install a certificate into the Windows Certificate Store, the public key is stored in the registry and the private key is stored using the selected CSP.

Microsoft supports a number of Cryptographic Service Providers (CSP), newer versions are called Key Storage Providers (KSP). These are modules that work with private keys, handle their storage and generation, and perform cryptographic functions. Applications do not work directly with the private key, but use the CSP.

Note: I haven't found much information on this area in the Microsoft Windows Hello documentation, so I'm deriving and estimating conclusions.

Windows Hello for Business uses a special Microsoft Passport Key Storage Provider and emulates a smart card to ensure application compatibility. When an application uses a certificate, the certificate API locates the keys using the stored KSP.

When a user registers Windows Hello, a Self-signed Smart Card Logon certificate is issued to the user's store (valid for 30 years). If we connect to the computer via RDP, we won't see it. If we delete the certificate, it will be restored upon the next login.

The generated Windows Hello for Business public key is used in the certificate. The certificate has a private key managed by the Microsoft Passport KSP and stored in the TPM (we're not considering the SW option). Access is therefore protected by the Windows Hello for Business gesture.

The certificate has a subject in the format

User-SID/GUID/login.windows.net/Tenant-ID/User-Principal-Name

We can see the certificate using certmgr.msc. Using the certutil command, we can list all keys of the given CSP (the -v switch displays more details).

certutil -csp "Microsoft Passport Key Storage Provider" -key -v

Below is a sample output (some values are deleted). We can learn several important pieces of information here. For example, if the key is stored in TPM, then in the NgcKeyImplType section, the flag NCRYPT_IMPL_HARDWARE_FLAG is active (not in parentheses).

Microsoft Passport Key Storage Provider:
  S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz

  RSA
Key Id Hash(rfc-sha1): 
Key Id Hash(sha1): 
Key Id Hash(bcrypt-sha1): 
Key Id Hash(bcrypt-sha256): 
Container Public Key:
  ...
Cached Key Identifier: S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/./bouska@firma.cz: No container name match
Cached Key Identifier: S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/./bouska@firma.cz: No KeyId match
    NCRYPT_ALLOW_DECRYPT_FLAG -- 1
    NCRYPT_ALLOW_SIGNING_FLAG -- 2
      (NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4)
      (NCRYPT_ALLOW_KEY_IMPORT_FLAG -- 8)
      (NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215))
  UI Policy = 0
      (NCRYPT_UI_PROTECT_KEY_FLAG -- 1)
      (NCRYPT_UI_FORCE_HIGH_PROTECTION_FLAG -- 2)
    Version: 0
  Export Policy = 0
      (NCRYPT_ALLOW_EXPORT_FLAG -- 1)
      (NCRYPT_ALLOW_PLAINTEXT_EXPORT_FLAG -- 2)
      (NCRYPT_ALLOW_ARCHIVING_FLAG -- 4)
      (NCRYPT_ALLOW_PLAINTEXT_ARCHIVING_FLAG -- 8)
Name: S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz
Algorithm Group: RSA
Algorithm Name: RSA
Length: 2048 (0x800)
Lengths:
  dwMinLength = 2048 (0x800)
  dwMaxLength = 2048 (0x800)
  dwIncrement = 0 (0x0)
  dwDefaultLength = 2048 (0x800)
UI Policy:
  dwVersion = 1 (0x1)
  dwFlags = 0 (0x0)
  pszCreationTitle = (null)
  pszFriendlyName = (null)
  pszDescription = (null)
Export Policy: 0 (0x0)
    (NCRYPT_ALLOW_EXPORT_FLAG -- 1)
    (NCRYPT_ALLOW_PLAINTEXT_EXPORT_FLAG -- 2)
    (NCRYPT_ALLOW_ARCHIVING_FLAG -- 4)
    (NCRYPT_ALLOW_PLAINTEXT_ARCHIVING_FLAG -- 8)

NgcKeyImplType: 1 (0x1)
  NCRYPT_IMPL_HARDWARE_FLAG -- 1
   (NCRYPT_IMPL_SOFTWARE_FLAG -- 2)
   (NCRYPT_IMPL_REMOVABLE_FLAG -- 8)
   (NCRYPT_IMPL_HARDWARE_RNG_FLAG -- 10 (16))

Key Usage: 3 (0x3)
  NCRYPT_ALLOW_DECRYPT_FLAG -- 1
  NCRYPT_ALLOW_SIGNING_FLAG -- 2
    (NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4)
    (NCRYPT_ALLOW_KEY_IMPORT_FLAG -- 8)
    (NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215))

Serial Number: 
Issuer: CN=S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz
 NotBefore: 02.06.2023 13:15
 NotAfter: 02.06.2053 13:25
Subject: CN=S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): 

Private key is NOT exportable

Cancelling (deleting) Windows Hello registration

Many articles on the internet state that we can use the command line tool certutil if we want to delete Windows Hello for Business registrations on a device.

certutil.exe -DeleteHelloContainer

This deletes the Windows Hello container and removes associated locally stored information (credentials), such as PIN or fingerprints (it should also include WebAuthn and FIDO credentials). The certificate mentioned above (and possibly others stored in the container) will also be deleted. When we look at the settings after executing the command, we'll see that no method is set. Data stored in Azure AD will remain (we can delete them from the user's account in Azure AD).

C:\>certutil -DeleteHelloContainer

Deleted certificate CN=S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz
Sign out now to complete this task.
CertUtil: -DeleteHelloContainer command completed successfully.

Checking registration in Azure AD

When a user correctly registers Windows Hello for Business, a new authentication method is added to their account in Azure AD. In the user details in Azure Active Directory admin center - Users under Authentication methods, we'll see the Windows Hello for Business authentication method.

Note: We can delete the Windows Hello for Business method here and thus disable it for login.

Windows Hello for Business  - User Azure AD Authentication methods

We can view a summary of registered authentication methods for users, where we can filter for Windows Hello for Business. We can access the same information through two paths:

  • Azure Active Directory admin center - Security - Authentication methods - User registration details
  • Azure Active Directory admin center - Usage & insights - Authentication methods activity - User registration details
Windows Hello for Business  - All Users Azure AD Authentication method

Data in the client's registry

Windows Hello for Business uses the first three Credential Providers, which are identified by the following GUIDs:

  • PIN - {D6886603-9D2F-4EB2-B667-1971041FA96B}
  • Fingerprint - {BEC09223-B018-416D-A0AC-523971B639F5}
  • Facial Recognition - {8AF662BF-65A0-4D0A-A540-A338A999D36F}
  • Password - {60B78E88-EAD8-445C-9CFD-0B87F74EA6CD}
  • FIDO - {F8A1793B-7873-4046-B2A7-1F318747F427}
  • Smartcard - {8FD7E19C-3BF7-489B-A72C-846AB3678C96}

We can check if a user has registered Windows Hello for Business on the computer in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{D6886603-9D2F-4EB2-B667-1971041FA96B}. Under the PIN provider, there are SIDs of individual users. The value LogonCredsAvailable must be 1.

We can find out how the user is currently logged in (more precisely, what was the last interactive login) in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\LastLoggedOnProvider. The value indicates the GUID of the provider.

Cloud Kerberos Trust

For hybrid environments, the newest option Cloud Kerberos Trust is recommended. The deployment is very simple. Older models Key Trust and Certificate Trust have many complex requirements and the entire deployment is much more complicated.

To use Cloud Kerberos Trust, we must meet several prerequisites (Requirements):

  • The OS on workstations must be at least Windows 10 21h2 with KB5010415 installed (we shouldn't have an older version these days, and even this one is nearing end of support) or Windows 11 21h2 with KB5010414 installed
  • Domain controllers must be at least Windows Server 2016 with KB3534307 installed, Windows Server 2019 with KB4534321
  • Multi-factor Authentication is required for user account verification when registering Windows Hello for Business (all methods)
  • Accounts synchronized using Azure AD Connect

By default, we can't use Windows Hello for Business to log in with a privileged account. These are accounts that are in groups like Domain Admins, Account Operators, Server Operators, Print Operators, etc.

Deploying Windows Hello for Business with Cloud Kerberos Trust is very simple. As an administrator, we need to perform two steps. The user then performs the registration.

  • Create/deploy Azure AD Kerberos
  • Enable/configure Windows Hello for Business on selected devices
  • The user performs Windows Hello for Business registration (Provisioning) (we'll address this in the next part)

Azure AD Kerberos

Windows Hello for Business cloud Kerberos trust uses Azure AD Kerberos, which simplifies deployment compared to the Key Trust model. It doesn't need PKI nor does it perform public key synchronization from Azure AD to AD (there's no delay after Windows Hello registration). It doesn't increase the load on domain controllers during KDC authentication. Azure AD Kerberos is also used for security key authentication (FIDO2).

When Azure AD Kerberos is enabled in an AD domain, a computer object AzureADKerberos is created as a Read Only Domain Controller (not associated with any server). It's used by Azure AD to generate TGT (Ticket-Granting-Ticket) for the AD domain.

When a user authenticates using Windows Hello for Business, they can request a TGT from Azure AD (they receive it along with the Primary Refresh Token - PRT). They get a partial TGT, which they use to log in or access resources in AD. The KDC (domain controller) exchanges it for a (full) TGT. Domain controllers are still responsible for standard issuance of service tickets and authorization.

Deploying Azure AD Kerberos

We install the Azure AD Kerberos PowerShell Module

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

We create Azure AD Kerberos Server objects in AD and publish them to Azure AD. There are various authentication options for AD and Azure AD. Here's a variant where we run PowerShell under an account with domain administrator rights. Global administrator authentication is done using modern authentication (we enter their UPN).

Set-AzureADKerberosServer -Domain firma.local -UserPrincipalName bouska@firma.cz

We can display information about the created Azure AD Kerberos Server. We see that not only a computer account was created, but also a user account krbtgt_AzureAD. This holds the TGT encryption key, similar to the krbtgt account. A Service Connection Point (SCP) CN=900274c4-b7d2-43c8-90ee-00a9f650e335,CN=AzureAD,CN=System,<domain-DN> was also created. In Azure AD, a KerberosDomain object is created.

PS C:\> Get-AzureADKerberosServer -Domain firma.local -UserPrincipalName bouska@firma.cz

Id                 : 25205
UserAccount        : CN=krbtgt_AzureAD,CN=Users,DC=firma,DC=local
ComputerAccount    : CN=AzureADKerberos,OU=Domain Controllers,DC=firma,DC=local
DisplayName        : krbtgt_25205
DomainDnsName      : firma.local
KeyVersion         : 41992547
KeyUpdatedOn       : 11.05.2023 12:42:56
KeyUpdatedFrom     : dc1.firma.local
CloudDisplayName   : krbtgt_25205
CloudDomainDnsName : firma.local
CloudId            : 25205
CloudKeyVersion    : 41992547
CloudKeyUpdatedOn  : 11.05.2023 12:42:56
CloudTrustDisplay  :

From a security perspective, it is recommended to regularly change (rotate) the KRBTGT encryption keys for the Azure AD Kerberos Server. We can do this using the cmdlet.

Set-AzureADKerberosServer -Domain firma.local -UserPrincipalName bouska@firma.cz -RotateServerKey

Configuring device settings using Group Policy

To allow users to register and use Windows Hello for Business, we can use Group Policy. Based on the Windows settings, it determines whether the user should attempt to register credentials. We can set the enablement of Windows Hello for Business for computers or users. However, Cloud Kerberos Trust requires settings that are only available as computer configuration.

To set the corresponding policies, we must have sufficiently new ADMX templates for Windows 10/11 (currently the latest for Windows 10 is version 22H2). Links to download different versions can be found in How to create and manage the Central Store for Group Policy Administrative Templates in Windows. Optimally, we upload them to the Central Store.

Enabling Windows Hello for Business

Windows Hello for Business configuration in Group Policy is located in the path

Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Hello for Business

There are several settings here, three are important for our situation:

  • Use Windows Hello for Business - we enable the use of Windows Hello
  • Use cloud trust for on-premises authentication - we enable the use of Azure AD Kerberos
  • Use a hardware security device - requires the use of TPM 1.2 or 2.0 (we can set only TPM 2.0)
  • Use certificate for on-premises authentication - must not be set, using certificates would take precedence
Windows Hello for Business  - konfigurace pomocí Group Policy

Non-enforced enabling of Windows Hello for Business

In the Use Windows Hello for Business settings, we can check Do not start Windows Hello provisioning after sign-in. With this setting, users are not prompted to configure Windows Hello after signing in (registration is not enforced). They can perform the registration themselves later in Settings - Accounts - Sign-in options. Until they perform the configuration, Windows Hello will not be available.

PIN Complexity

If we want to set PIN requirements, the configuration is located in Group Policy in the path

Computer Configuration/Policies/Administrative Templates/System/PIN Complexity

Note: Once, there was also a setting Use Phone Sign-in in Group Policy, which was supposed to allow using Authenticator. But Microsoft apparently cancelled it and the current documentation notes it as Not currently supported.

Blocking password login

We can also block password login when we require the use of Windows Hello for Business or a certificate from a smart card (or FIDO2). This is a Group Policy setting Interactive logon: Require Windows Hello for Business or smart card in the path

Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

Configuring device settings using Intune

We can enable and configure Windows Hello for Business using Intune in two ways:

  • Tenant-wide policy - we can create settings for the entire Tenant, which are applied only when a device registers with Intune (policy changes do not affect already registered devices)
  • Configuration profile - we create a configuration profile that we assign to a group of devices, changes take effect on assigned devices

Tenant-wide configuration is done in Microsoft Endpoint Manager admin center - Devices - Enroll devices - Windows enrollment - Windows Hello for Business.

Setting up using a configuration profile

Usually, we need to create a configuration profile (the documentation also mentions other options, besides those listed below, such as Endpoint security Account protection policy).

  • Microsoft Endpoint Manager admin center - Devices - Configuration profiles

We can use the Identity protection template, where we enable Windows Hello for Business and set various parameters (including PIN requirements). But we can't set Cloud Kerberos Trust here.

Therefore, we must create another profile from the Custom template. Where we manually set the OMA-URI ./Device/Vendor/MSFT/PassportForWork/<tenant ID>/Policies/UseCloudTrustForOnPremAuth, type Boolean with value True.

Or there's a second option to create a Settings catalog profile, where we find the Windows Hello For Business category. The configuration is less clear than using a template, but there are more settings (including PIN requirements). Some configurations are separate for devices and for users. We have the main options here:

  • Use Passport for Work - enabling Windows Hello for Business (the item uses the old Passport name)
  • Use Cloud Trust For On Prem Auth - enabling Azure AD Kerberos
  • Require Security Device - requiring TPM
Windows Hello for Business  - konfigurace pomocí Intune

I couldn't find the option in Intune that exists in Group Policy, Do not start Windows Hello provisioning after sign-in. Probably the only solution is to create a configuration using registry keys HKLM\SOFTWARE\Policies\Microsoft\PassportForWork\DisablePostLogonProvisioning.

We assign the profile to a device group. This is necessary for using Cloud Kerberos Trust. Also, when assigned to users, only one user can register on the device with Windows Hello.

Extended Windows Hello features

Dynamic Lock

Dynamic Lock allows pairing a mobile phone (or other device) with a computer using Bluetooth. When the phone's signal is too weak and the computer is not in use, it automatically locks.

  • the setting is located in Windows under Settings - Accounts - Sign-in options
  • using Group Policy under Windows Hello for Business - Configure dynamic lock factors

Multi-Factor Unlock

Multi-Factor Unlock allows setting up a requirement for two methods to unlock Windows. We can set a combination of fingerprint, face scan, PIN, and Trusted Signal (only as a second factor, phone proximity or trusted network location).

  • Group Policy setting under Windows Hello for Business - Configure dynamic unlock factors

Dual Enrollment

Allows using two accounts on a computer, one privileged and the other standard, under which we usually work. Within the non-privileged account, we can use Remote Desktop Connection or run an application as Run as different userand use Windows Hello for Business login with the privileged account.

Smart Card Logon certificates are used for this, which we must have properly deployed. We must also allow access to certificates of all users within the computer (Group Policy under Windows Hello for Business - Allow enumeration of emulated smart cards for all users).

PIN Reset

In Windows settings, we can change our Windows Hello PIN. If we forget it, we can perform a reset, where we log in and verify using MFA and set a new PIN.

There are two ways to reset the PIN:

  • destructive PIN reset - deletes the original PIN, keys, certificates, etc. in the Windows Hello container and creates new ones, works automatically without configuration, Hybrid Azure AD Joined devices must have an available domain controller
  • non-destructive PIN reset - requires Microsoft PIN reset service (an Enterprise application that is activated in Azure AD), a PIN reset protector (256-bit AES key) is added to the Windows Hello container on the device, during reset it's used to change the PIN, so the keys remain preserved, we must enable it using Group Policy Use PIN recovery or Intune EnablePinRecovery

Remote Desktop - connecting to a remote desktop

We use Windows Hello for Business for interactive (local) login to the computer. When we log in to the computer remotely (Remote Desktop), we must use a different authentication method (password).

If we are logged in to the computer using Windows Hello for Business, we can connect remotely to another computer using Remote Desktop Connection from this computer. The RDP protocol doesn't support Windows Hello for Business, but it's possible to use a certificate that is protected by Windows Hello for Business (stored in the Windows Hello Container). The RDP feature of smart card redirection is used. Or deploy Windows Defender Remote Credential Guard.

Windows Hello for Business certificate

After registering Windows Hello for Business, the user has a Smart Card Logon certificate with Windows Hello keys on the computer. During remote connection, authentication with this certificate with a set gesture is automatically offered. Login with this Self-signed certificate doesn't work, it doesn't contain the correct UPN and isn't trusted.

Windows Hello for Business - RDP s certifikátem

Windows Hello for Business emulates a smart card. Older versions of Windows 10 redirect access to the private key (emulated smart card) using Microsoft Smart Card KSP, so it's possible to use a PIN. From Windows 10 version 1809, redirection doesn't occur, but Microsoft Passport KSP is used, which supports the use of biometrics. For compatibility, we can enable the original functionality using Group Policy Use Windows Hello for Business certificates as smart card certificates.

Issuing Smartcard Logon certificate

If we want to use Windows Hello for Business for RDP (for example with Cloud Kerberos Trust) and we have an internal CA (PKI set up), we can create a special Smartcard Logon certification template and issue certificates to users. The description is in the article Deploy certificates for remote desktop (RDP) sign-in. The main thing is to change the CSP to Microsoft Passport KSP, which must be done by exporting the template and text editing.

Login with the issued Smart Card Logon certificate works, but only PIN use is offered to me (I couldn't get biometrics to work).

Windows Hello for Business - RDP se Smart Card Logon certifikátem
Author:

Related articles:

Azure AD / Entra ID identity and authentication

Articles related to user and device identity (not only) in Microsoft Entra ID. Different login and authentication options. Areas such as modern authentication, multi-factor authentication, password-less login, etc. Often involving the use of FIDO Authentication, for example using the FIDO2 security key or Windows Hello for Business.

FIDO Authentication

FIDO authentication is based on the FIDO2 standard (WebAuthn and CTAP2). It brings a more secure option to log in to online services. It belongs to Passwordless MFA (multi-factor authentication without a password). At the same time, it increases the convenience of users (it supports the use of biometrics). These are, for example, Windows Hello for Business, FIDO2 security key and generally passkeys (access keys).

If you want write something about this article use comments.

Comments

There are no comments yet.

Add comment

Insert tag: strong em link

Help:
  • maximum length of comment is 2000 characters
  • HTML tags are not allowed (they will be removed), you can use only the special tags listed above the input field
  • new line (ENTER) ends paragraph and start new one
  • when you respond to a comment, put the original comment number in squar brackets at the beginning of the paragraph (line)