Implementing and Managing Authentication Methods– Implementing and Managing Authentication

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.