Category Attribute Mapping

In this chapter, you learned how to evaluate passwordless sign-in options for your organization and deploy the ones that best suit your needs. Some passwordless options, such as Windows Hello or FIDO2 keys, may require specialized hardware such as cameras, USB devices, or fingerprint readers, while the Microsoft Authenticator app method requires only the Microsoft Authenticator app on any supported Android or iOS-based device.

You also learned about deploying features such as self-service password reset and Azure AD password protection to further reduce administrative overhead, helping your organization comply with security policies.

In the next chapter, you’ll learn about implementing secure access in the context of Microsoft 365.

Exam Readiness Drill – Chapter Review Questions Benchmark Score: 75%

Apart from a solid understanding of key concepts, being able to think quickly under time pressure is a skill that will help you ace your certification exam. That’s why, working on these skills early on in your learning journey is key.

Chapter review questions are designed to improve your test-taking skills progressively with each chapter you learn and review your understanding of key concepts in the chapter at the same time. You’ll find these at the end of each chapter.

Before You Proceed

You need to unlock these resources before you start using them. Unlocking takes less than 10 minutes, can be done from any device, and needs to be done only once. Head over to the start of Chapter 7, Managing Security Reports and Alerts by Using the Microsoft 365 Defender Portal in this book for instructions on how to unlock them.

To open the Chapter Review Questions for this chapter, click the following link:

https://packt.link/MS102E1_Ch05. Or, you can scan the following QR code:

Figure 5.34 – QR code that opens Chapter Review Questions for logged-in users

Once you login, you’ll see a page similar to what is shown in Figure 5.35:

Figure 5.35 – Chapter Review Questions for Chapter 5

Once ready, start the following practice drills, re-attempting the quiz multiple times:

Exam Readiness Drill
For the first 3 attempts, don’t worry about the time limit.

ATTEMPT 1
The first time, aim for at least 40%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix your learning gaps.

ATTEMPT 2
The second time, aim for at least 60%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix any remaining learning gaps.

ATTEMPT 3 The third time, aim for at least 75%. Once you score 75% or more, you start working on your timing.

Tip You may take more than 3 attempts to reach 75%. That’s okay. Just review the relevant sections in the chapter till you get there.

Working On Timing

Target: Your aim is to keep the score the same while trying to answer these questions as quickly as possible. Here’s an example of how your next attempts should look like:

Table 5.4 – Sample timing practice drills on the online platform

Note
The time limits shown in the above table are just examples. Set your own time limits with each attempt based on the time limit of the quiz on the website.

With each new attempt, your score should stay above 75% while your time taken to complete should decrease. Repeat as many attempts as you want till you feel confident dealing with the time pressure.

In addition to the core options for the methods and types of multifactor authentication, Azure AD also supports a number of settings, as given in Table 5.3, to further modify the behavior of multifactor authentication. These properties are located under Azure Active Directory | Security | Multi-Factor authentication in the Azure portal:

Table 5.3 – Additional multifactor authentication settings

Investigating and Resolving Authentication Issues

Resolving authentication issues in Azure AD can be tricky due to the number of authentication methods, sign-in methods, and other configurations that may be put in place.

The first step when attempting to troubleshoot an issue is to review any available sign-in logs in the Azure portal. To locate the sign-in logs, navigate to the Azure portal (https://portal.azure. com) and then select Azure Active Directory | Sign-in logs. See Figure 5.30:

Figure 5.30 – Sign-in logs

Each authentication failure generates an individual entry. You can select an entry to see expanded details, as shown in Figure 5.31:

Figure 5.31 – Activity details

The Basic info tab displays high-level information about this particular event. The critical piece of information will typically be listed next to Failure reason, and some expanded explanation may be available in the Additional Details property. In the example shown in Figure 5.31, the reason for the failure of authentication is that the user entered an incorrect password. If the user has entered an incorrect password multiple times in a row, it may be a sign of a forgotten password or an attempted identity breach. Figure 5.32 shows the same account after it has met the smart lockout threshold:

Figure 5.32 – Sign-in detail showing locked-out account

The Location tab will show detailed information regarding the source IP address, and, if possible, resolution to a particular geographic location.

The Device info tab displays information regarding the device that was attempting a logon, such as a Windows 10 device with the Edge browser.

Note
Other browsers can also provide device information or interact with the Microsoft 365 logon process if they have the Windows Accounts extension installed. For example, Chromium-based browsers can install the Windows Accounts extension from the Chrome Web store: https://chromewebstore.google.com/detail/windows-accounts/ ppnbnpeolgkicgegkbkbjmhlideopiji.

The Authentication Details tab, shown in Figure 5.33, provides additional information regarding the authentication method, including whether the user is configured for Password Hash Sync, Federation, or Pass-through Authentication, or whether they’re using a cloud-managed identity:

Figure 5.33 – Authentication details

Finally, the last two tabs, Conditional Access and Report-only, show what policies took effect during the sign-in process. You can review these tabs for the status of Conditional Access policies, showing either what was applied or would have been applied during the logon process and how any conditions were satisfied.

Resolving an authentication issue sometimes requires examining several logs to determine the source of the error. In many cases, however, the detailed data provided on each of the tabs of an event’s activity details should provide adequate information to pinpoint the source of the error.

To enable users to sign in with FIDO2 security keys, you need to configure the authentication policy. Configuring the policy requires an account with the Global Administrator or Authentication Administrator role:

1. Navigate to the Azure portal (https://portal.azure.com).
2. Select Azure Active Directory | Security | Authentication methods and then select Policies.
3. Select Microsoft Authenticator.
4. On the Enable and Target tab of the FIDO2 security key settings page, slide the Enable toggle to On. See Figure 5.18:

Figure 5.18 – Enabling Microsoft Authenticator

5. Using the Include and Exclude tabs, specify which users the policy settings will apply to. Select the All users radio button to include all users in the policy or choose the Select groups radio button to specify which groups will be included or excluded.
6. Click Save to update the policy configuration.

The next step is to instruct users to register the security keys.

Registering Devices

Like Microsoft Authenticator-based authentication, FIDO2 authentication requires end users to register the compatible device they wish to use for authentication.

Note
In order to register a FIDO2 security key, the user must already have an Azure AD multifactor authentication method configured. If they do not have one, they must add one (such as Microsoft Authenticator or SMS). If that is not possible, an administrator can issue a Temporary Access Pass (TAP) to allow the user to complete registration. For more information on configuring a TAP, please see https://learn.microsoft.com/en-us/azure/active-directory/ authentication/howto-authentication-temporary-access-pass.

To register a FIDO2 security key, users must follow these steps:

1. Navigate to https://myprofile.microsoft.com or, from the Microsoft 365 portal, expand the profile icon and select View account:

Figure 5.19 – Accessing My account

2. Click Security Info.
3. Select Add method and click Security key.
4. Select either USB device or NFC device.
5. Ensure the key is ready and click Next.
6. In the dialog box, create and enter a PIN for the security key and then perform the required gesture (biometric/touch) to confirm.
7. Enter a Name value for the key and click Next.
8. Click Done.

After the key has been registered, users can sign in to Azure AD, Entra ID, or Microsoft 365 using their security key. At the sign-in page, after entering a username, users can select the Use Windows Hello or a security key option, which will cause the browser to issue a prompt to insert the key, as shown in Figure 5.20:

Figure 5.20 – Sign in with Windows Hello or a security key

Next, you’ll look at configuring a self-service password reset.

Implementing and Managing Self-Service Password Reset

Self-service password reset (SSPR) is a feature that allows users to change or reset passwords without administrator or service desk involvement. Self-service passwords can be configured for Azure AD cloud-only environments as well as enabling SSPR of hybrid identity through the Azure AD Connect Password Writeback feature.

To enable users to sign in with Microsoft Authenticator, you need to configure the authentication policy. The authentication policy is shared across the tenant, though different authentication methods are scoped for groups of users.

Configuring and managing the policy requires an account with the Global Administrator or Authentication Administrator role:

1. Navigate to the Azure portal (https://portal.azure.com).

Exam Tip

While the current (as of this writing) version of the exam was developed before full parity of the Entra admin center was delivered, it’s important to understand that interim exam updates may include references to the Entra admin center (https://entra.microsoft.com). Things such as menu items or configuration options are located in slightly different locations (from the left-hand menu navigation perspective), though they render the current Azure portal information in the main content window.

2. Select Azure Active Directory | Security | Authentication methods and then select Policies, as shown in Figure 5.10:

Figure 5.10 – Authentication methods

3. Select Microsoft  Authenticator.

4.    On the Enable and Target tab of the Microsoft Authenticator settingspage, slide the Enable toggle to On, as shown in Figure 5.11:

Figure 5.11 – Enabling Microsoft Authenticator

5. Using the Include and Exclude tabs, specify which users the policy settings will apply to. Select the All users radio button to include all users in the policy or choose the Select groups radio button to specify which groups will be included or excluded. Each group can have a separate Authentication mode value selected, including Any (default), Passwordless, or Push. Choosing Push as the option prevents the use of the passwordless phone sign-in credential.

6. Click Save to update the policy configuration.

After configuring the policy, users will need to register any devices to be used for passwordless authentication.

Registering Devices

Before users can log in to the service using Microsoft Authenticator, they will need to register their devices. If they’ve already registered for multifactor authentication, nothing else needs to be done.

If a user who has not registered signs in to the Microsoft 365 portal, they are greeted with aMore information required dialog as part of the sign-in process, as shown in Figure 5.12:

Figure 5.12 – More information required

During the process, they are redirected to download the Microsoft  Authenticator app, as shown in

Figure 5.13:

Figure 5.13 – Keep your account secure page

After they click Next, they are prompted to launch the Microsoft Authenticator app and add an account. Following the directions on the mobile device, they should launch a camera window that allows them to take a picture of a unique QR code, linking their device to their account, as shown in Figure 5.14:

Figure 5.14 – Registering a device

Once the device has been linked, the enrollment process will ask the user to confirm a code between the registration screen and their Microsoft Authenticator app. After completing the challenge, users should be presented with a confirmation screen, similar to the one shown in Figure 5.15:

Figure 5.15 – Authenticator registration screen

The final step for the user for full passwordless sign-in from the Microsoft Authenticator app is to configure the device itself. In Microsoft Authenticator, the user can open the app and select Enable phone sign-in, as shown in Figure 5.16:

Figure 5.16 – Microsoft Authenticator Enable phone sign-in

This will start a process to configure the device for passwordless sign-in. After configuration, the user can choose to log in with an app instead, triggering the phone authentication notification on their device. See Figure 5.17:

Figure 5.17 – Launching passwordless sign-in

The user then completes the logon challenge in the Microsoft Authenticator app to finish logging in to Microsoft 365.

Configuring FIDO2

When setting up FIDO2 -based authentication, you’ll follow a similar process as with Microsoft Authenticator—updating the authentication policy to allow the method and then instructing users to self-register their security keys.

WHFB supports cloud-only, hybrid Azure AD, and on- premises deployments. The easiest method to deploy Windows Hello is in a cloud-only model since the Microsoft 365 organization is set up for it automatically. You’ll look at that scenario in this section.

During the out-of-box experience (OOBE), users are prompted for credentials. After providing an Azure AD credential, if the Intune enrollment policy has not been configured to block WHFB, the user will be prompted to enroll with their biometric data (such as a facial scan with a compatible camera) and set a PIN.

Devices will be joined to Azure AD during the initial sign-in process and WHFB will be enabled.

If your subscription supports it, Microsoft recommends creating a WHFB policy to configure settings for your organization:

1.Navigate to the Intune admin center (https://intune.microsoft.com or https://endpoint.microsoft.com).

2. Expand Devices and, under Device enrollment, select Enroll devices, as shown in Figure 5.7:

Figure 5.7 – Enroll devices

3. Select Windows enrollment and then choose Windows Hello for Business, as shown in Figure 5.8:

Figure 5.8 – Windows Hello for Business

4. Under Assigned to, select a group (if scoping the enrollment policy to a subset of users).

5. Configure the options for Windows Hello for Business (italics options are the default settings for the enrollment policy):

• Configure Windows Hello for Business: Enabled, Disabled, Not Configured

• Use a Trusted Platform Module (TPM): Required, Preferred

• Minimum PIN length: Configure a numeric value between 4 and 127.

• Maximum PIN length: Configure a numeric value between 4 and 127.

• Lowercase letters in PIN: Not allowed, Allowed, Required

• Uppercase letters in PIN: Not allowed, Allowed, Required

• Special characters in PIN: Not allowed, Allowed, Required

• PIN expiration (days): Never, a numeric value between 1 and 730

• Remember PIN history: Never, a numeric value between 1 and 50

• Allow biometric authentication: Yes, No

• Use enhanced anti-spoofing, when available: Not configured, Yes, No

• Allow phone sign-in: Yes, No

• Use security keys for sign-in: Not configured, Enabled, Disabled

6. Click Save to update the enrollment policy.

With the policy configured, new device enrollments (for the configured user group) will receive the Windows Hello for Business setup prompt to begin enrollment, as shown in Figure 5.9:

Figure 5.9 – Windows Hello for Business enrollment

After completing enrollment, users will be able to unlock and log in to devices using supported biometrics or their PIN.

Users that are already connected to Azure AD can also trigger the Windows Hello setup wizard, by either navigating to the Account protection blade in the Windows Settings app or by pressing Win+R and entering ms-cxh://nthaad in the Run dialog box.

Next, you’ll look at configuring Microsoft  Authenticator for passwordless sign-in.

Configuring Microsoft Authenticator

The Microsoft Authenticator app provides a convenient way to sign in to any Azure AD account with a supported mobile device. Before users can sign in using the method, however, it will need to be enabled in your tenant through the authentication policy.

Physical tokens, such as the Fast Identity Online 2 (FIDO2)-based token or security key, are another passwordless option that can be used. While the Microsoft Authenticator app is a soft token, FIDO2 tokens are physical pieces of hardware that are typically either connected to the computer (in the form of a USB device) or that communicate wirelessly (via Bluetooth or NFC).

You can access the security key logon process during a browser session by selecting the Sign in with

Windows Hello or a security key option from the sign-in page, as shown in Figure 5.5:

Figure 5.5 – Passwordless authentication dialog with a FIDO2 security token

The data flow for a FIDO2-based logon follows a similar pattern as both WHFB and the Microsoft Authenticator app. For example, to log in to a device using FIDO2, this process outlined in Figure 5.6 is followed:

Figure 5.6 – FIDO2 authentication sequence

1. The user plugs in a FIDO2 security key.
2. Windows detects the security key.
3. Windows sends an authentication request to Azure AD.
4. Azure AD responds by sending a nonce back to the logon device.
5. The user authenticates to the FIDO2 key, unlocking the secure storage area containing the private key.
6. The FIDO2 key signs the nonce with the private key and sends it to Windows.
7. Windows generates a PRT request and sends it with the signed nonce to Azure AD.
8. Azure AD verifies the signed nonce with the FIDO2 device’s public key.
9. Azure AD returns the PRT to the logon device.

FIDO2, like Windows Hello, has specific requirements for supported hardware.

Supported FIDO2 Security Tokens

You can see an up-to-date list of supported FIDO2 security keys or tokens here: https:// learn.microsoft.com/en-us/azure/active-directory/authentication/ concept-authentication-passwordless#fido2-security-key-providers.

As you’ve seen from the diagrams, each of the passwordless options (Windows Hello, Microsoft Authenticator App, and FIDO2) follows a similar authentication workflow, based on public key infrastructure.

Comparison

Now that you have explored the different passwordless options available for Microsoft 365, let’s look at some information that will help you choose the appropriate solution. Table 5.1 describes some basic features and requirements for each authentication scheme.

Table 5.1 – Authentication method comparison table

It’s also important to consider the various end user scenarios that your organization utilizes to ensure you’re recommending an appropriate mechanism based on your real-world use cases. Table 5.2 describes a few example scenarios:

Table 5.2 – Passwordless logon scenarios

With that information in hand, it’s time to look at the implementation aspects.

After onboarding identity and configuring multifactor authentication requirements, you can begin deployment.

Exam Note

Full deployment and configuration of these methods are outside the scope of the MS-102 exam, but it would be good to spend a little bit of time reviewing the product documentation for deeper dives into how passwordless authentication works. See https://learn.microsoft. com/en-us/entra/identity/authentication/concept-authentication-passwordless for further information.

Let’s go through an overview of the configurations necessary to enable passwordless authentication methods.

Choosing an Authentication Mechanism

Everyone is familiar with using an identity and a corresponding password to log in to a device, service, application, or website—whether it’s a bank website, Facebook, Xbox Live, or even just a local computer. While Microsoft 365 supports traditional username and password authentication mechanisms, there are newer methods that provide fewer opportunities for malicious users to compromise identities, applications, and devices.

Microsoft has long advocated for using multifactor authentication as part of the logon process to help secure identities—that is, using some sort of supplementary logon tool (such as a token, authenticator app, phone call, or text message) to confirm the logon process. The weakest link in this chain is the password—and interfaces unable to leverage the multifactor authentication process are more susceptible to bad actors.

With Microsoft’s newest passwordless technologies, users get the advantage of multifactor authentication (something you have, something you know, or something you are) without the frustration of remembering complex passwords. Microsoft supports several different approaches to passwordless logon, including Windows Hello for Business (WHFB), the Microsoft Authenticator app, and Fast Identity Online 2 (FIDO2)-compatible security keys or tokens.

Microsoft passwordless options are based on apublic key infrastructure (PKI) design, comprising a private key (managed and stored by the user’s device) and a public key saved in Azure AD. The keys are linked and only work with each other. When an entity (be it a user or device) establishes a public/ private key pair, the public key can be broadly distributed to all other entities that the owner of the key pair wishes to communicate with.

Each key has two purposes:

• The public key is used to encrypt data. Only the corresponding private key can decrypt it.

• The private key is used to sign data. Only the corresponding public key can authenticate or verify the signature, offering proof that a particular private key produced it.

For example, let’s say you establish a public/private key pair and you wish to conduct secure email communication. You distribute the public key to everyone you will communicate with. You might even add it to your email signature, post it on a blog, or store it in a directory where others can look it up.

The following examples demonstrate possible uses for public key cryptography in the context of email:

• You’re sending out an important product announcement update on behalf of your organization and you want people to be certain it’s authentic. You sign the email with your private key. Recipients who already have your public key (or who can retrieve it from your website or a directory) can use the public key to check the signature on your email. Since only your private key matches that well-known public key, recipients can be assured that your private key was used to sign the content.

• You’re in the process of acquiring financing for a new business venture. The lender has prepared documents for you to review. Since they contain sensitive financial information, the lender wants to make sure that only you can open them. They encrypt the content with your public key and email you the documents. Since only your private key is able to decrypt the content, both entities can be assured that the content will be unreadable to anyone else.

Those types of scenarios are very analogous to what happens when using PKI-based sign-on methods such as Windows Hello—but instead of signing and encrypting email, it’s used for authentication data.

In this section, you’ll explore a little bit about each of these mechanisms to help you decide which is appropriate for your organization.

Another way to prevent objects from being synchronized to Azure AD is using an attribute filter. This advanced method requires creating a custom synchronization rule in the Azure AD Connect Synchronization Rules Editor.

To create an attribute-based filtering rule, select an attribute that isn’t currently being used by your organization for another purpose. You can use this attribute as a scoping filter to exclude objects. The following procedure can be used to create a simple filtering rule:

1.On the server running Azure AD Connect, launch the Synchronization Rules Editor.

2. Under Direction, select Inbound and then click Add new rule. See Figure 4.11:

Figure 4.11 – Synchronization rules editor

3. Provide a name and description for the rule.

4. Under Connected System, select the object that represents your on-premises Active Directory forest.

5. Under Connected System Object Type, select user.

6. Under Metaverse Object Type, select person.

7. Under Link Type, select Join.

8. In the Precedence text field, enter an unused number (such as 50) , as shown in Figure 4.12. Click Next.

Figure 4.12 – Creating a new inbound synchronization rule

9. On the Scoping filter page, click Add group and then click Add clause.

10. Under Attribute, select extensionAttribute1 (or whichever unused attribute you have selected).

11. Under Operator, select EQUAL.

12. In the Value text field, enter NOSYNC, as shown in Figure 4.13 and then click Next.

Figure 4.13 – Configuring a scoping filter for extensionAttribute1

13. On the Join rules page, click Next without adding any parameters.

14. On the Transformations page, click Add transformation.

15. Under FlowType, select Constant.

16. Under Target Attribute, select cloudFiltered.

17. In the Source text field, enter the value True. Click Add.

Figure 4.14 – Adding a transformation for the cloudFiltered attribute

18. Acknowledge the warning that a full import and synchronization cycle will be required by clicking OK. See Figure 4.15:

Figure 4.15 – Warning for full import and synchronization

After modifying the synchronization rule, a full import and full synchronization is required. You don’t have to perform any special steps, however; Azure AD Connect is aware of the update and will automatically perform the necessary full imports and synchronizations.

Monitoring Synchronization by Using Azure AD Connect Health

Azure AD Connect Health is a premium feature of the Azure AD license. Azure AD Connect Health has separate agent features for Azure AD Connect, Azure AD Health for Directory Services (DS), and Azure AD Health for AD FS.

In this chapter, you learned how to deploy identity synchronization and authentication solutions. You learned how to configure filtering for both Azure AD Connect and Azure AD Connect Cloud Sync, as well as deploying and managing the health agents for diagnostic and troubleshooting.

The next chapter will discuss methods to manage authentication.

Exam Readiness Drill – Chapter Review Questions

Benchmark Score: 75%

Apart from a solid understanding of key concepts, being able to think quickly under time pressure is a skill that will help you ace your certification exam. That’s why, working on these skills early on in your learning journey is key.

Chapter review questions are designed to improve your test-taking skills progressively with each chapter you learn and review your understanding of key concepts in the chapter at the same time. You’ll find these at the end of each chapter.

Before You Proceed

You need to unlock these resources before you start using them. Unlocking takes less than 10 minutes, can be done from any device, and needs to be done only once. Head over to thestart of Chapter 7, Managing Security Reports and Alerts by Using the Microsoft 365 Defender Portal in this book for instructions on how to unlock them.

To open the Chapter Review Questions for this chapter, click the following link:

https://packt.link/MS102E1_CH04. Or, you can scan the following QR code:

Figure 4.35 – QR code that opens Chapter Review Questions for logged-in users

Once you login, you’ll see a page similar to what is shown in Figure 4.36:

Figure 4.36 – Chapter Review Questions for Chapter 4

Once ready, start the following practice drills, re-attempting the quiz multiple times:

Exam Readiness Drill

For the first 3 attempts, don’t worry about the time limit.

ATTEMPT 1

The first time, aim for at least 40%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix your learning gaps.

ATTEMPT 2

The second time, aim for at least 60%. Look at the answers you got wrong and read the relevant sections in the chapter again to fix any remaining learning gaps.

ATTEMPT 3

The third time, aim for at least 75%. Once you score 75% or more, you start working on your timing.

Tip

You may take more than 3 attempts to reach 75%. That’s okay. Just review the relevant sections in the chapter till you get there.

Working On Timing

Target: Your aim is to keep the score the same while trying to answer these questions as quickly as possible. Here’s an example of how your next attempts should look like:

Table 4.4 – Sample timing practice drills on the online platform

Note

The time limits shown in the above table are just examples. Set your own time limits with each attempt based on the time limit of the quiz on the website.

With each new attempt, your score should stay above 75% while your time taken to complete should decrease. Repeat as many attempts as you want till you feel confident dealing with the time pressure.

Microsoft’s recommended solution for passwordless authentication is Windows Hello for Business (WHFB). It’s designed for users that have their own dedicated PC. When logging on, the user presents a biometric or PIN code to unlock the device.

WHFB supports a variety of biometric logons, including facial recognition and fingerprint scanners. Devices configured to use Windows Hello (such as the one shown in Figure 5.1) can be recognized because they have the Windows Hello smiley face greeting at the top:

Figure 5.1 – Windows Hello for Business sign-on screen

After configuring Windows Hello, the sign-in flow follows this sequence, as depicted in Figure 5.2:

Figure 5.2 – Windows Hello authentication sequence

1. The user signs in with either a biometric or PIN (if the configured biometric input can’t be accessed), which unlocks the WHFB private key. The key is then passed to the Cloud Authentication security support provider, also known as the Cloud AP, part of the on-device security package.

2. The Cloud AP requests a nonce (single-use random number) from Azure AD.

3. Azure AD sends the nonce to the Cloud AP on the endpoint.

4. The Cloud AP signs the nonce with the user’s private key and returns the signed nonce to Azure AD.

5. Azure AD decrypts and validates the signed nonce with the user’s public key. After it’s validated, Azure AD issues a primary refresh token (PRT) with the session key, encrypts it using the device’s public transport key, and sends that to the Cloud AP.

6. The Cloud AP decrypts the PRT/session key using the device’s transport private key and then uses the Trusted Platform Module (TPM) to store the session key.

7. The Cloud AP returns a success response to Windows, allowing the user to log in to complete.

WHFB is available to be deployed as a cloud-only or hybrid identity solution and can be used for both Windows logon as well as logon to Microsoft 365 services. Windows Hello-based authentication is tied to a unique device, meaning you have to set it up individually for each device that you will be using.

Microsoft Authenticator App

Many administrators and users are already familiar with the Microsoft Authenticator mobile device app, after using it for multifactor authentication. The Authenticator app can also be used as a passwordless sign-in option. When used as a passwordless option, Microsoft Authenticator can use number-matching, where the sign-in screen displays a number that the user enters and confirms with their PIN or biometric data. See Figure 5.3:

Figure 5.3 – Passwordless authentication dialog with Microsoft Authenticator

The data flow using the Authenticator app follows the same general pattern as Windows Hello, as shown in Figure 5.4:

Figure 5.4 – Microsoft Authenticator authentication sequence

1.The user enters their username on the device.

2. Azure AD detects that the user is configured for passwordless authentication.

3. Azure AD sends a notification to the Authenticator app on the user’s configured Apple or Android device.

4. The user launches the Authenticator app.

5. The Authenticator app connects to Azure AD and receives the proof-of-presence challenge and the nonce.

6. The user completes the challenge on their mobile device and then confirms their identity with biometric data or a PIN, unlocking the private key.

7. The private key is used to sign the nonce and the Authenticator app returns the data to Azure AD.

8. Azure AD decrypts the data with the user’s public key, performs validation, and then returns the sign-in token to the original device where the logon was started.

Whereas WHFB has specific hardware requirements (such as a Windows Hello-compatible camera or fingerprint reader), passwordless using Microsoft Authenticator has a very low barrier to entry. The Authenticator app is free for iOS and Android devices and works not only with Microsoft 365 services but also any service that supports a soft-token app or device.

Further Reading

In addition to the traditional Microsoft Authenticator application, Microsoft has also released Authenticator Lite as part of Outlook. For more information, see https://learn. microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-authenticator-lite.