IMPORTANT NOTE: This blog post is referring to the Windows Hello for Business Hybrid key-trust model. Since 16-02-2022 a new Windows Hello for Business Hybrid deployment model has been made available called cloud-trust. If you are using the latest Windows 10 / 11 builds (21H2) I would strongly recommend you to read this new blog to make use this new, simplified and improved Windows Hello for Business Hybrid cloud-trust model!

As described in my previous blog, we have implemented Windows Hello for Business for Azure AD Joined devices without making sure you can use those same credentials to authenticate against on-premises Active Directory and access on-premise resources.

This blog will focus on enabling Windows Hello for Business hybrid based on the key-trust model for both Hybrid Azure AD Joined devices as Azure AD joined devices. If you haven’t read my previous blog about enabling Windows Hello for Business I would strongly urge you to read it first to make sure you’ve completed all requirements.

NOTE: In case you’ve ignored my advice to read my previous blog first, please know we don’t implement the certificate-trust model. This is due to the fact that it requires your domains to be federated with the Azure AD and this breaks the password-less flow as described in this previous blog.

Requirements check-list:

• Certificate Authority based on Server 2012 or higher;
• Certificate Revocation List internally accessible;
• New KDC certificate deployed to Domain Controllers;
• Root & Intermediate certificates deployed to clients;
• Windows Server 2008 R2 domain and forest functional level;
• Windows Server 2016 domain controller, at least one on each site;
• Primary Domain Controller role hosted on a Server 2016 Domain Controller;
• Synchronized Identities via Azure AD Connect;
• Windows 10 Physical or Virtual Machine with TPM;

---

General required technical steps for WHfB Hybrid.

For both the Azure AD Joined and Hybrid Azure AD Joined devices there is some general steps we need to perform, these are listed down in this chapter and are a requirement to complete both of the scenario’s.

STEP 1: Make sure your Certificate Authority has a healthy CRL.

The first step is to make sure your Certificate Authority has a healthy CRL (Certificate Revocation List), even if we do use the key-trust model which doesn’t require certificates, your domain controllers does. This to make sure that your WHfB credentials (passport authentication) are accepted on the Domain Controllers and can be verified to issue Kerberos tickets.

The first step is to pick a DNS name for the CRL if you don’t have one yet, I would recommend to keep things easy and to just use crl.companyname.com. For this create a DNS record pointing to the IIS webserver which will host the CRL files from both the Root and Intermediate CA, in my case I used crl.identity-man.eu. This record must at least be available on the internal DNS for all clients, but can also be made available to external clients (not required for WHfB Hybrid).

NOTE: Don’t be shocked if you don’t have an intermediate CA. It means your CA environment isn’t based on a best practice, especially not from a security perspective. It however still works perfectly with Windows Hello for Business Hybrid, you just have to ignore the intermediate steps within this blog :-).

Once you’ve picked your DNS name for the CRL, open the Certificate Authority MMC and go to the properties of the Root CA, in there go to the Extension tab and make sure that there is a HTTP URL available pointing to the DNS name of the CRL (which in case you didn’t had one you just created it).

The CRL is in this example hosted on a IIS server, and again preferably this would be same server as your intermediate CA. Make sure that when publishing the CRL as URL the ‘Include in CRLs. Clients use this to find Delta CRL Locations’ and ‘Include in the CDP extension of issued certificates’ are both checked.

NOTE: Publishing this HTTP URL in the CRL extension will only put this data on the certificate, it won’t copy over the actual CRL file(s), for this I’ve created a script which copies all the data from ‘C:\Windows\System32\CertSrv\CertEnroll’ to the intermediate CA servers virtual directory which is hosted via IIS.

Now if you have changed the URL for the CRL the intermediate certificate must be re-issued again to get this new URL. In this blog I assume you’ve done this before, if not stop with whatever you’re doing right now because renewing an intermediate certificate can definitely have some implications on your production environment.

Once the intermediate certificate is renewed you can open the certificate and check the details for the ‘CRL Distribution Points’, in there you will find the URL you just have configured.

Now please copy and paste this URL into a browser, a successful download means everything is configured correctly for the Root CA, if you got an error you unfortunately have done something wrong, go through the steps again and verify if everything is configured correctly and make sure the CRL is available in the IIS Virtual Directory which is selected.

Now we have configured the Root CA, we need to walk through the same steps on the Intermediate CA. Again open the Certificate Authority MMC and open the Properties of the Intermediate CA and select the ‘Extensions’ tab. In here again make sure that the CRL is published to the CRL URL. Again make sure that when publishing the CRL as URL the ‘Include in CRLs. Clients use this to find Delta CRL Locations’ and ‘Include in the CDP extension of issued certificates’ are both checked.

Now if you have changed the URL for the CRL on the intermediate CA all the issued certificates from the intermediate CA need to be re-issued to get this new CRL. You can easily go to the issued certificates screen, check if certificates are renewed and if they contain the new or changed CRL (as shown below).

Now please copy and paste this URL into a browser, a successful download means everything is configured correctly for the Intermediate CA, if you got an error you unfortunately have done something wrong, go through the steps again and verify if everything is configured correctly.

NOTE: Same as for the Root CA Publishing this HTTP URL in the CRL extension on the Intermediate CA will only put this data on the certificate, it won’t copy over the actual CRL file(s). If you want this to be an automated process you need to configure an extra location within the Extension for the CRL on the Intermediate CA. Like the one shown below.

Now you’ve executed the above steps successful this means the whole CRL trust from the Root and Intermediate CA can be verified. You can easily verify this from the pkiview.msc MMC.

If you open the pkiview.msc MMC on the Intermediate CA server you are able to check the health of the whole CA environment. As you can see below the Root CA has a valid CRL (status ‘OK’).

If you open the Intermediate CA you will see again status ‘OK’. (For two CRL’s and two Delta CRL’s published via both HTTP and LDAP).

The CA is now ready to be used for WHfB Hybrid.

NOTE: Please make sure that all AD Joined clients get these new Root and Intermediate certificates, this can be achieved via a Group Policy.

STEP 2: Make sure AD Sites and Services and Server 2016 Domain Controller(s) are ready for WHfB Hybrid.

As the CA is now ready let’s make sure that the domain is also ready. As WHfB is based on passport-authentication at least server 2016 domain controllers are required for each Active Directory site within AD Sites and Services.

Let’s first verify what kind of domain controllers you do have in your environment per Site. You can easily do this via the OU ‘Domain Controllers’ (assuming all your domain controllers are in there of course 😉 ). In there you can easily see to which site each domain controller belongs an what version it is.

Now important to know is that each site needs at least one Server 2016 Domain Controller, and for the people who didn’t know… A site within AD Sites and Services without Domain Controllers belonging to the site does literally nothing. Now if you think: ‘Guilty’, no worries, you can just delete the site or make sure no subnets belong to that specific site to make it inactive.

Now another thing to check within the Active Directory is the forest and domain functional level, please make sure that those are 2008 R2 or higher. If this isn’t the case it’s time for some maintenance as 2008 is already end-of-life :-).

STEP 3: Configure Azure AD Connect Service Account permissions.

Now this is all configured correctly and each site has an active Server 2016 Domain Controller there is only one step left to configure. This is making sure that the Azure AD Connect service account has the appropriate permissions to write-back the public key configure for Windows Hello for Business within the Azure AD back to the on-premises AD.

For this to happen the service account needs to be a member of the Key Admins group within Active Directory (or when using root and child domains the Enterprise Key Admins group).

If this group doesn’t exist, this is only for one single reason. The PDC (Primary Domain Controller) role of the domain isn’t hosted on a Server 2016 domain controller. (If you have multiple domains, this is something you have to repeat for each domain.

To make this group available ‘right click’ the domain for which you want to change the PDC role and first hit ‘Change Domain Controller…’ and select the 2016 domain controller which you want to use as PDC. Once done again ‘right click’ the domain and now select ‘Operations Masters…’.

Within the Operations Masters screen hit the second tab called PDC and hit ‘Change’, this will move the PDC role to the Server 2016 Domain Controller you just selected, the Key Admins (or Enterprise Key Admins group) is now available and ready for use.

We are now ready to start the Hybrid Azure AD Join experience.

---

Required technical steps for WHfB Hybrid on Hybrid Azure AD Joined devices.

Now imagine you have a big on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory like Windows Hello for Business, you can implement Hybrid Azure AD joined devices. These devices, are devices that are joined to your on-premises Active Directory and registered with your Azure Active Directory. AKA Hybrid Azure AD Joined devices.

STEP 1: Make the necessary changes within Azure AD Connect

To get your on-premises AD joined devices Hybrid Azure AD Joined, the first step we need to take is to update the Azure AD Connect configuration. To do this, go to the server where Azure AD Connect is running on and open the Azure Active Directory Connect wizard.

Once the wizard is open please click on ‘Configure Device Options’ and hit ‘Next’.

As you can see you can do two things beneath this option, the first one is the Hybrid Azure AD Join and the second one is device writeback. Please know that we only need Hybrid Azure AD Join, we do not need the device writeback option within a key-trust scenario. Now again please hit ‘Next’.

Select ‘Configure Hybrid Azure AD Join’ and select ‘Next’.

Select ‘Windows 10 or later domain-joined devices’ and select ‘Next’. (Reason why we only do Windows 10 is because WHfB is only available on Windows 10 :-)).

Now verify the forest of your domain joined clients is visible in the overview and hit ‘Add’.

Once prompted enter the account details of an account which is a member of the ‘Enterprise Admins’ group within the Active Directory. Once done select ‘OK’.

Verify all settings are configured and hit ‘Next’.

Now the wizard is ready to configure the connectors, please hit ‘Configure’ and hit ‘Exit’ once the wizard has completed successfully.

As for Hybrid Azure AD Joined devices the source computer objects within Active Directory also need to be synced, please make sure that the OU containing these computers is synchronized (for big production environments I do recommend to start small for testing purposes and extend later on, just to be sure).

Another setting which is strongly advised to be turned on is ‘Password Hash Synchronization’ with ‘Enable Single sign-on’. This will bring a better end user experience to Hybrid Azure AD Joined devices.

STEP 2: Make the necessary changes within the Group Policies

Especially for the Hybrid Azure AD Joined devices we have created a separate group policy for the following computer settings:

• Register domain joined computers as devices – Enabled.
  (To make sure AD Joined devices are going to register in Azure AD).
• Disable MDM Enrollment – Enabled.
  (To make sure AD Joined devices won’t be managed with Intune).

Now next to a computer policy another user policy is required to configure the intranet sites within the IE settings. Within this policy we specify that the following URL’s belong to the intranet zone to provide the user with a seamless logon experience to the Azure AD and to prevent certificate prompts:

• https://device.login.microsoftonline.com
  (Required for Hybrid Azure AD Joined windows 10 devices).
• https://autologon.microsoftazuread-sso.com
  (Required with the enable single sign-on checkbox checked within Azure AD Connect).

STEP 3: Make sure that devices can be joined and monitor the process.

Now we are ready to join devices, if you’ve followed my previous blog post where we configured the Windows Hello for Business settings we also allowed Azure AD Joined devices. As we allowed Azure AD Joined devices we also allowed device registrations for all users (as you can see below within the ‘Azure Active Directory’ blade on the ‘Device Settings’ tab of the Azure AD Tenant.

Now when all things are configured correctly, with the next synchronization within Azure AD Connect, you will see in the export to the Azure AD (<yourtenantname>.onmicrosoft.com) that one device (which resides beneath the Computers OU which is checked for synchronization) is synchronized to the Azure AD.

If you now logon to this specific device with an account which is available within the Azure AD, the device will be registered and therefore Hybrid Azure AD Joined within your tenant (in some cases your machine needs a gpupdate /force).

This can be verified within a command prompt by running the command ‘dsregcmd /status’. This will show that the device is Azure AD Joined and Domain Joined. Together this means Hybrid Azure AD Joined.

If you now go to the ‘Azure Active Directory’ blade and hit ‘Devices’, you will see beneath ‘All Devices’ that there is one (or more) Windows 10 devices with a join type ‘Hybrid Azure AD Join’. This means congratulations, you’ve successfully walked through the above steps :-). If this isn’t the case, you need to start troubleshooting because as long as the devices aren’t Hybrid Azure AD Joined, the Windows Hello for Business policy won’t be received. You can troubleshoot this via the “dsregcmd /status /debug” command in a command prompt, more details about troubleshooting this can be found here.

