Azure and MFA Secrets

Comments 0

Share to social media

MFA and conditional access policies are powerful tools for our cloud security, but they are full of tricks.

I don’t pretend to cover the basics here. You know you can create conditional access policies to request MFA authentication from the users. You also know the fact the default configuration (which you should avoid) will request MFA from everyone.

However, for the user to fulfill the requirement, the user needs to be registered for the MFA. There are some different ways to control the user registration for MFA.

It’s recommended to ensure the registration of the users for MFA before the conditional access policies jumps in and start requesting MFA from the users.

Direct Registration Requirement

On Active Directory -> Security -> Identity Protection -> MFA Registration Policy you can define the users who will be required to register a 2nd authentication method for MFA.

MFA give the  user 14 days for the registration before making it required. However, this will be a registrations of a single alternate method which by default is the Authenticator App.

The user has the option to choose a different method instead of the authenticator app, but not many users do so. A request for a new registration will never appear for the user again, or that’s what most people believe.

Self-Service Password Reset

It’s undeniable that SSPR is a very interesting feature, but what’s its relation to MFA registration?

SSPR requires MFA authentication methods. You can check the authentication methods required by SSPR on Active Directory -> Password Reset -> Authentication Methods

The enabled authenticator methods don’t includ the authenticator app  by default. You can include it, but it’s not by default.

On the item below, Active Directory -> Password Reset -> Registration the default configuration is to require every user registered for SSPR to register an MFA method on their next login and by default will be a different one than the default Authenticator App.

This becomes the second option the user has to register a secondary MFA method.

The Problem

It’s not very good the idea to depend on SSPR for the registration of a secondary MFA method. What happens if the user is in the middle of a trip and don’t have access to the main MFA methods registered? How could the user authenticate with alternate methods?

It’s not a good idea to have a single MFA method registered, how could you configure additional ones?

The Solution

There are two addresses the user can access directly to register additional MFA methods:

 

Conclusion

It may be a good idea for the IT team to make these addresses available to the users so they can control their own MFA registration methods and ensure that, when in trouble, they still have alternate options to authenticate on the systems.

About the author

Dennes Torres

See Profile

Dennes Torres is a Data Platform MVP and Software Architect living in Malta who loves SQL Server and software development and has more than 20 years of experience. Dennes can improve Data Platform Architectures and transform data in knowledge. He moved to Malta after more than 10 years leading devSQL PASS Chapter in Rio de Janeiro and now is a member of the leadership team of MMDPUG PASS Chapter in Malta organizing meetings, events, and webcasts about SQL Server. He is an MCT, MCSE in Data Platforms and BI, with more titles in software development. You can get in touch on his blog https://dennestorres.com or at his work https://dtowersoftware.com

Dennes's contributions