Passwordless Authentication with Windows Hello for Business

Passwords are everywhere and nobody likes them.  Not only are they a pain to remember and manage, but they also continue to be a primary source of data breaches.  This affects companies whether they are storing their data in the cloud or on-premises. According to the 2020 Verizon DBIR, 77% of cloud breaches involved stolen and compromised credentials.

Clearly, passwords aren’t great and there are better ways of doing things. Smartphones and tablets have moved away from passwords and most people today sign into their phone with their face or fingerprint.    

But how does that translate into the business world within corporate networks?  Microsoft has introduced some very interesting “passwordless” security options built around their Windows Hello for Business (WHfB) product. 

I had never really gotten my hands on this technology, but as many of our customers have been exploring whether Passwordless security was a good option for them, I wanted to make sure I understood it.  

There are several upsides of going to passwordless security that make this an appealing security approach.  This blog walks you through my experience evaluating WHfB.

The Objective

My goal in this research was to evaluate a Passwordless authentication approach based on Windows Hello for Business in a hybrid Azure Active Directory environment. This is representative of what a lot of companies are experiencing challenges with, so I thought if I could explore this, I could answer these basic questions:

1. What is Windows Hello for Business and how does it work?
2. What are the benefits and drawbacks of Windows Hello for Business?
3. What threats and attacks can still be perpetrated against a Passwordless hybrid AD model?

This blog does not cover an in-depth guide on how to set up or configure Windows Hello for Business, but I will provide resources that I found very useful when setting up my own lab as it can get a bit complicated in places if you don’t understand all the steps (which I definitely did not when I started). 

The Setup

Here is the basic set up of my Hybrid lab for this test.  My lab consists of:

1. On-premises domain controller (2016), member workstation (Windows 10), and File Server (2016), all joined to the same domain
2. Azure AD (AAD) domain with Azure AD Premium licenses.  Azure AD Connect synchronizing users and hashes, no AD Federation Services. 
3. AAD joined devices through Intune

With that setup, my goal was to be able to log into the workstation as a user without a password and access an on-premises resource (file share) and a cloud resource (Teams / SharePoint Online / Azure) without being prompted to enter a password. 

To accomplish this, I chose the Hybrid Azure AD Key Trust deployment model (see here). This does not currently support remote desktop connections with WHfB. If you really need that, you have to bring in ADFS and use a certificate trust deployment. In my lab, I will be using SbPAM for that anyway (shameless plug I know, but really, I would).   

I have my lab and I have a mission. Now let’s dig into what Windows Hello for Business is all about.

What is Windows Hello for Business?

WHfB is a form of multi-factor authentication that lets a user log in with something they have (their laptop or phone) and either something they know (a PIN) or something they are (biometrics).

While Microsoft provides lots of documentation and technical details on Windows Hello for Business, I think this is the simplest and best way to summarize it.    

Some of the extra security comes from the user’s PIN or biometrics being tied to the device on which they registered. This means in order to steal your identity through WHfB, somebody would have to steal your physical device. This is way more secure than passwords, which can be replayed from anywhere. Once you’ve gotten WHfB deployed and user logs in they will be asked to register that device with a screen similar to this:

Then they will register their PIN. The Identity provider (Azure AD or AD) will then map a public key for that user. When the user logs in next time, they will sign some data using their private key which is tied to their device and then send that over to the identity provider to verify the user and authenticate them.  Sounds simple enough. Again, the main benefit here is that the only place the secrets for a user are stored is on their device and they are well protected. This is different than traditional AD passwords where compromising the DC could expose every single user password through the Ntds.dit file, as just one example.

Deploying Windows Hello for Business

This is an area I am not going to go too deep into. There are several ways you can deploy it and it depends on variables such as:

• Do you have cloud-based and on-premises resources your users need to access?
• Do you have Windows 2016 domain controllers or not?
• Do you currently push out and manage certificates to user devices?
• Are your workstations running Windows 10?

If you want some sound guidance on what deployment model is right for you, check out this post from Microsoft.

In my lab, I chose to go with a Hybrid Azure AD Key Trust deployment. That included the basic following steps:

• Set up your on-premises domain (2016 domain controller please) and Azure AD domain and connect them with Azure AD Connect. I enabled password-hash synchronization with SSO. 
• Ensure Azure device registration is set up so you can auto-register your devices
• Set up your certificates the right way on your DCs including setting up a Certificate Revocation List (CRL) (which I forgot to do in my lab the first run through).
• Configure your clients to enroll in Windows Hello for Business. This can be done through Intune if you are managing your devices there or through GPOs if you aren’t.

That was about it! After getting through all of that, I could log into my device with a PIN and then access SharePoint Online and on-premises file shares without being prompted for logon. 

Success!

Also as a tip, get ready to run “dsregcmd /status /debug” at least 100 times as you work through what is and isn’t working while trying to get your devices registered appropriately. 

My Thoughts on Going Passwordless with WHfB

Please read on if you want to get into the details of the research, but here are some thoughts and observations on using WHfB for Passwordless authentication in a hybrid environment.

#1 – Passwordless does not mean no more passwords

WHfB does not eliminate passwords. This does make it so your end users may only have to type their passwords in once a week or once a month rather than 10 times a day. You still have passwords to manage and protect, but it may let you enforce stronger passwords since your users don’t have to use them often. 

I know Microsoft lists the elimination of passwords as Step 4 in their Passwordless Strategy, but for a Hybrid AD-based environment, that is not something that can be expected. Ideally, you could get to the point where users don’t know their passwords, but they are still there lurking in the shadows of your on-premises Active Directory environment. 

#2 – A lot depends on your needs

The value of Windows Hello for Business is based on what your company uses. It worked great in my lab for connecting to Microsoft 365 (via Edge browser) and network file shares without any password prompt. If you have custom web apps and lots of cloud apps, you have to start getting them into the Azure SSO support which is outside the scope of this research but seems to have broad coverage and a web application proxy for custom on-prem web apps. 

First, identify where you use passwords today. Then compare that list to WHfB to see how much it can help.

#3 – Password Attacks are still a thing

This does not eliminate password-based attacks like password spraying. AD accounts still have passwords. You still need a good password security strategy for human and non-human accounts. If done right this can significantly reduce password attacks, but only if you enforce better standards and make sure everybody has their passwords reset to meet those standards. 

#4 – Lateral Movement is still a thing

This does not eliminate pass-the-hash, pass-the-ticket, and other lateral movement attacks, as well as Golden Tickets and other privilege escalation techniques. Those take advantage of non-interactive logons and are outside the scope of Windows Hello for Business.

#5 – Passwordless is a great way to go. Get there as soon as you reasonably can.

Even with all that being said, this is a good direction to move and I would recommend most companies evaluate it if you are using Azure and already own licenses for the necessary components. It makes signing in easy, and you can improve your password security measures without user friction. It also gets users out of the password-only mentality. This may make it seem weird when they are asked to enter their password somewhere (like in a phishing scam) and reduce the risk of inadvertent credential exposure. Passwordless is a good thing. It just doesn’t solve all of your problems and you need to assess your company’s readiness to adopt the technology.

References

In all honesty, I struggled heavily at a few points here.  If you are going to try to get this set up in your lab, you may want to use some of these resources.  The best overview I found was this one here:

I also found this video very useful:

This blog was very good as well: https://identity-man.eu/2020/02/13/password-less-3-of-5-going-password-less-with-windows-hello-for-business-hybrid/