One of the main Identity related topics during Microsoft Ignite March 2021 edition was passwordless. Microsoft announced at the event that passwordless authentication is now generally available, and Microsoft is now urging their customers to start their journey towards passwordless.

As the name implies, going passwordless means that we will get rid of passwords for good, replacing it for a more secure solution based on usage of: something you have and something you are or something you know. Based on this you might ask, “Hey, but doesn’t having a username and password align with the something you have, and something you know statement?” – well that’s correct, but in the case of passwordless, the something you know part will not be transmitted over the network and is often device specific, making it less vulnerable.

That basically means that if someone else knows the PIN you use to login to Windows Hello for Business on your Windows 10 device, that PIN is theoretically useless on another device, since that PIN is device specific and stored locally. Figuring out the PIN of another user is also referred to as “shoulder surfing“

I do see one big caveat here though, and it’s something we have learned from the past. People tend to re-use their password for convenience. In that way they only have to remember one password for logging in into multiple services. I expect the same to happen for PIN, because there is nothing stopping a user from using a PIN multiple times to unlock a multiple of devices. (for example, use the same PIN to both unlock their mobile phone, and their Windows device). The only way to stop this is to require a biometric identifier (fingerprint or face recognition a.k.a. “something you are”).

Also let’s not forget, that if attackers really want to that there are other ways to get what they want. You have probably all seen a movie or series where the actor cuts loose the finger of their dead victim and use that to unlock doors or give access to devices. Another funny example is the one where kids find out that they can unlock the mobile of their parent by using their fingerprint while they are asleep.

But let’s not forget, that using methods which only require login using username and password are “evil”, especially in a world where your users “and attackers” can login from anywhere on the internet, and users can easily fall victim for password phishing attempts or are vulnerable because they are using easy guessable passwords. An attacker in possession of a user’s username and password is one of the most common ways of account compromise today.

We are therefore urging user to start using multi-factor authentication, where the user besides username and password also needs something else to login. That something else, in my world is often approving a push notification coming from the Microsoft Authenticator app installed on my mobile device. From an end-user perspective though, using this method is more inconvenient and something we are trying to solve by implementing “Single sign-on” solutions as much as possible.

Modern Authentication

One of the requirements you must fulfil before you are able to go to passwordless authentication, is that you have to get rid of legacy authentication, by blocking legacy authentication you block authentication protocols which support username and password logins, and transition to protocols being able to support modern authentication which is based on tokens.

In order to migrate your Azure AD environment to Modern Authentication you have to perform several steps, which I explained in my article: “Microsoft is going to disable basic/legacy authentication for Exchange Online. What does that actually mean and does that impact me?“

The work you have to do though in order to go fully passwordless doesn’t involve Microsoft products only, also other software and services you are using must support modern authentication protocols, since in order for you to get rid of passwords you first have to make sure you don’t need them anymore.

History

The Microsoft passwordless story started in May 2016, when Microsoft released a paper with their recommendations for password management. At that time Microsoft detected 10 million username/password pair attacks every day. The paper made the following recommendations:

1. Maintain an 8-character minimum length requirement (and longer is not necessarily better).

2. Eliminate character-composition requirements.

3. Eliminate mandatory periodic password resets for user accounts.

4. Ban common passwords, to keep the most vulnerable passwords out of your system.

5. Educate your users not to re-use their password for non-work-related purposes.

6. Enforce registration for multi-factor authentication.

7. Enable risk based multi-factor authentication challenges.

The paper also discusses some patterns (a response to a recurring problem that is effective) and one of those patterns was to use Microsoft Passport and Windows Hello. It stated: “Passwords can be forgotten or stolen, so the best option is not having a password at all”

Passwordless strategy

In 2017 during Ignite Microsoft shared their strategy on how to transition to passwordless in 4 steps, with the end goal of eliminating passwords from the Identity provider once and for all.

Develop password replacement offerings
Reduce user-visible password surface area reduction
Transition into password-less deployment
Eliminate passwords from identity directory

Step 1 – Password replacement offerings

Microsoft offers the following passwordless authentication options:

Windows Hello for Business
Microsoft Authenticator app
FIDO2 security keys
Text message and Temporary Access Pass

Windows Hello for Business

