Contents
This post will show you how to set up your environment to support AzureAD joined devices authenticating to your on-prem resources. When devices are setup as pure azure ad joined, and not hybrid joined, devices we need to handle authentication to your on-prem resources in a better way. Your on-prem resources does not in itself understand the authentication from these devices. It will also add support for using Windows Hello for Business/biometrics, FIDO security keys – which I also have written about before here, and passwordless options on the devices ,while still beeing able to authenticate with local resources.
In scenarios where another trust model is in place (key trust), we also need to migrate away from this – as this will be preferred if both are in place. Although the new Cloud hybrid trust is the recommended way of doing this.
This also brings you – and your users – one step closer to enabling your users to enjoy the passwordless experience in the future. Death to passwords.
I’m including some information from Microsoft here in the post with sources for your to read more.
About Cloud Kerberos trust deployment
Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in a cloud Kerberos trust scenario.
The goal of Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of passwordless security key sign-in to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments.
Windows Hello for Business cloud Kerberos trust uses Azure AD Kerberos, which enables a simpler deployment when compared to the key trust model:
- No need to deploy a public key infrastructure (PKI) or to change an existing PKI
- No need to synchronize public keys between Azure AD and Active Directory for users to access on-premises resources. There isn’t any delay between the user’s Windows Hello for Business provisioning, and being able to authenticate to Active Directory
- Passwordless security key sign-in can be deployed with minimal extra setup
Unsupported scenarios
The following scenarios aren’t supported using Windows Hello for Business cloud Kerberos trust:
- On-premises only deployments
- RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)
- Using cloud Kerberos trust for “Run as”
- Signing in with cloud Kerberos trust on a Hybrid Azure AD joined device without previously signing in with DC connectivity
Prepare your on-prem domain controller
To prepare for enabling the Cloud Kerberos trust functionality, we need to do a small job on the existing domain controllers. To to this, we follow the steps in the Microsoft article “Enable passwordless security key sign-in to on-premises resources by using Azure AD“.
The steps involved have som prerequisites, so make sure you are covered on that part before starting the job.
Microsoft also has a matrix here showing the minimum requirements for each deployment method for Windows Hello for Business.
Prerequisites
Before you begin the procedures in this article, your organization must complete the instructions in Enable passwordless security key sign-in to Windows 10 devices.
You must also meet the following system requirements:
- Devices must be running Windows 10 version 2004 or later.
- Your Windows Server domain controllers must run Windows Server 2016 or later and have patches installed for the following servers:
- Windows Server 2016
- Windows Server 2019
- AES256_HMAC_SHA1 must be enabled when Network security: Configure encryption types allowed for Kerberos policy is configured on domain controllers.
- Have the credentials required to complete the steps in the scenario:
- An Active Directory user who is a member of the Domain Admins group for a domain and a member of the Enterprise Admins group for a forest. Referred to as $domainCred.
- An Azure Active Directory user who is a member of the Global Administrators role. Referred to as $cloudCred.
If all pre-requisites are in place, you can configure the domain controller with the provided script in the “Enable passwordless security key sign-in to on-premises resources by using Azure AD” article.
Open a powershell with administrative permissions on the domain controller, and run the following:
# First, ensure TLS 1.2 for PowerShell gallery access. [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12 # Install the Azure AD Kerberos PowerShell Module. Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
This will install the needed powershell module for the next step.
For the next section, copy the commands from the article -depending on your needs – I am using the modern authentication option.
# 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 a UPN of an Azure Active Directory global administrator $userPrincipalName = "365globaladmin@somename.onmicrosoft.com" # Enter a domain administrator username and password. $domainCred = Get-Credential # Create the new Azure AD Kerberos Server object in Active Directory # and then publish it to Azure Active Directory. # Open an interactive sign-in prompt with given username to access the Azure AD. Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred
This will prompt you for credentials for the on-prem domain admin account, and then ask you to log in with the 365 global admin account.
After this command is run, you will find a new computer account in active directory. (read only domain controller)
Do not reset the computer account password etc for this object.
The on-prem setup is now complete, and we can jump over to the 365 configuration with Endpoint manager (intune).
Setup in Endpoint Manager
This section covers the setup involved on the Azure AD/Endpoint manager side.
Enable FIDO support in your tenant
To enable the use of Security keys, as mentioned in the pre-requisites, head over to your azure ad portal> click on security-> Authentication Methods->Policies->Click on the FIDO2 security key method, set it to enable, and target all users or a group of users.
You can also add some extra configuration for FIDO2 keys if you want to i.e restrict the type of security keys allowed.
Click save on the policy when you are done.
If you want, you can also configure the Microsoft Autenticator policy.
With this you can configure the authentication method to passwordless/push/any if you feel like it.
Check for current configuration for Windows Hello for Business
First we check the company wide settings on the windows enrollment side.
Next we check for any current Windows Hello configuration profiles already deployed in the environment.
If you find an exisiting policy, check what users/groups its targeting and take note – good for later.
Scroll further down to check the current settings that are configured for Windows Hello in the profile.
We are looking to see if the option “Certificate for on-premise resources” is set to enabled – when this is enabled, it will be preferred over cloud trust if both are configured, as mentioned by Microsoft here
If this is set to enabled, like this example, we need to migrate away from this, if it is not set you can skip to the next part. In this example this is enabled,and we want to ensure we don’t affect any existing setup.
To do this, we will create a new Windows Hello for Business policy with all the same options, but with the certificate option not enabled.
We target the new policy to the device group for the devices we will be enrolling to the cloud trust model. This new group is added as excluded on the existing Windows Hello policy – to ensure that these new device that are going to use the cloud trust does not get hit with the “old” policy with certificate trust enabled.
PS: If you do not want to do a limited test first, you could configure and deploy the new Windows Hello policy side-by-side, and then remove the existing policy – but it’s always good to stage the rollout, so you get to verify that nothing unexpected breaks – always prefer to do a test first.
Next we will need to create the new configuration profile to enable the cloud hybrid trust option.
Create a new configuration profile-> set platform to windows 10 and later, and profile type to settings catalog-> hit create.
Give the profile a name and a description->hit next.
In the next step click add settings-> search for cloud trust-> click on windows hello for business-> check the box for Use Cloud Trust For On Prem Auth-> then close the slide out menu.
Enable the Cloud trust option and click next
Configure scope tags if you use them, click next.
On the assignment page assign your group of devices/users to be targeted for the profile, click next, review everything on the last page, and click create to complete the profile.
Summing it up
You now have done the needed settings to enbable your devices with the cloud trust model. This means that you should be able to move away from the hybrid join* type for your devices, and insted moving to enrolling your devices directly as Azure AD Joined devices, and still getting access to on-prem resources, even if your users log on to the device with PIN/Bio/FIDO**.
*This will depend on the rest of your environment of course, so map the terrain first.
**For hybrid joined devices the first login must be done with line of sight to the domain controllers
Some information to check status of provisioning on a device kan be found by running the “dsregcmd /status” command on a device.
Sources
Enable passwordless security key sign-in to on-premises resources by using Azure AD
Consultant manager & SME @ iteam, localized in Kristiansund, Norway.
Focused on EUC, security, mobility, virtualization, management and a modern workplace. Highly specialized around RDS/Citrix/EUC/Mobility.
