Choosing an authentication mechanism– Planning and Implementing Authentication

Over the course of the last few chapters, you’ve learned a lot about identity, synchronization, and sign-in methods – all part of the Microsoft 365 foundation. In this chapter, we’ll shift gears from how you configure the service for a sign-in method to how you implement authentication on the user-facing side.

We’re going to tackle authentication mechanisms and methods by covering the following topics:

• Choosing an authentication mechanism
• Configuring and managing multi-factor authentication
• Implementing and managing authentication methods
• Implementing and managing self-service password reset
• Implementing and managing Azure AD password protection
• Investigating and resolving authentication issues

By the end of this chapter, you should be able to describe the various authentication methods and supporting tools, as well as have an understanding of where to go to troubleshoot authentication issues.

Let’s go!

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. 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 multi-factor authentication (MFA) as part of the login process to help secure identities – that is, using some sort of supplementary login tool (such as a token, authenticator app, phone call, or text message) to confirm the login process. The weakest link in this chain is the password; interfaces unable to leverage the MFA process are more susceptible to bad actors.

With Microsoft’s newest password-less technologies, users get the advantage of MFA (something you have, something you know) without the frustration of remembering complex passwords. Microsoft supports several different approaches to password-less login, including Windows Hello for Business (WHFB), the Microsoft Authenticator app, and FIDO2-compatible security keys or tokens.

Microsoft password-less options are based on a public key infrastructure (PKI) design, comprised of 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 who 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 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, we’ll explore a little bit about each of these mechanisms to help you decide which is appropriate for your organization.