Skip to content
Menu
ChrisOnSecurity
  • Blog
  • Microsoft Security portals
  • Presentations
  • GitHub
  • About me
  • Impressum
  • Disclaimer
ChrisOnSecurity

Going passwordless with Azure Active Directory

Posted on 28. July 20195. January 2020

Passwords are not ideal

A world without passwords! Passwordless – seems to be the dream for anyone that has to manage a number of accounts. Who even likes passwords? Well, I know who doesn’t:

IT admins don’t like passwords

Why passwords are a major pain point for many organizations:

  • reused credentials across multiple services increase the attack surface
  • forgotten passwords create an additional overhead for helpdesk personnel
  • no matter how secure your password is: it is phishible
  • you have no control over how and where passwords are used. After all, they’re just a random string

User don’t like passwords, either

Fortunately, end users also don’t quite like them!

  • secure passwords are hard to remember if you follow best practices like not reusing passwords
  • entering passwords on mobile devices is often frustrating
  • password managers are cool, but you still need a way to access those and you have to have access to the database when you need to get a certain password
  • again, passwords are phishible and a lot of users have experience with “hacked” private accounts

Searching for a better solution

Since several years there are some alternatives or mitigations to some of the problems I mentioned above. However, it seems that most solutions target securing sign-ins with additional means like Multi-Factor Authentication. Especially MFA is a good approach but it still depends on a password to begin with.

In terms of Active Directory smart cards are a thing – kind of. Most organizations I encountered do not really use them, however. If you start using hybrid cloud, identities or even native cloud identities they become more and more obsolete.

So, is there a solution that is both convenient and highly secure? Yep, Azure Active Directory offers three ways which you can use right away (with more or less implementation effort):

  • Windows Hello for Business: has been with us for quite some time. It allows users to authenticate against their Windows 10 device and AD / AAD using either biometics or a PIN. So even if your devices do not come with fingerprint readers or infrared cameras you can get started.
  • Microsoft Authenticator: again, not really new and a comfortable companion for MFA. Recently, Microsoft added the capability to use it as a single entity for strong authentication.
  • FIDO2 security keys: the most recent addition to AAD. You can now use a FIDO 2 key to savely store credentials for multiple users.

How can biometrics or a PIN be more secure than a good password?

Good question! I get that a lot from customers. All these authentication methods are not trying to replace the password. They try to enhance it. With a password you have a single requirement for authentication: you need “something you know”. With any passwordless scenario this is a bit different.

  • Windows Hello for Business: something you have (the device) + something you are (biometrics) or know (PIN)
  • Microsoft Authenticator: something you have (the device) + something you are (biometrics) or know (PIN)
  • FIDO2 keys: something you have (the device) + something you are (biometrics) or know (PIN)

So as you can see, even though a PIN seems to be less secure than a password it actually isn’t as you also need an additional factor (device) to authenticate. So, you could say all passwordless methods with Azure AD are Multi-factor Authentication out of the box.

How the authentication flow works

Step 1: the user unlocks the secure element (TPM / app / security key) that is holding their private key with either biometrics or a PIN

Step 2: the device sends an authentication request to Azure AD

Step 3: Azure AD sends back a nonce that is used to prevent replay attacks

Step 4: the device uses the user’s private key to sign the nonce. It is then returned to Azure AD with the key ID.

Step 5: Azure AD returns a refresh token and the encrypted session key which is then stored in the secure element

Step 6: the device returns the signed refresh token and the derived session key back to Azure AD for verification

Step 7: the user is now authenticated and in possession of all necessary tokens and keys

Now, let’s have a look at each of those options in detail:

Windows Hello for Business

Pre-requisitesWindows 10 1511 or later
DevicesPC with a TPM chip, biometrical scanners (or a keyboard for the PIN 😉 )
User experienceUsers can sign-in to their Windows 10 PCs by using either biometrics or a PIN; authentication is unique to the device, users need both the device and PIN / biometrics to authenticate
ScenariosPassword-less sign-in to Windows devices, extended by single sign-on to other devices (HfB can be used remotely as well) or applications (like O365 in a browser e.g.)

To be honest, I will not focus on implementing Hello for Business in hybrid or on-prem only scenarios. Depending on your deployment method (key trust vs. certificate trust) and other factors, this takes a bit more steps than in the cloud. Fore Azure AD joined Windows 10 clients it takes no more than creating a Intune configuration profile (profile type: identity protection):

There you can set various options for PIN, biometrics, TPM usage, and most interestingly: you can also enable users for security keys for sign-in. This comes in handy when using FIDO2 authentication as described later in this article.

To make things not too easy there is a separate Windows Hello for Business policy that can be found in Intune > Device Enrollment > Windows enrollment. This is the default policy for all devices that are being joined to Azure AD.

Microsoft Authenticator

Pre-requisitesMicrosoft Authenticator app on Android or iOS
DevicesMobile phones
User experienceUsers can sign-in to their corporate account by using either biometrics or a PIN to accept the authentication prompt that is sent to the app
ScenariosPassword-less sign-in to corporate accounts on any device; prefered usage: get access on a device that is not corporate owned or in a browser that does not support single sign-on from Hello for Business (Firefox, e.g. Chrome does support SSO with the “Windows 10 Accounts” addon)

Enabling

Allowing users to setup passwordless sign-in with the Microsoft Authenticator app is pretty straight forward. All you have to do is allow it to either all users or a certain group. Settings can be found in the new authentication method policy in Azure AD:

As you can see further options are a bit limited at the moment. E.g. it is not possible to require passwordless setup for the Microsoft Authenticator at the moment. What you also have to do is set the new converged MFA / Self-Service Password Reset experience for users that should be able to use passwordless sign-in methods. This can be found in the users settings section in Azure AD:

Onboarding

All users have to do is add the Microsoft Authenticator as a MFA factor by using the guided setup at aka.ms/setupmfa
After that they can select to “Enable phone sign-in” on the Authenticator entry:

To be recognized as a trusted device, users also must register their phone with Azure AD. This does not allow any kind of management and only serves as an anchor. Just as it is needed for Intune App Protection e.g.

Using it

After that the user will be automatically prompted to sign-in using the passwordless experience. After entering their email address they will be prompted do send a notification…

… followed by the number that must be matched in the Authenticator app:

Important point to remember: if users do not successfully finish the passwordless logon using the Authenticator app they will not be able to use this method for the next try. They will have to use their password at least once before passwordless sign-in is available again.

FIDO 2 security keys

Pre-requisitesWindows 10 1809 or later
DevicesFIDO2 security devices that are supported by Microsoft / Azure AD. They are either connecting via USB or NFC
User experienceUsers can sign-in to their corporate account on browsers and Windows 10 devices by using either biometrics or a PIN to validate their identity against the FIDO2 key.
ScenariosPassword-less sign-in to corporate accounts on any (shared) device; preferred usage: workers and other employees that are on the go (helpdesk, kiosk devices, hospital teams)

Enabling

Enabling users for FIDO 2 keys is pretty similar to the Authenticator app. Again, you can set the tenant’s authentication method policy to either allow all users or a certain group to be able to register FIDO 2 tokens:

At the moment, you should keep “Allow self-service set up” and “Enforce attestation” enabled. In the future it will be also possible to white or black list certain FIDO2 keys based on their GUID.

In the private preview that preceded the current public preview it was already possible to provision FIDO2 keys for other users, so most likely there will also be some kind of bulk enrollment for central management.

Onboarding

Again, users need to head over to aka.ms/setupmfa (with enabled converged experience as mentioned in the Microsoft Authenticator section) to add FIDO2 keys to their account.
It can be added as a sign-in method:

Select the type of device (USB or NFC):

Click next to be redirected to the next step:

Depending on your key manufacturer you will be prompted to either touch it (fingerprint reader) or enter the PIN of the key (which will be set up if it’s a brand-new key).

PIN and biometrics are always exclusive to the complete key and can’t be different for every single account you add.

After that you can select a name for the key and that’s it.

Using it

To use a FIDO2 key users will have to select “Sign-in options” in either Microsoft Edge or Mozilla Firefox. At the moment, Chrome does not support it. With the new Chromium-based Edge this might also change for Google’s browser.

Now select “Sign in with Windows Hello or a security key”:

To verify your identity, you need to either enter your PIN or touch the fingerprint reader:

If you have enrolled multiple accounts to the key, you have to select the one you want to use for the session.

And that’s it. You’re authenticated.

FIDO2 sign-in to Windows 10 devices

FIDO2 security keys can also be used to sign-in to devices. At the moment you must enable Windows 10 1809 or later to do so, e.g. by using custom OMA-URI settings in Intune:

OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
Data type: Integer
Value: 1

It can also be added to Windows Hello for Business via Intune policies.

Things to consider with passwordless

All in all, Microsoft already offers great functionality to go passwordless. Unfortunately, not all scenarios and applications are capable of using these new sign-in methods. These are the things you might want to consider:

  • using passwordless sign-in is automatically flagged as “strong authentication”, so if you enforce MFA in Conditional Access this prerequisite is already met
  • sign-in to mobile applications on iOS or Android might be inconsistent or not working at all
  • at the moment, in order to user the Microsoft Authenticator for passwordless sign-in the device has to be registered with Azure AD which requires a password. Microsoft is working on it, however
  • Third party or on-prem applications that use hybrid users might not be able to use passwordless sign-in depending on how they are published in Azure AD

Summing things up

Yep, there are still some limitations regarding the passwordless journey. However, it is already possible to use it for a majority of scenarios. I am very sure that in a few years using your password will be a niche scenario. Even today, I am hardly using my corporate password at all.

Thanks for reading!

Chris

@ChrisOnSecurity@infosec.exchange

Recent posts

  • What’s new: Microsoft 365 Security & Compliance December 2022
  • What’s new: Microsoft 365 Security & Compliance November 2022
  • Counter MFA spam attacks with Azure Active Directory
  • Windows 11 security – a first look
  • Conditional Access – device identification using certificates

@ChrisOnSecurity

Tweets by ChrisOnSecurity

Recent posts

  • What’s new: Microsoft 365 Security & Compliance December 2022
  • What’s new: Microsoft 365 Security & Compliance November 2022
  • Counter MFA spam attacks with Azure Active Directory
  • Windows 11 security – a first look
  • Conditional Access – device identification using certificates

Tags

Administration Administrative Units Android AV Azure Active Directory Azure AD Azure Sentinel Client Security Conditional Access Conditional Access App Control Defender ATP Delegation EDR EMS Enterprise Mobility + Security Identity Protection Information Protection & Compliance Linux M365 M365 E3 Mail Security MCAS MDAPT MDATP MFA Microsoft 365 Microsoft 365 E3 Microsoft 365 Security Microsoft Cloud App Security Microsoft Defender ATP Microsoft Ignite Mobile Security Monitoring Network Control Office 365 Office ATP passwordless Perimeter Security Baseline Session Control Sysmon Unified Incidents User submissions Web Content Filtering Windows 10 Enterprise
©2023 ChrisOnSecurity | WordPress Theme by Superbthemes.com
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Cookie settingsACCEPT
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT