End user passwordless utopia

With all the different technologies available in Azure and Azure Active Directory (Azure AD), it’s easy to miss the bigger picture and how they all play into the end user experience. 

 

This includes: 

 

• Azure AD
• Multifactor authentication (MFA)
• Passwordless authentication
• Conditional Access and authentication strength
• Device registration
• Primary Refresh Token
• Enterprise Apps/single sign-on (SSO)
• Intune
• Autopilot
• Temporary Access Pass  

 

Some of the above promote convenience, and some are for security. When using these technologies, we can lessen the authentication burden on users and increase our security posture.  

 

My goal is to demonstrate how a user can securely open their device and access corporate applications and data without a password, credential prompt, or traditional MFA prompt, while remaining secure.  

 

Let’s start with two common issues that we’re trying to combat: 

 

1. Authentication fatigue 

As users, we’ve been conditioned for about 20 years to enter username and password credentials whenever our device prompts us to do so. This is the very behavior bad actors rely on when phishing a user, often sending links that lead to fake sign in pages, where users enter their credentials.

 

2. MFA fatigue 

Microsoft statistics show 99.9% of accounts that have been compromised in Azure AD have been on accounts that didn’t enforce MFA.

 

As a result, bad actors have had to change their techniques when targeting end users. They rely on users following MFA prompts on their phone. Bad actors can exploit this, too. If a user’s credentials have been compromised and the bad actor sends enough MFA prompts to the user at the right time, there’s a chance the user might click “approve,” Otherwise known as MFA phishing. 

 

Numbers Matching on Microsoft Authenticator App can alleviate this problem. When a user gets an MFA prompt, they must type a number that’s displayed on their computer screen into the prompt on the authenticator app. If a user gets this prompt on the authenticator app without a prompt on their screen, then the likelihood of them getting MFA phished has dramatically decreased.  

 

How to solve this

 

By using a combination of passwordless authentication with our cloud apps or on-prem apps via app proxy, registered in Azure AD, we can address these problems.  

 

From a corporate managed device, a user can access these applications without being prompted for usernames and passwords or getting an MFA prompt/phone call/SMS on their phone.  

 
Let’s see if a picture can illustrate this scenario before we get into the details. This is the same for either Hybrid Join or Azure AD joined device.

 

Note: For illustration purposes, ignore any AD auth flows to domain controllers. 

 

Overview of the SSO flow when accessing a cloud application:

 

 

 

 

Step	Description
A	User signs into their desktop or laptop using Windows Hello for Business via pin or biometrics or FIDO2 key.
B	When the computer authenticates the user, it will then attempt to sign into Azure AD. Depending on Hybrid join or Azure AD join, the order will vary. When Azure AD validates the user, it will issue a Primary Refresh Token with an MFA claim.
C	User attempts to access an application registered against Azure AD as its IDP (identity provider). The user will be directed to Azure AD. This should be silent and transparent to the user. Due to the device being registered in Azure AD, the Microsoft Online URLs used to sign in are stored in the registry these match the URL we are directed to for SSO, and the browser will initiate SSO and attempt to use the Primary Refresh Token.
D	Conditional Access will then evaluate the attempt to sign in. If we have a policy that protects this application with MFA, because the PRT already contains an MFA claim, we do not need to involve the MFA service.
E	Azure AD now issues relevant tokens to the user. This can be SAML or OAuth, depending on the configuration of the application.
F	User will present these tokens to the application and sign into the application.

 

Deep dive part B: Primary Refresh Token (PRT) and Azure AD – Azure Active Directory – Microsoft Entra | Microsoft Lear… 

Deep dive part C: Primary Refresh Token (PRT) and Azure AD – Azure Active Directory – Microsoft Entra | Microsoft Lear… 

 

What happened here

 

Device registration 

Device registration Azure or Hybrid join is a prerequisite for Windows Hello for Business or FIDO keys. We can push the policies to start the enrollment process via different means.  

 