With the release of Windows 10, Microsoft first introduced the Microsoft passport and Windows Hello concept providing multi-factor authentication. Later the two technologies were combined into what we now know as Windows Hello for Business (WHfB).

With WHfB users need to be verified using two-step verification during rollout. Once enabled, users can sign-in to their device without needing their password. They can use a pincode, or use biometric methods like face recognition or a fingerprint. WHfB authentication is tied to the local device where the biometric data stored securely in the Trusted Platform Module (TPM) chip or in software (not recommended but possible). The biometric data therefore doesn’t roam with the user.

WHfB uses some components to accomplish device registration, provisioning and authentication and must be enabled using either Group Policy or using MDM. How the different components work is depending on your situation:

Azure AD joined, AD joined or Hybrid Azure AD joined
Whether you still use Active Directory Federation Services (ADFS)
If you use Key trust or Certificate trust authentication to authenticate to AD.

For devices which are not managed at all, Microsoft provides the “Windows Hello convenience PIN” option, where users can sign-in using their PIN but don’t have the full options of WHfB available.

If you haven’t enabled WHfB yet in your organization, I suggest to start with the following document and work from there: Planning a Windows Hello for Business Deployment.

The Microsoft Authenticator app is mostly used for providing multi-factor authentication. It can also be used as a passwordless sign-in mechanism. Users can sign in to any platform or browser by getting a notification to their phone, matching a number displayed on the screen to the one on their phone, and then using their biometric (touch or face) or PIN to confirm.

Microsoft Authenticator app

Since recently Microsoft is also providing the option to store passwords in the Microsoft authenticator app which then roam over the devices the user is using, making the app even more valuable to use.

FIDO2 security keys

Another option is to use a physical security key, which the user can bring along. These security keys are there in multiple form factors and either use USB or Near Field Communication (NFC) to connect to the device. You use these security keys in combination with a PIN or use biometric options (in most cases a fingerprint) to unlock its functionality.

Microsoft supports security keys from the Fast Identity Online (FIDO) alliance. FIDO2 is the latest standard and supported by Azure AD. FIDO2 security keys are an unphishable standards-based passwordless authentication method that can come in any form factor. Fast Identity Online (FIDO) is an open standard for passwordless authentication. FIDO allows users and organizations to leverage the standard to sign in to their resources without a username or password using an external security key or a platform key built into a device.

See the following link for the manufacturers of security keys which are supported: FIDO2 security key providers

Tip: Did you know that you can store more than one account on a security key. Handy if you perform tasks for multiple clients and want to have a way to passwordless sign in.

Step 2 – User-visible password surface area reduction

Reducing the user-visible password surface area is something you can accomplish by using Windows Hello for Business on your Modern Workplace. What I currently see at my customers is that more and more users never use their password anymore, because they sign in to their Windows Devices using biometric methods or PIN.

In this phase we must therefore make sure that we have some things in place:

Disable expiration of their password
Force MFA when logging in, either through meeting the MFA requirement through WHfB or by asking for it via the Microsoft Authenticator.
Implement Self Service Password Reset (SSPR) in case users have forgotten their password and need to reset it.

We can force MFA scenario based using Conditional Access, if you want to know more about setting up Conditional Access I want to suggest that you start with reading my paper on this subject, for which you can find the latest version here: February 2021 update of the Azure AD Conditional Access demystified whitepaper and workflow cheat sheet. Implementing Self Service Password Reset (SSPR) is something I described as well, see: Enabling Self Service Password Reset (SSPR) for your Modern Workplace users

Step 3 – Password-less deployment

Up until Ignite March 2021, we didn’t have a solution yet for onboarding users without them needing a password. This has changed now, since Microsoft introduced the SMS based authentication and Temporary Access Pass (TAP) functionality.

SMS-based authentication

SMS-based authentication lets users sign in without providing, or even knowing, their user name and password. After their account is created by an identity administrator, they can enter their phone number at the sign-in prompt. They receive an authentication code via text message that they can provide to complete the sign in. This authentication method simplifies access to applications and services, especially for Frontline workers.

SMS based authentication has some limits though:

SMS-based authentication isn’t currently compatible with Azure AD Multi-Factor Authentication.
Except for Teams, SMS-based authentication isn’t compatible with native Office applications.
SMS-based authentication isn’t recommended for B2B accounts.
Federated users won’t authenticate in the home tenant. They only authenticate in the cloud.

It’s therefore not usable for normal corporate users, but is more a solution targeted for specific use cases (Frontline workers)

Temporary Access Pass

A Temporary Access Pass is a passcode which is time-limited and issued by an administrator. The TAP satisfies strong authentication requirements and can be used as a method to onboard other authentication methods, including Passwordless ones. By using a one-time code users never need a password in the first place, and once setup use passwordless methods only.

A Temporary Access Pass also makes recovery easier when a user has lost or forgotten their strong authentication factor like a FIDO2 security key or Microsoft Authenticator app, but needs to sign in to register new strong authentication methods.

When configuring the Temporary Access Pass you have some options to determine the lifetime and character length. The Require one-time use setting, which is set to No by default determines whether or not you are able to use the time limited code multiple times during its lifetime.

After the Temporary Access Pass authentication method is enabled and configured you can generate the Temporary Access Pass for the user, if not already done you first need to enable the new user authentication method experience after which you are able to add the Temporary Access Pass as an authentication method.

Step 4 – Eliminate passwords

The final step is where passwords simply do not exist in Azure AD, once accomplished you have successfully banished passwords for good. In one of the published articles on this subject, Microsoft already gave a glimpse of what this may look like, also telling that this functionality will become available in spring 2021 (that’s very soon already)

Some other special scenario’s explained

Besides explained above, there are some other things I think are worthwhile mentioning as well

Accessing on-premises resources when Windows Hello for Business is enabled

As you might know, Azure AD joined Windows 10 devices have access to on-premises resources like file shares, printers and applications. A requirement is that you synchronize your on-premises identities to Azure AD using Azure AD connect. Azure AD connect synchronizes on-premises user and domain information to Azure AD, and sends this information to the device along with the Primary Refresh Token (PRT). The local security authority (LAS) service then enables Kerberos and NTLM authentication which provides the SSO experience to the on-premises resources. For more information about how this works see: How SSO to on-premises resources works on Azure AD joined devices | Microsoft Docs. The same SSO functionality is there for Hybrid Azure AD joined devices, since for those devices are joined to Active Directory and registered in Azure AD.

With Windows Hello for Business enabled, you will notice that by default SSO will not work to your on-premises resources when using either Azure AD joined or Hybrid Azure AD joined devices. This is because some additional configuration is needed in order to make SSO using WHfB login possible. This additional configuration can be accomplished by either deploying the Key trust or Certificate Trust model. Both models require that you have an Enterprise Public Key Infrastructure (PKI) available.

The links below give some more detailed information of the authentication flows when using the options described:

The Certificate Trust model requires an available Active Directory Federation Services (ADFS) environment, so if you are using Pass Through Authentication (PTA) or Password Hash Sync (PHS) you can only use the Key trust model. The Certificate Trust Model also requires you to distribute client certificates to all your clients.

The key trust model only requires certificates to be deployed to your domain controllers. There is one disadvantage though with Key trust, and that is, that it’s not supported if you are using the RDP protocol. You therefore cannot accomplish SSO if you want to connect to a remote desktop via RDP. Microsoft states that they do support the use of Remote Credential Guard in this case, but this only works with the classic remote desktop client (mstsc.exe) and not the Remote Desktop Universal Windows Platform application, which is often used for example to access Windows Virtual Desktop environments.

If you want to implement Key trust, you must have a reasonable amount of Domain Controllers which must be Windows Server 2016 or higher. Key trust is the model with the most flexibility, because it allows you to phase out your ADFS environment, which I highly recommend.

The following guides detail how to setup Certificate trust or Key trust:

Plan your passwordless deployment wizard

The passwordless deployment wizard, available via https://aka.ms/passwordlesssetup will help you choose the appropriate passwordless authentication method for your organization. You’ll be required to answer a few questions, about your users and how they sign in, to guide you through the authentication set up process. The wizard is part of Setup guidance Microsoft is offering in the Microsoft 365 Admin center containing more and more guides helping customers to configure several settings using user friendly wizards.

Overview page
Choose deployment scenario
Windows Hello for Business
Phone authentication options
FIDO 2 Security Keys

Multi factor unlock

Multi factor unlock can be used in the scenario where unlocking a device using a single credential (PIN, biometrics or password) doesn’t meet the requirements. For example because it’s easy for users to get an hold of each others PIN (shoulder surfing) or where people are tempted to share their PIN with each other (production floors, shared devices). By configuring multi factor unlock, you add an extra authentication method which must be available before the user can sign in.

Multi factor unlock is accomplished by defining so called “First unlock factor credential providers” and “Second unlock factor credential providers”. When multi factor unlock is enabled users unlock their device using at least one credential provider from each category before Windows allows the user to proceed to their desktop.

The default credential providers for the First unlock factor credential provider include:

PIN
Fingerprint
Facial Recognition

The default credential providers for the Second unlock factor credential provider include:

Trusted Signal
PIN

So, based on the options mentioned above, we could configure sign-in by letting users use both their Fingerprint and PIN before they are able to sign-in.

For the Second unlock factor credential provider we also have the option to configure ‘Trusted Signals”. You can configure the following items as trusted signals:

Bluetooth
IP Configuration
WiFi

So for example, you can satisfy the second unlock factor by having a device with you which you paired using Bluetooth. Or you are automatically satisfying the second unlock factor because you are in a predefined IP network, or using a SSID of a known WiFi network.

Personally I think the IP configuration factor is the least usable, since most companies use very generic IP addressing schemes for users who are in the building, besides that this is easy guessable the chances that the same network configuration is active in another network are high.

My #WPNinjaSNL colleague Ronny de Jong, wrote a detailed article about multi factor unlock, detailing everything you need to set it up for your environment. Enable Windows 10 Multifactor Authentication with Windows Hello Multifactor Device Unlock & Microsoft Intune

Web Sign-in

Web sign-in allows you to configure your Windows device in such a way, that login is only possible after a Web sign-in has been made. Web sign-in is only possible on Azure AD joined devices, and doesn’t work for hybrid joined devices. You can configure Web sign-in using the Authentication CSP. Configuring this setting, with the settings catalog being available now is a piece of cake.

Addition 9-2021: For Web sign-in Microsoft explicitely states the following:

Web sign-in enables Windows logon support for credentials not available on Windows (for example, Azure AD temporary access pass). Going forward, web sign-in will be restricted to only support Azure AD temporary access pass.

Dual Enrollment

By design, Windows 10 does not enumerate all Windows Hello for Business users from within a user’s session. Dual enrollment enables administrators to perform elevated, administrative functions by enrolling both their non-privileged and privileged credentials on their device, this only works on AD/Hybrid AD Joined devices though.

After you enable this feature, users which enrolled multiple credentials can you the second credential when using functionality like Run as different user, or Run as Administrator to start administrative tooling. At that time, because the administrative account is also rolled out into Windows Hello for Business this account can be selected. Users can then simply supply their PIN for that account and perform the administrative task.

For Azure AD joined workplaces, when administrative tasks are performed this usually takes place in the browser. I highly recommend to use separate profiles in your browser of choice. I encounter so many administrators struggling with different credentials in the same browser, while the solution is quite simple. Just create a separate profile for each account that you are using. I can tell you, I have a lot of profiles 🙂 due to my work as an consultant.

Disabling Authentication methods

If you want to enforce certain authentication methods on your device, you must disable the credential provider which you do not want to be used. What use is it to enforce biometric for example, if passwords can still be used by the user to login as well. Ronny wrote another article on this subject which I encourage you to read as well: Moving away from passwords with Windows 10, Windows Hello for Business & Microsoft Intune.

Conclusion

I hope this article gave you enough information to start your own passwordless journey. Starting the journey requires you to understand the playing field and I hope this article provided that for you.

Implementing passwordless will heavily rely on how far you are in your Modern workplace journey. I a true modern workplace, you sign-in to external applications using SSO methods and never need your password. The whole journey of going passwordless could be stalled if one of those applications doesn’t support SSO and still requires you to use your password. This concept is something that many companies still don’t understand, you cannot go to a Modern Workplace without investing in the way you use your backend applications as well. Preferably, all those applications are moved to SaaS based applications, either hosted by a 3rd party or by your own company but provided as if it would be hosted by a 3rd party provider. We are not there yet, but if you as a company are investing in that direction, I think you are in the right track.