Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 1

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. In this Trilogy you can expect to learn the what, the how and the wow!

Looking for other parts?
Part 2 – Part 3

The story so far

Windows Hello for Business Cloud Kerberos Trust – Every silver lining begins with a journey through pain, non optimal circumstance and wisdom gained through grit and determination. The trust model story has never been simple..

In this 3-part mini series, we will talk about concepts, strategies, configurations and pain points that we commonly come across when configuring Windows Hello for Business and why Cloud Kerberos Trust is the future.

What is Windows Hello for Business?

We won’t spend too much time peeling apart what Windows Hello for Business (WHfB) is but let’s remind ourselves of some key points.

• WHfB is a password-less authentication mechanism. Think of it as a type of user credential which is uniquely tied to a device – secured with a PIN or biometric
• WHfB is not the same same as Windows Hello. Windows Hello “convenience PIN” is targeted for the home market and is, essentially, like a password vault. A PIN or biometric is used to reveal the password(s) in that vault.
• WHfB key trust uses an asymmetric key pair, a password is never hashed and sent across “the wire” which is what makes it particularly secure. The private key is secured, normally, using the Trusted Platform Module (TPM). The private key never leaves the device and is unique for every device. An alternative to WHfB key trust is WHfB certificate-based authentication.

Why Windows Hello for Business?

Passwords are weak. Full stop. In a world where Identity theft is on the rise and password lists can be purchased from the dark web for the price of a McDonalds coffee we need to do more to secure the identity of our workforce. Passwords are transmitted over the wire and are susceptible to many man in the middle and eaves dropping practices.

This leads to the question…

Why does WHfB address the weak password conundrum?

WHfB is considered a “Strong” authentication type. The Biometric and PIN are unique to a user on a specific device where as passwords can normally be used to validate a user from any device.

WHfB differs because the “Password” or “Private Key” never leaves the device. For WHfB key trust, a cryptographic key pair is bound to the TPM or in Software (less secure). WHfB policy dictates where the key is generated. The Identity Provider (IDP) has the public portion of the key that is mapped to the user account during the registration process. Even when a token is generated by the Identity Provider (IDP) it is bound to that specific device.

Unlike some Multi-Factor (MFA) methods, WHfB is considered “Phish Resistant”. This means that strong authentication cannot be phished, unlike “One Time Passwords” and “Push Notifications”.

When we talk about WHfB, many orgs think about key trust but certificate trust is also another valid way to ensure a strong logon to a device. Certificate trust is used by orgs leveraging ADFS.

WHfB is great, and a much stronger alternative to passwords, but there are still scenarios where some might consider the PIN is weak compared with a password. If you deploy a WHfB policy and require a 4 digit PIN, will most users use the day and month of their birthday for the PIN – or perhaps a phone number? This information can be easily phished through social engineering.

Also consider if a laptop is stolen on a train and the PIN is shoulder surfed – an attacker has access to the device*

We are not saying don’t use WHfB because of these scenarios but you should be aware of them when deciding on your WHfB PIN policy and Conditional Access design.

* TPM anti-hammering can prevent an attacker guessing the PIN incorrectly too many times.

Key Trust

Many organizations have already deployed WHfB key trust. If you are still requiring your devices to access on-premise resources, the single biggest pitfall is during initial deployment.

A synced user identity is required in a hybrid environment. Image you have a shiny, internet born device, enrolled in Azure AD and managed by Intune but you want the user to still access resources within your domain. We spoke about this scenario and the requirements in our SSO mega series.

SSO to domain resources from Azure AD Joined Devices – The MEGA Series – Part 1 – Overview – MSEndpointMgr

During the provisioning of WHfB, there is a delay while the Next Generation Credential (NGC) is written back to the Active Directory User object – specifically the msDS-KeyCredentialLink attribute.

Below is a high level flow for a typical first logon in a hybrid scenario when the user is prompted to setup WHfB.

1. User signs in and is prompted to setup WHfB
2. PIN is set and Biometric (if applicable) is chosen
3. NGC written to Azure AD user object
4. ADConnect, by default every 30m, synchronizers the NGC to the Active Directory User object.

Until that AD Sync happens, the user cannot authenticate to on-premise resources with WHfB. This results in a poor first-run experience where users would setup WHfB and then be told by IT they need to sign back in with their password or “go and have some pie and wait an hour before trying again”.

Key Trust Pain Points

• Requires a Certificate Authority and a valid trust chain from the device to a 2016 DC.
• In order for SSO to function on an Azure AD joined device you need to publish a CRL. This can be challenging to configure and debug if you are not comfortable with Enterprise PKI.
• SSO will not work until the NGC is synced back to Active Directory

Certificate Trust

The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience of WHfB.

Companies using ADFS only had the option to use certificate trust. We still found, in our experience, that most companies used the key trust type for WHfB. Did anybody who configured certificate trust live to tell the tale even? Who knows!

Our thoughts on certificate trust are few, so we won’t dwell on it in this post.

Certificate Trust Pain Points

• Requires a Federated domain. AD federation with AAD. (Who else vomited a little in their mouth when they read ADFS?)
• Requires a PKI for SSO to on-premises resources. Users are issued certificates during enrollment to WHfB.
• Certificate requirements are complex – no one got no time for legacy PKI design.

What is Cloud Kerberos Trust?

WHfB hybrid key and certificate trust always had a lot of moving parts. AD Connect, Device Registration, PKI, sync wait times and more. There was often misunderstanding on configurations, timings and almost every blog post or Microsoft doc you looked at never quite explained the setup for your specific scenario.

Microsoft knew this complexity was a roadblock to many and they really wanted to help organisations improve their authentication posture – moving away from insecure passwords was an itch everyone was eager to satisfy.

The big challenge they had to solve was the reliance on the credential sync and complex configuration of many moving parts. Along came Azure AD Kerberos.

Azure AD Kerberos was first brought in to enable FIDO2 authentication on HAADJ devices. Azure AD Kerberos facilitates kerberos ticket issuance by Azure AD instead of on-premises Domain Controllers. Because a DC was not critical to the ticket issuance, neither was the wait for AD Connect to sync when a user first setup their WHfB credential. Azure AD Kerberos allows AzureAD to issue TGT’s that came down with the PRT – amazing stuff.

Onto a winner:-

• 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. This means that there isn’t delay between the user’s WHFB provisioning and being able to authenticate to Active Directory
• Passwordless security key sign-in can be deployed with minimal extra setup

At a high-level, “Cloud Trust” means, that we establish a chain of trust directly with Azure Active Directory. Instead of a triangle of trusts that involve our local AD, PKI, the device TPM storage things become incredibly simple, incredibly quickly.

The big game changer with Cloud Key Trust is WHfB works immediately after enrolment for SSO to domain resources

There is no need to wait for Azure AD Connect to sync some public key material to establish the trust, or anything like that. It. Just works. So, that’s the first problem Cloud Kerberos Trust solves – the users waiting for sync and the issues that arise from trouble with the msDS-KeyCredentialLink in AD. So, the big game changer with Cloud Key Trust is that WHfB works immediately after enrolment for SSO to domain resources

The Second problem Cloud Kerberos Trust solves – no more PKI requirements or CRL over http required for hybrid devices.

A third problem Cloud Kerberos Trust solves, limited normally to large organisations, is the added CPU overhead for KDC Authentication when using key trust. In some instances those organisations had to spin up extra domain controllers to handle the extra processing load.

Can I get rid of the PIN requirement now?

“Silly rabbit! Trix are for kids” And tricks like removing the PIN code is not a thing.
You need the PIN as a fallback for your biometrics. Just like with any passwordless solution out there, we need a way for the user to recover in case their biometrics fail, or if there simply are no biometrics available (I hear that people can loose face!).

Remember fundamental principles of multi-factor authentication.

• Something the user has: Any physical object in the possession of the user, such as a security token (USB stick), authenticator app, their device, etc.
• Something the user knows: Certain knowledge only known to the user, such as a password, PIN, etc.
• Something the user is: Some physical characteristic of the user (biometrics), such as a fingerprint, etc.

So if your argument is that the PIN seems insecure compared to a password, think again – it ONLY relates to the unlocking of your access token in the TPM for use in Windows Hello for Business. The password on the other hand will let you in from a remote location, which is ideal for a hacker or any bad actor (the password is what you should focus on getting rid of!).

But of course, protecting the PIN is still important, so here are a few strategies to consider if you feel that the PIN is a security risk (These are notes from the field and not necessarily to be considered recommendations).

1. Teach users to only use Biometrics, and have a policy of only using the PIN in a secure way (e.g. never in the open Office, and always looking over their shoulder while wearing a tin foil hat!)
2. IT can be a part of the WHfB provision process, and choose the unique PIN for the users. This PIN could be kept with IT, and never disclosed to the user unless required. If you choose this option, remember to disable PIN recovery for the users, and have a policy of never using the same PIN on multiple devices. Using this strategy is not recommended, as you are essentially creating a treasure chest for any bad actor to abuse (i.e. insider risk).
3. Make the PIN more complex but avoid making it possible for the user to replicate their actual password (if you are still providing them with such a relic). This could be achieved by adding a requirement for the use of lower case letters (not upper case) besides just the digits.

As a final word of advice on the whole PIN code debacle – consider your very own smartphone. How do you login to that?
Face? Fingerprint? PIN? – Regardless of your answer, consider that you are holding on to that device 24/7 like a crack addict. And just put things into perspective, when you say that PIN seems less secure than a password.

How does authentication work to on-premise resources?

After Cloud Kerberos Trust is enabled for the user (see the next post in our mini series), we can observe the following authentication flow when we attempt to access domain resources – after all, the main purpose of enabling Cloud Trust with WHfB is for SSO authentication to domain resources.

• There is still a requirement for the user to be synchronized from Active Directory. This is how we discover the domain name associated with the user in order to request tickets from the KDC.
• Authentication to Active Directory from an Azure AD joined device begins when the user first attempts to use a resource that needs Kerberos authentication.
• The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user’s domain.
• Using the hint, the provider uses the DClocator service to locate a 2016 domain controller.
• DCLocator needs a domain hint, which it gets from the onpremisedomainname that came down with the PRT.
• A Domain Controller (KDC) is then returned to the client to continue normal service ticket issuance.

Note If DNS is broken this lookup will fail – it’s always DNS when things fail
_{(except when it’s routing)}

• After locating an active 2016 domain controller, the Kerberos provider sends a partial TGT that it received from Azure AD from a previous Azure AD authentication with the domain controller.
• The partial TGT contains only the user SID and is signed by Azure AD Kerberos.
• The domain controller will verify that the partial TGT is valid.
• On success, the KDC returns a full TGT to the client so the client can begin requesting service tickets.

In summary, Azure AD Kerberos issues a partial TGT to the user. The partial TGT is then exchanged for a full TGT from the KDC and normal service ticket issuance continues when the user tries to access domain resources

PRO-TIP

DNS hit and miss in your place?
You can test if DCLocator is able to return a list of valid DC’s by running the nltest command

nltest /dsgetdc:contoso.local

Summary

In part 1 of this mini series we introduced the concept of Cloud Kerberos Trust.

Being able to receive partial TGT’s from Azure AD is a game changer in terms of speed to SSO logon for on-premises resources AND for simplicity of configuration for admins.

In Part 2 we will look at how to configure Cloud Kerberos Trust. We are waiting over on the next page 🙂