Passwordless/MFA 

Windows Hello for Business or FIDO2 keys replace passwords with strong two-factor authentication on devices. This authentication consists of a type of user credential that is tied to a device and uses a biometric or PIN. To deep dive Windows Hello for Business follow this link or FIDO2 logon here. 

 

We have two factors required to complete this logon: the actual device that contains key data and a pin or biometric to unlock it. This process involves something we have (the computer), something we know (pin), or something we are (bio). For more info, read this article on why a pin can be better than a password. 

 

Enterprise Apps/SSO 

When a device is joined to Azure AD, a number of URLs are added to the registry. These are the Azure AD URLs used to sign in. When you use your browser to access an application registered in Azure AD, AND if the browser supports Azure AD SSO (Edge, Chrome using the office add in, Firefox v91+), AND the Azure AD URL you’ve been directed to matches a URL in the registry, then the browser will attempt to silently authenticate you using the Primary Refresh Token that you acquired when you signed into your device. This is detailed here in browser SSO using Primary Refresh Token.

 

The user should not see a prompt to sign in. 

 

If a user is directed to a fake website that’s designed like an Azure AD page with a username/password prompt, this will be a different URL to what’s stored in the registry so the SSO process will not be initiated. However, this can’t occur because the fake webpage won’t have the required endpoints to accept the SSO. Remember that the genuine Azure AD logon page in these situations will not show a password prompt. 

 

Conditional Access 

Conditional Access will then evaluate the authorization request. Depending on the grant controls configured in the Conditional Access policy for this user/app, we could have multiple controls, such as MFA, hybrid joined, and Compliant device. We might require one or multiple controls, such as MFA and hybrid joined. The device being registered in Azure AD will satisfy the hybrid joined control and the MFA claim present in the PRT satisfies the MFA control. 

 

We can also start to require passwordless authentication like Windows Hello for Business or phishing resistant MFA like FIDO2 when accessing company data or apps using a new preview feature in Conditional Access called Authentication Strength.

 

We can get to a position where you:  

 

• Can prove the user is who they say they are and have logged onto their computer using multiple factors.  
• Sign into a managed device. 
• Access the same apps from familiar locations.
• Ensure the security stance of the user hasn’t changed (account disabled, password hasn’t been reset)
• Confirm the user isn’t showing on any leaked credential dumps.

 

So why do we need the user to re-authenticate?

 

Note: this only applies to corporate-managed devices. BYOD and other supported access devices will still trigger these conditional access policies and require MFA or any other controls you have in place.   

 

Conclusion 

 

We see many customers using these technologies every day. Your organization is probably already benefiting from the security enhancements brought by these configurations without realizing it. Armed with this knowledge, we can start to tell users that from their corporate device, when they access company apps, services, or data, they won’t be asked for their password except in a limited set of circumstances. If a user isn’t using their password, the chances of it getting compromised are massively reduced.

 

Cyber security training has always placed the burden on the end user to ensure every time they enter their credentials, they are responsible for validating the site they’re using is genuine, checking the URL for anything suspicious, and confirming the site is secure with valid certificates, etc. If the user gets an MFA prompt, again, we place the responsibility on them to confirm this is an MFA they initiated.

 

We can start to make it simpler for our users. If the user ever sees a prompt for their credentials, STOP and report it! If they get an MFA prompt, they probably didn’t initiate it, so STOP and report it! This is easier than having to evaluate every attempt to sign in and every MFA.

 

This will increase our security posture. We’re reducing the possibility of a user falling for a phishing attack. Bring Intune, Autopilot, and Temporary Access Pass or FIDO2 keys into the mix, and a user can take their new company-issued laptop out of the box, get to their desktop, and start accessing corporate applications and data without ever knowing their password. Utopia.  

 

 

Tarek Dawoud 

Principal Program Manager, Product Management

Twitter: @cybertarek

 

 

Learn more about Microsoft identity: