A zero-disruption path to better MFA

The clue is in the name; multifactor authentication. It always meant using a range of different methods to assert an identity but we typically treated it as a homogeneous security control, with “require MFA” a single checkbox on many systems. The shortcomings of this approach have been apparent in recent years as attacks have surfaced that specifically target weaker methods. Microsoft’s response to this is authentication strengths, a feature of Conditional Access that allows organisations to customise the methods they accept.

While this is certainly progress, it poses a problem since if we start requiring more secure methods before everyone has one, we risk locking out legitimate users. I have previously outlined the problems with this all-or-nothing approach, primarily that it discourages the application of more secure methods on a widespread basis in large organisations with a range of legacy methods in use because of the potential disruption that could be caused.

A possible workaround?

I’m a member of the Microsoft Conditional Access group on Linkedin which is a great resource for Identity professionals. A few days ago Dominik Gilgen published an Azure Runbook on Github that uses a bit of simple logic to create dynamic groups based on the MFA status of the user (one group for users that have a certain method and another for those that don’t). My first thought was that the man is a genius as this could be the key to my MFA problems.

Initial Registration

Consider the following process where we need to register MFA for a new user:

• A user is allocated a Microsoft account prior to their first day in the office and they need to log in from a personal device at a remote location (this is commonplace in education where teachers generally start working in advance of the beginning of the school year).
• User does not have existing MFA, so they are caught by the registration campaign and directed to sign up.
• The Conditional Access policy which restricts security changes and MFA registrations to known locations or trusted devices (a security best practice) blocks their attempt and prevents login.

The standard workaround for this scenario is that we communicate a Temporary Access Password for MFA-specific setup. The TAP is in addition to the user’s standard password but qualifies as an MFA method for setting up the MS Authenticator app.

A slightly-modified version of Dominik’s script could eliminate this hassle by creating a dynamic group of all users who are non-MSAuthenticator capable. This group could then be set as an exception to the restrict security changes CA policy. New users with no existing methods registered would not be prevented from registering their Authenticator app, while users with existing registrations would remain protected. Each time the script runs, any users that have registered a method since last run would move to the capable group.

Alternative: employeeHireDate

I had a great suggestion from Microsoft’s Merill Fernando to use a preview feature in dynamic groups to create a group containing only recent hires. This is based on a comparison of the current date and the employeeHireDate field in Entra ID. In my tenant I used the following rule syntax to make a group containing new staff within the last month:

(user.employeeHireDate -ge system.now -minus p30d)

Applying this group as an exception to the Conditional Access policy is a simpler way of achieving the same result, however it is less secure in that the exception is time-based rather than being removed once the user has registered a method. It also depends on having an accurate employeeHireDate entry for each member of staff.

Modifying an existing policy

Consider the scenario where we have a policy that currently requires only standard MFA but we raise the bar to the phish-resistant / FIDO2 level:

• A user who does not have a FIDO2 MFA method registered is caught by the CA policy that now requires it.
• An exception is specified in the policy for the ’non-FIDO2 capable’ group and the script has already added this user.
• User is permitted access to the resource.

While this is sufficient to avoid non-capable users from being blocked, it’s not a long-term solution by itself as it would permit indefinite circumvention of the policy. I had some ideas on how to fix this but subsequent to my initial posting of this blog, Dominik contacted me with a better one. He has made a script for group cleanup which removes users added to groups after a defined period of time. Adding this into the mix, users would only need to be added to the exceptions for a limited period. Combining this with a Power Automate trigger to generate a notification on group addition / removal, we have a much more complete solution.

Concerns and limitations

Membership of the non-capable group could pose a security risk if access were not strictly controlled since an attacker could remove their MFA requirements by adding themselves to the group. Access Reviews could be used to prompt a routine check of the non-capable group members to determine whether their presence is expected or not.

Managing capabilities globally isn’t helpful for governing access to a single Conditional Access policy or set of policies. We can’t see who was specifically excluded on a policy level and we don’t have the ability to manage remediation for a subset of our users.

Ultimately this workaround would be best restricted to an interim stage where an organisation is working toward having more secure authentication methods in use universally and wants to be able to gain the security benefits of them without having to wait until every last user is covered.

I’m still interested to hear suggestions or pointers in work around this area, as I believe it is one of the key challenges in enterprise security at the minute.

Comments