Setting Up Windows Hello for Business with Cloud Trust

 

 

Difference Between WHFB Hybrid Key Trust and WHFB Hybrid Cloud Trust

A hybrid device refers to a device that is connected to both on-premises and cloud-based infrastructure. When discussing a hybrid device, it is necessary to determine which Identity Provider (IdP) is responsible for authenticating the user's identity. An IdP is a system that is responsible for verifying the identity of a user or device and issuing credentials that can be used to access resources.

 In the case of Hybrid Key Trust, Active Directory is the authoritative IdP, while Azure AD is considered secondary. The authoritative IdP is the primary source for managing and authenticating the user's identity and is responsible for tasks such as account lockout for disabled user accounts. 

On a hybrid device, the user's identity is tied to both Active Directory and Azure AD. However, when a user attempts to authenticate on the device, the authentication request is first sent to the authoritative IdP (Active Directory). If the authentication is successful, the user will receive a Primary Refresh Token (PRT) from Active Directory. The PRT is a secure token that is issued by Azure AD and is used to access resources in the Azure AD tenant. If the authentication with Active Directory fails, the authentication request will be sent to Azure AD as a secondary source.

It is important to determine the authoritative IdP for a hybrid device because it determines the primary source for managing and authenticating the user's identity. In the case of Hybrid Key Trust, Active Directory is the authoritative IdP.

 

 

In a Hybrid Cloud Trust scenario, the identity model is reversed, with Azure AD serving as the authoritative Identity Provider (IdP) and Active Directory as the secondary source. This means that Azure AD is responsible for verifying the user's identity and issuing credentials that can be used to access resources.

The authoritative IdP can be identified through the security events recorded on the device. When a user logs into the device, a 4624 user logon event with a logon type of 11 (cached interactive) will be recorded, even if Active Directory is available. This event indicates that the user's identity has been authenticated by the IdP. Soon after, if Active Directory is available, a second 4624 user logon event with a logon type of 7 (normally indicating workstation unlock) may be recorded. This event indicates that the user's identity has been authenticated by the secondary IdP (Active Directory).

 

It is important to note that even if the user's account is disabled in both Azure AD and Active Directory, local login on the device will still be possible. This is because the device is able to authenticate the user's identity using cached credentials. However, when the user attempts to access cloud-based resources, they will be unable to do so because their account is disabled in the authoritative IdP (Azure AD). In this case, the user will receive an error indicating that they need to sign in (which will fail) in thick-client applications like Teams, and through the web, they will be informed that their account is locked out. Access to resources in Active Directory will also be denied, and a failed sign-on event with a failure indicating a disabled account will be recorded in the security event log.

 It is important to determine the authoritative IdP for a hybrid device because it determines the primary source for managing and authenticating the user's identity. In the case of Hybrid Cloud Trust, Azure AD is the authoritative IdP.

 

 

What is MFA and why do we use it in Windows Hello For Business

 

Multi-factor authentication (MFA) is a security measure that requires users to provide additional proof of identity beyond just a username and password. MFA is widely used to increase the security of online accounts and protect against unauthorized access.

Windows Hello for Business is a feature that allows users to authenticate their Windows devices using MFA. Instead of just a username and password, Windows Hello for Business uses biometric factors (such as fingerprint or facial recognition) or a PIN code to verify the user's identity. This adds an extra layer of security to the login process and makes it more difficult for unauthorized users to gain access to the device.

In addition to these biometric factors, Windows Hello for Business also uses the built-in Trusted Platform Module (TPM) chip on the device to provide a second factor of authentication. This chip stores cryptographic keys and helps to ensure that the login process is secure.

Windows Hello for Business can be extended to include additional MFA factors, such as trusted signals from other devices or locations. This can further increase the security of the login process and help to protect against unauthorized access.

 

 

Overview of Windows Hello for Business and its benefits

Windows Hello for Business (WHfB) is a feature that enhances the security of Windows devices by replacing traditional passwords with multi-factor authentication. Instead of just a username and password, WHfB requires users to provide additional proof of their identity through biometric factors (such as facial recognition or fingerprint scanning) or a personal identification number (PIN).

To ensure the authenticity of these authentication methods, WHfB utilizes the Trusted Platform Module (TPM) chip on the device to generate a unique key. This key is sent to the identity provider (Azure AD) to obtain an authentication token, which grants the user access to the device.

In addition to biometric and PIN authentication, WHfB can also be configured to use trusted signals as a third factor of authentication. Trusted signals may include the Bluetooth signal from a user's phone, network information, or other indicators of the user's location or device. This allows for a dynamic login experience, where the level of authentication required may vary depending on the user's location or other factors.

Overall, Windows Hello for Business provides a secure and convenient alternative to traditional passwords, helping to protect against unauthorized access to devices.

 

Explanation of MFA and how it works with Windows Hello for Business Taken from Microsoft Page

 

 

A common question that arises is why a PIN is considered more secure than a password. While a password may seem more secure due to its greater length and the use of letters, numbers, and special characters, a PIN offers its own unique advantages.

For one, a PIN can only be used on a specific device, whereas a password can be used on any device or even online (such as in the case of Microsoft 365). This means that even if someone knows your PIN, they still need physical access to your device in order to log in to your account.

However, it's important to note that a PIN alone is vulnerable to shoulder surfing, where someone could potentially observe and memorize your PIN as you enter it. To mitigate this risk, you can use Multi-Factor Unlock, which uses trusted signals such as the Bluetooth connection from your phone to verify that it is you attempting to log in.

Additionally, Windows Hello for Business uses an algorithm to check for a constant delta between one digit and the next, which prevents the use of repeating, sequential, or simple patterns. This means that simple PINs such as "1234" or "4321" are not allowed. By enforcing these security measures, Windows Hello for Business helps to ensure the secure authentication of your device.

 Windows Hello is a biometric authentication feature that allows users to log in to their Windows devices using facial recognition, fingerprint scanning, or iris recognition. It was introduced with Windows 10 and is designed to provide a secure and convenient alternative to traditional passwords.

Windows Hello for Business is a variant of Windows Hello that is specifically designed for use in enterprise environments. It provides the same biometric authentication capabilities as Windows Hello, but also adds support for multi-factor authentication (MFA) and the ability to integrate with Azure Active Directory (Azure AD).

 

Difference Between Windows Hello and Windows Hello for Business

Windows Hello is a biometric authentication feature that allows users to log in to their Windows devices using facial recognition, fingerprint scanning, or iris recognition. It was introduced with Windows 10 and is designed to provide a secure and convenient alternative to traditional passwords.

Windows Hello for Business is a variant of Windows Hello that is specifically designed for use in enterprise environments. It provides the same biometric authentication capabilities as Windows Hello, but also adds support for multi-factor authentication (MFA) and the ability to integrate with Azure Active Directory (Azure AD).

One of the main differences between Windows Hello and Windows Hello for Business is the way they are deployed and managed. Windows Hello is a consumer-facing feature that is available to all users of Windows 10. It is configured on a per-device basis and is intended for personal use.

On the other hand, Windows Hello for Business is designed for use in enterprise environments and is typically deployed and managed through Group Policy or mobile device management (MDM) solutions. It can be configured to use MFA with trusted signals, such as the Bluetooth connection from a user's phone, to provide an extra layer of security. Windows Hello for Business can also be integrated with Azure AD, allowing organizations to manage the authentication process for their users across multiple devices and platforms.

Overall, Windows Hello for Business offers a secure and convenient authentication solution for enterprise environments, providing the same biometric capabilities as Windows Hello while also supporting MFA and integration with Azure AD.

 

Implementing Hybrid Cloud Trust:

 

If you have a hybrid environment with both on-premises Active Directory and Azure AD, then Cloud Trust is the recommended method for implementing Windows Hello for Business. Cloud Trust allows for an easier deployment of Windows Hello for Business compared to the older methods of Key Trust or Certificate Trust.

To implement Cloud Trust, you will need to set up Azure AD Kerberos using PowerShell and deploy it on devices using Group Policies. This process will allow you to take advantage of the convenience and security of Windows Hello for Business in your hybrid environment.

Requirements

To implement Windows Hello for Business with Cloud Trust, you must ensure that you meet the following requirements:

• Multi-factor authentication must be enabled.
• Your devices must be running Windows 10 21H2 or later, or Windows 11.
• Your domain controllers must be fully patched Windows Server 2016 or later.

Ensuring that these requirements are met will allow you to successfully use the Cloud Trust method to deploy Windows Hello for Business in your environment.

Creating the Azure AD Kerberos Server object

 

To enable Azure AD Kerberos in your domain and enable Windows Hello for Business, you will need to take the following steps:

1. Install the Azure AD Kerberos PowerShell module on your domain controller:
• Open Windows PowerShell as an administrator
• Run the command Install-Module -Name AzureADKerberos
2. Connect to Azure AD:
• Run the command Connect-AzureAD
• Enter your Azure AD credentials when prompted
3. Set up Azure AD Kerberos:
• Run the command New-AzureADKerberosServer
• Follow the prompts to set up the Azure AD Kerberos server object

Note: If you are already using passwordless SSO in your environment, you may have already deployed Azure AD Kerberos and can skip this step.

By completing these steps, you will have set up Azure AD Kerberos in your domain and are ready to configure Windows Hello for Business.

 

# Install the Azure AD Kerberos PowerShell Module.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber 

 

After running the script, the AzureADKerberos computer object will be added to the Domain Controller OU in your Active Directory

A Read Only Domain Controller (RODC) object will be created. It will not be associated with a physical server, but will be used to generate Ticket Granting Tickets (TGTs) for Active Directory

 

Administrators use the Azure AD Kerberos PowerShell module to create an Azure AD Kerberos Server object in their on-premises directory.

Run the following steps in each domain and forest in your organization that contain Azure AD users:

1.      Open a PowerShell prompt using the Run as administrator option.

2.      Run the following PowerShell commands to create a new Azure AD Kerberos Server object both in your on-premises Active Directory domain and in your Azure Active Directory tenant.

 

# Specify the on-premises Active Directory domain. A new Azure AD

# Kerberos Server object will be created in this Active Directory domain.

$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory global administrator username and password.

$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Global Administrators group for Azure AD.'

# Enter a domain administrator username and password.

$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.'

# Create the new Azure AD Kerberos Server object in Active Directory

# and then publish it to Azure Active Directory.

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

To confirm that the Azure AD Kerberos object has been created successfully, you can check for its presence in the Domain Controller Organizational Unit (OU) of your Active Directory. To do so:

1. Open the Active Directory Users and Computers console.
2. Navigate to the Domain Controllers OU.
3. Look for the AzureADKerberos computer object.

If the object is present, it indicates that the Azure AD Kerberos object has been created successfully. You can now proceed with configuring Windows Hello for Business in your environment.

To verify the configuration of the Azure AD Kerberos object, you can use the following PowerShell command:

 

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

This command will retrieve and display the details of the Azure AD Kerberos object. If the object is configured correctly, you should see its details displayed in the output.

Note: You may be prompted to authenticate again in order to view the details of the object.

By running this command, you can confirm that the Azure AD Kerberos object has been set up correctly and is ready for use in configuring Windows Hello for Business in your environment.

 

"To configure Windows Hello for Business on devices in a hybrid environment, you can use Group Policies. In this case, we will be using the Cloud Trust method, which requires the policy to be applied to computers rather than users.

To do this, follow these steps:

1. In the Group Policy Management tool, create a new policy, for example, WHfB_CTrust.
2. Edit the policy and navigate to:

• Policy > Administrative Templates > Windows Components > Windows Hello for Business

3. Enable the following settings:

• Use Windows Hello for Business
• Use Cloud trust for on-premise authentication
• Use a Hardware security device"

 

"To use Windows Hello for Business in a hybrid environment, you need to enable these three settings in your Group Policy:

• Use Windows Hello for Business
• Use Cloud trust for on-premise authentication
• Use a Hardware security device

Before rolling out the policy to all devices, it is recommended to first assign it to an Organizational Unit (OU) containing test computers. This will allow you to verify that the policy is working as expected before applying it to all devices.

To prevent users from being immediately prompted to set up Windows Hello for Business after signing in, you can enable the "Do not start Windows Hello provisioning after sign-in" option under the "Use Windows Hello for Business" setting. This will allow users to configure it at a time that is convenient for them."

 

To verify that the device is using Hybrid Cloud Trust and not Hybrid Key Trust, we can check the Event Viewer logs. In the Operational log under the 'Applications and Services Logs > Microsoft > Windows > Hello for Business' category, we should see an event indicating that the device has been configured and has obtained a Cloud TGT

 

 

Testing Time Now

Now that you have configured and assigned the policy to an OU containing test computers, it's time to test the implementation of Windows Hello for Business. To do this, follow these steps:

1. Ensure that the latest policies have been loaded on the client. You can force an update using the GPUpdate command or check the status using RSOP.
2. Sign in to one of the test computers and verify that the Windows Hello for Business setup process is triggered.

 

 

 

The next step will be the multifactor authentication (MFA) step, which is a required process

 

 

Set your Pin

 

 

All Set Now

 

3. Follow the prompts to set up Windows Hello for Business and ensure that it is functioning as expected.
4. Repeat these steps on all test computers to ensure that the policy is working correctly on all devices.

Once you have verified that the policy is working as intended on the test computers, you can roll it out to all devices in the organization."

Before configuring the PIN for Windows Hello for Business, the user must first complete an MFA request to authenticate their identity. After the MFA request is complete, you can proceed with configuring the PIN.

Note that it may take up to 30 minutes after configuring the sign-in method for Windows Hello for Business on a device for it to become active. This is because the Azure AD Connect tool needs to synchronize the necessary attributes first. To force a sync of Azure AD, run the following PowerShell command on the server where the Azure AD Connect client is installed:

Start-ADSyncSyncCycle -PolicyType Delta

To verify that the key for Windows Hello for Business has been synced back to your Active Directory, you can check the value of the msDS-KeyCredentialLink attribute in the user's account. If this attribute is present, it indicates that the key has been successfully synced.

To check the value of the msDS-KeyCredentialLink attribute, you can use a tool such as Active Directory Users and Computers or a script that queries the attribute on the user's account."

 

 

 

Summary

Deploying Windows Hello for Business with Cloud Trust is relatively easy compared to older methods. However, it's important to thoroughly test the implementation before rolling it out to your organization. Not only does Windows Hello for Business improve security, but it also makes logging in more convenient for users. This can help increase adoption within your organization.