A couple of months ago I had to setup and enable MFA in a hybrid environment of Active Directory on-prem with MS365 and Entra ID (formely named Azure AD). This is my personnal experience on how I was able to accomplish all of this. It was quite a journey because of the complexity and the upgrade path I had to take in order to make all of this works seamlessly.

Since this topic is big – or a journey unto itself. I’ve decided to create a 3 parts serie on my blog about this. The first part is about checking and setting up the prerequirements of the clients and servers within the internal AD Domain. The second part will be about connecting the internal AD and establishing the communication between the AD domain and the external env. i.e. EntraID. The last part will be pushing the configuration using GPO to the client’s device in order to have the devices joined in hybrid mode and enabling the Windows Hello for Business. But before getting into the technical details of this, let me put some background on what needs to be supported or required.

I want MFA enforced for everyone to work witouth a hitch but also at the same time, I want to achieve the best experience for logging to our business laptops/desktops without having to enter a complexe password every time, even tough, complexe passwords are enforced to all of the users of the system. For this, we are using business devices with multiple biometrics reader already integrated in the laptops, like finger print reader, facial recognition webcam or PIN (not to be confused with convenience PIN, more on that topic later).

Here comes Windows Hello for Business into the picture, or WHfB for the acronym. This will make all login experience much smoother for everyone. There is nothing new here, I’m just building on top of what others did before me. Also the documentation from Microsoft is the best source for all of this. It’s just that there is lot of reading involved. Buckle up your seat belt, because this is going to be a long ride.

Client Side Requirements

All laptops must be running at least Windows 10 or 11 with TPM version 1.2 for the minimum but I went with version 2.0 instead in my case. TPM is fundemental to make this works because it’s the chipset on the motherboard of the computer that will store the encryption/cryptographic key for WHfB. Some usefull commands to check what is the TPM version running on your computer:

tpm.msc

Make sure that it’s enabled and confirm the version you have on the computer (on all the computers that will be affected):

For the CLI command, you can use this in a cmd elevated as an admin:

tpmtool getdeviceinformation

That was the easy part!

Server Side Requirements

AD Schema Version

My initial AD forest and domain level is Windows Server 2012 R2. I had to put in place a domain controller running version 2016 at the minimum, I went with version 2022 instead, but I did not had to raise the domain or forest level yet. Why is that? It’s because the requirement is that your domain and forest level must be at version 2008 R2 minimum but the schema version has to be at least 2016 – version 87. So after I promoted my new DC Windows Server 2022, I was able to update the schema version of the AD. Just add your domain admin account for the operation as a member of the enterprise admins group. Be sure to remove yourself of the group membership as soon as you’re finished. You know, for security best practice’s… Here a fast way to check your AD schema version using powershell:

Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion.

Internal CA

The hard part now… We will also need an internal certificate authority for the AD (or Root CA) because we will be deploying a new KDC certificate (Kerberos Domain Controller) to all of the DC of the internal AD domain. This could be one of the biggest step if you don’t already have one internal CA. You are basically aiming to setup a “Public Key Infrastructure” or PKI with proper AIA configured and CRL or OSCP. This is beyond the scope of this article. I cannot stress this enough, you gotta make sure that your PKI setup is healthy and in good working condition before going further. I could write a post on this topic in the future, but honestly there are so many good tutorials that exist already on this topic.

Obligatory warning from here: We will create a new certificate template that will be pushed on all the DC of the internal AD domain, if you don’t know your environment or understand what is going on here, do not do this! Hire a professionnal, test everything in a lab, document your configuration, etc. This will impact the communication with all of your DC.

From the Certificate Authority Console, manage your certificates templates and duplicate the Kerberos Authentication template to use as a base.

From there, name your new template, mine is DC Kerberos Authentication. There are a couple of things you will need to tweak and check on this new template. Here’s the gist of it; From the compatibility tab, choose your level of compatibility of the CA authority and for all of your end client member of your AD domain.

On the tab for Superseed Templates, make sure that this new template will superseed the old template for KDC auth. like so:

• Domain Controller
• Domain Controller Authentication
• Kerberos Authentication

Go to the tab for the extensions, there is nothing that should be changed here, but still confirm that Application policy is populated with the following:

• KDC Authentication
• Smart Card Logon
• Server Authentication
• Client Authentication

Next and last tab to change the configuration is the most important one! Go to Cryptography and check or change the following settings:

• Provider Category: Key Storage Provider
• Algorithm name: RSA
• Minimum key size: 2048
• Requests can use any provider available on the subject’s computer
• Request hash: SHA256

That’s it for this new certificate. Save it and publish it on your internal CA. Using GPO you can deploy automatically this new certificate to all your DC. Double check your deployment with auto-enrollment for the GPO, make sure that all your DC get this new certificate and all your communication and replication between the DC is still healthy before going further.

We are done for part 1.
Part 2 is now available.
Part 3 is here.