STEP 4: Enable Windows Hello for Business for Hybrid Azure AD Joined devices.

Now to make sure that Windows Hello for Business is enabled on these Hybrid Azure AD Joined machines, we go back to the user group policy we just created, and in here we enable the ‘Use Windows Hello for Business’ setting. (Please make sure that ‘Do Not start Windows Hello Provisioning after sign-in’ is disabled unless you want this to happen).

NOTE: This can also be done via Microsoft Endpoint Manager (aka Intune), so if you’re going to manage devices via Microsoft Endpoint Manager (which I assume you don’t in this part) you can ignore this step. This because Intune will automatically let computers retrieve this policy. If you aren’t using Microsoft Endpoint Manager yet as a management tool but you do have the licenses I would recommend you to start exploring your options as it’s a modern management tool compared to old fashioned group policies :-).

Now logon to the Hybrid Azure AD Joined machine, and if you have enabled this account for MFA the Windows Hello for Business policy will be received (which we have configured in the previous blog post). Make sure to het Set up PIN (as I’m working on a virtual machine).

Please configure your PIN, as also described in my previous blog you can see that the PIN policies from the Azure AD are honored.

Now it takes 30 minutes to synchronize the public key from this Windows Hello for Business configuration back from the Azure Active Directory to the on-premises Active Directory. The attribute which is used in this case is the msDS-KeyCredentialLink (which is included in the schema if you have Server 2016 Domain Controllers, and you do otherwise this isn’t going to work).

NOTE: If you don’t see this value within the export back to the on-premises AD this means that Azure AD Connect doesn’t know there is a new schema applied in the meantime to the Active Directory. To make sure this is applied op the Azure AD Connect Wizard and hit the ‘Refresh Directory Schema’ option, once done you will see this value being synchronized.

STEP 5: Verify Windows Hello for Business Hybrid Works

If you now logon to the device with your PIN, Face or any other Windows Hello for Business authentication you can access your file shares seamlessly without any kind of prompt on Hybrid Azure AD Joined devices:-).

---

Required technical steps for WHfB Hybrid on Azure AD Joined devices.

In case you don’t like doing a Hybrid Azure AD Join and want to go Azure AD Joined straight away (which I would recommend you to do) there are some other steps you need to take. This as there is no relation between the on-premises AD and Azure AD besides the user account which you logon to your Azure AD Joined device.

STEP 1: Deploy a new Domain Controller Certificate Template to the Domain Controllers.

The first step which we need to take is to prepare the Domain Controllers with a certificate from our CA which supports Kerberos Authentication. This is due to the fact that everything you do with Windows Hello for Business on an Azure AD Joined device to your on-premises Active Directory requires Kerberos authentication.

Therefore go to your Issuing CA, right click on ‘Certificate Templates’ and hit ‘Manage’. From the ‘Certificate Templates Console’ search for the ‘Kerberos Authentication’ certificate, right click on this certificate and hit ‘Duplicate Template’.

Now within the new template wizard based on the Kerberos Authentication certificate change the following:

• On the compatibility tab
  • Change the Certificate Authority to the value hosting your certificate authority (minimal must be 2012). In my lab environment the whole CA is based on Server 2016, therefore 2016 is selected.
  • Change the Certificate Recipient to the minimum version of Domain Controllers OS you have running. So if you’re environment is still running 2012 R2 domain controllers this should be 2012 R2. In my lab environment all domain controller are running 2016 or higher, therfore Windows 10 / Windows Server 2016 is selected.

• On the General tab definea Template display name, I’ve used ‘Domain Controller (Kerberos Authentication)’. Please note that you never use spaces in the template name as that could lead to weird issues.

• On the Cryptography tab make sure that the ‘Key Storage Provider’ and ‘RSA’ is selected. Next to the above the ‘key size’ should be set to 2048 and the ‘request hash’ setting should be set to SHA256.

• On the superseded Templates make sure to include all old domain controller templates:
  • Domain Controller
  • Domain Controller Authentication
  • Kerberos Authentication
  • Depending on what you did yourself you maybe need to add more.

• Verify within the ‘Extension’ tab the ‘Application Policies’, this should list KDC Authentication, if not please go back to step 1 and verify what you did wrong (and double check you’re using server 2012 as an OS for your CA).

• Within the ‘Subject Name’ tab make sure that the ‘Subject name format’  is set to ‘None’ and that ‘DNS Name’ is selected as the only option.

Once done hit ‘Apply’ to create the certificate template.

As you can see within the overview the certificate template has been created, now it’s time to deploy the certificate to the domain controllers.

To do this ‘right click’ the ‘certificate templates’ option on your issuing CA and select ‘New’ and click on ‘Certificate Template to Issue’.

Select the new ‘Domain Controller (Kerberos Authentication)’ certificate and hit ‘OK’.

As you now can see the ‘Domain Controller (Kerberos Authentication)’ certificate is scheduled to be issued. This is still next to other Domain Controller certificates, which are set to be superseded by the ‘Domain Controller (Kerberos Authentication)’ certificate. So to clean up the MMC console I would recommend you to disable these certificate templates from being issued.

Now to make sure that your Domain Controllers get the updates automatically (which is super helpful because it will also renew certificates which are about to expiry). Go to the Group Policy Management Console and either create a new policy or edit the ‘Default Domain Controller Policy’. In the Group Policy make sure that the ‘Automatic Certificate management’ setting is set to ‘Enabled’ including the two options beneath this setting.

Now login to all your domain controllers and run a ‘gpupdate /force’ (or reboot the machines, but a gpupdate /force probably is faster 🙂 ).

Once done open the MMC Certificates snap-in and check the personal certificates beneath the computer account. In case you have done the above exactly as the described you should have the ‘Domain Controller (Kerberos Authentication)’ applied to the domain controllers, you can see this by looking at the ‘Certificate Template’ column within with the MMC.

The Certificate authority and your domain controllers are now configured correctly for Windows Hello for Business Hybrid for Azure AD Joined devices.

STEP 2: Deploy root and intermediate CA certificates to Azure AD Joined devices (Intune required).

Now we need to prepare our settings for Azure AD Joined devices… in this case I’m going to assume you manage devices via Intune, but if you don’t… Don’t worry this isn’t required, the only thing where we need Intune for in this case is to deploy the root and intermediate certificate to Azure AD Joined devices so it’s not a hard requirement but recommend by me though :-).

To make sure you can manage Azure AD Joined Devices logon to the Azure Portal and go to the ‘Azure Active Directory’ blade. Within the ‘Azure Active Directory’ blade select ‘Mobility (MDM and MAM)’. The screen below will open, in here either set the MDM user scope to a group or set it to ‘All’ like I did. This will make sure that when devices are joined to the Azure AD they are being managed with Intune. Please don’t change the URL’s configure over here and leave the MAM settings as is as that’s only required for Windows Information Protection.

NOTE: If set to a specific group this only counts for that group so that would be good for testing and piloting this feature or if you want to limit this to a specific group.

Now when you’ve done this it’s time to make a small bit of Intune Configuration. First let’s double check the Enrollment Restrictions, for this go to the Intune blade in the Azure Portal and from there select ‘Device Enrollment’. Within the Device Enrollment settings select ‘Enrollment Restrictions’.

In here make sure that the ‘Default Device Type’ Restriction which is configured for all users at least has Windows (MDM) personally enabled, this will allow Windows 10 to managed for devices joined to the Azure AD which aren’t known within Windows Autopilot.

NOTE 1: Please also verify the Device Limit restriction and make sure that it’s set to an acceptable number.

NOTE 2: If you’ve configured separate settings within this pane for specific user groups also verify those as your users is maybe matching other settings that the default for ‘All Users’.

Now the enrollment restrictions are configured correctly, let’s go back to Microsoft Endpoint Manager and make sure to configure two ‘Device Configuration Profiles’ for the Root and Intermediate certificates.

For this click on the ‘Create Profile’ button and give the Profile a ‘Name’. Select as the Platform ‘Windows 10 and later’ and as Profile Type ‘Trusted Certificate’. On the right side of the screen ‘browse to the root certificate and select the certificate’ and make sure that the destination store is set to ‘Computer certificate store – Root’. Once done hit ‘Create’. Now make sure the profile is assigned to a user group or to all users if you want to apply this for all users working on Windows 10 and later.

NOTE: After creating this policy the platform changes to Windows 8.1 and later, which is a bug within the Interface.

For the intermediate take exactly the same steps as above, but now select the intermediate (Issuing) certificate and make sure that the destination store is set to ‘Computer certificate store – Intermediate’. Once done again hit ‘Create’ and again make sure the profile is assigned to a user group or to all users like you did also for the root certificate.

Now you’re ready to Azure AD Join a device. In case you’ve followed my previous blog post you need to redo those steps again to make sure that the device is managed via Intune to get the Root and Intermediate certificates (as those devices weren’t managed via Intune).

STEP 3: Azure AD Join a device and enable Windows Hello for Business.

As describe above we are redoing an Azure AD Join by resetting the Windows 10 device to the factory defaults.

NOTE: if you want to Azure AD Join existing devices please read my previous blog post.

Now during the Out of Box Experience (OOBE) within Windows 10 we choose for the option ‘Set up for an organization’ and hit ‘Next’.

Now login with your business credentials, this automatically joins a device to the Azure AD.

After all the OOBE Screens you will be prompted for a WHfB enrollment (for which we have defined the settings in the previous blog post). Please hit ‘Set up PIN’ (as in this example this is a virtual machine with a TPM, this is my only option).

Now as the enrollment of Windows Hello for Business requires Multi-factor authentication (which we enabled in the first blog of this series), I’m prompted for verification with my Authenticator App.

NOTE: some people already asked me why this screen isn’t password-less. That’s due to the fact that password-less isn’t multi-factor authentication. Password-less is password-less authentication so there is a difference between them (but on the other hand the two also overlap).

On the next screen I’m asked for my PIN. When configuring Windows Hello for Business I always need to set a PIN besides my Fingerprint and Face recognition. Sometimes your fingerprint or face isn’t recognized in that situation the PIN functions as a fall back. As you can see the PIN requirements are matching the settings configured earlier within the tenant. Once you have typed in your PIN please hit ‘OK’.

Once the PIN is configured you can see everything is set correctly, please hit ‘OK’ to finish the Windows Hello for Business enrollment.

Now as you can see within the ‘Azure Active Directory’ my device is Hybrid Azure AD Joined and managed with Intune.

I can also find my device within Intune:

After a successful logon I can also see that my Root and Intermediate certificates are received on the Azure AD Joined device.

Root CA:

Intermediate CA:

Now the last step in this process is to wait for the public key of Windows Hello for Business for this particular end user & device to be written back to the Active Directory via Azure AD Connect. In normal circumstances this could take up to a maximum of 30 minutes. The attribute which is used in this case in the on-premises Active Directory to writeback this public key is the msDS-KeyCredentialLink (which is included in the schema if you have Server 2016 Domain Controllers, which you should have otherwise this isn’t going to work).

We are now ready to use Windows Hello for Business in a hybrid environment for Azure AD Joined devices!

STEP 4: Verify Windows Hello for Business Hybrid Works

If you now logon to the Azure AD Joined device with your PIN, Face or any other Windows Hello for Business authentication you can access your file shares seamlessly without any kind of prompt on Azure AD Joined devices :-). This way you can benefit from all the features cloud has to offer but fully work hybrid.

In this case you can also see that you’ve created a Kerberos ticket by executing the command ‘klist’ in a command prompt. In here you would see Kerberos tickets from the domain which you wouldn’t had if you had a misconfigured Windows Hello for Business environment on Azure AD Joined devices (or if your public key wasn’t yet written back to the Active Directory).

NOTE: Please note that connecting via RDP isn’t support or even working, this is still under investigation as described on this docs page of Microsoft.

---

Tips & Tricks:

As the environment which I’ve used is my blog is a greenfield environment it’s quite easy to describe and build a successful WHfB Hybrid environment. In practice I’ve seen several misconfigurations which resulted in a non-working Windows Hello for Business Hybrid environment. In some cases it even brought my some headaches so let me at least save you from them and explain the tips & tricks below to you 🙂 :

Verify if ‘old’ domain controller certificates are removed from the domain controllers:

In any normal circumstance superseding the old domain controller certificates with the new ‘Domain Controller (Kerberos Authentication)’ certificate should also remove old domain controller certificates on the domain controllers. In practice we aren’t always seeing this behavior (unfortunately). Therefore check if the old domain controllers certificates are removed and if not delete them via the MMC Certificates snap-in.

Verify Samaccountname value in Azure AD:

I hear you thinking, what is the samaccountname value still synchronized to the Azure AD? Yes it is, it however is called ‘Onpremissessamaccountname’ and can be explored via the Graph API. Please make sure that this value is the same as the samaccountname value in Active Directory.

To check this value in the Graph API run the following command:

https://graph.microsoft.com/v1.0/users/johny.bravo@identity-man.eu?$select=onPremisesSamAccountName

The output should be similar to the screen below:

And as you can see this value is the same as in the Active Directory:

And a ‘whoami’ on the Windows 10 box will tell me the same.

If this is different then you did something unsupported :-)… please check the synchronization rules in Azure AD Connect and make sure these are configured to the defaults… If you never have done something with the synchronization rules editor before, please ask some professional help because this defines everything which is synchronized to the Azure AD. One mistake can break your whole configuration and has immediate user impact.

Verify DNS Names on Domain Controller certificate:

Another thing which is important is to verify if the domain name with and without FQDN is available on the certificate including the name of the domain controller itself. If this isn’t the case there is something wrong with either the certificate template or the issued certificate. Please check both and deploy a new certificate to the domain controller(s) experiencing this issue.

Verify if the CRL isn’t expired or unreachable.

If the CRL is expired or not reachable all Azure AD Joined clients which are using Windows Hello for Business to logon to a file share as example, will have authentication issues. Please make sure the CRL is reachable and and not expired.

For the Root CA I advise to use a CRL lifetime of 6 months, for the intermediate a week including Delta CRL’s should be enough.

Verify if your subnet belongs to a site within AD Sites and Services where a Server 2016 Domain Controller is available.

It’s important to make sure your clients belongs to a specific site within Active Directory Sites and Services which has a Server 2016 Domain Controller available. You can do this by specifying a subnet within Active Directory sites and services.

First check the IP range which you’re using on your machine, in this case this is 10.31.96.0/24.

Please define this subnet within AD Sites and Services and make sure the subnet belongs to a site containing a Server 2016 Domain Controller.

NOTE: if you have more sites and not all sites have Server 2016 domain controllers this becomes extremely important. If you just have one site the above isn’t required.

Verify if the correct root and intermediate certificates are available on the end user machine

If you have changed your CA configuration you need to update your clients as well with this new root and intermediate certificate. Please remember you need to do this in Active Directory for Hybrid Azure AD Joined machines and within Intune for Azure AD Joined machines.

In the next two blogs I will continue explaining how to implement the password-less options from a technical and user point of view. When they are available the links below will become active:

• Introduction to a password-less era
• Password-less 1 of 5: Going password-less with phone sign-in
• Password-less 2 of 5: Going password-less with Windows Hello for Business
• Password-less 3 of 5: Going password-less with Windows Hello for Business Hybrid
• Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 1
• Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 2
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 1
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 2
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 3
• Password-less continued: Upgrading your password-less experience with Windows Hello for Business Hybrid cloud-trust.
• Password-less continued: Using the Passwordless Phone Sign-in experience for multiple accounts on iOS!
• Password-less continued: Using a Temporary Access Pass for Bootstrapping your Passwordless Journey