Home / server / Questions / 1149107
Accepted
Joel Coel
Asked: 2023-12-05 01:38:57 +0800 CST

MS Entra users incorrectly marked as completing proofup and can't complete MFA setup

  • 772

I'm preparing to onbaord a new set of users for MFA authentication with Entra/AD FS, and running into some trouble (thankfully still during the testing phase!)

The environment is an on-premise AD/AD FS server (2019), synching to Entra with P1 to support MFA. This is working for most users. When users activate a new account they are redirected to the MS "ProofUp" process at mysignins.micrsoft.com/security-info per the documentation, and can finish the registration/authentication. It allows them to initially bypass the MFA requirement to reach the "mysignins.micrsoft.com/security-info" page until additional factors are provided, as it should.

However, we have a class of users now who come to us where they already have the Microsoft Authenticator app, and have already signed into the app with our "Work or School account", but have not yet actually finished registering the app for MFA with our Azure/Entra tenant. Notably, the app does NOT appear at all in the Authentication Methods section for the user in the Entra admin console. These are students (we are a university) who used the app to do MFA with an outside service from back before we required student MFA, and we now no longer use that service.

These users are NOT able to load the mysignins.micrsoft.com/security-inf ProofUp page, and instead enter a redirect loop where they continually end up back at our AD FS site saying they need to complete MFA registration.

AD FS MFA required screen shot

One key is at no point does the user ever see an actual error message. They just can't move past the AD FS page asking them to register MFA tokens. Anything they do to move forward will redirect them back to this point. Additionally, sign-in logs for these users in Entra will only show "Success" results unless they actual do enter a bad password, and even these are from before we turn on the MFA requirement for the user (or after we release them due to failure).

UPDATE:

I am now able to recreate this for a new test user on demand with these steps:

  1. Create a user in the local Active Directory
  2. Make sure the user is NOT yet required for MFA and let it sync to Azure AD/Entra
  3. Take a test mobile device that is NOT already registered with Entra
  4. Install the MS Authenticator app fresh on the device (completely remove it first and then re-install if it's already there so any local data for prior tests is cleared)
  5. Login to the Authenticator app as a work/school account with the user credentials created in step 1
  6. Close and quit the app.
  7. Set the user to require MFA for one of our AD FS Relying Parties (we do that here by adding a group membership in AD)
  8. Have the user try to access a protected app

The important thing was steps 5 and 6 happened before step 7.

AD FS will now correctly determine the user needs to complete MFA; it will show them a message per the documentation and then attempt to redirect them to the Entra ProofUp page after 5 seconds. But the proof-up page will not allow access and immediately redirect them back to AD FS to repeat the cycle. The user is prevented from completing the ProofUp process.

Using the "Require Re-register multifactor authentication" button shown below for the user in the admin console does not work to resolve this.

Entra partial screenshot showing button

So far, I have two ways I can move these users forward:

  1. Manually enter an additional factor for them (such as a cell phone). We'll soon be brining several hundred additional users onboard this way, where I don't necessarily have those cell phone numbers. I need something better.
  2. Change the access control policy for the Office 365 app specifically to not require MFA. This isn't as bad as it seems at first, because we use Google Workspace for email and most document services, but it's also obviously not good and not something I want to live with long term.

How can I clear the half-finished Authenticator app registration for these users, or otherwise allow them to move forward with MFA registration?

I can't be the first person to run into this, because it could happe to anyone who skips a step in the normal process and tries to add the Authenticator App too soon.

entra-id

2 Answers

  1. Navigate to Azure Active Directory > Users > All users > Choose the user you wish to perform an action on > select Authentication methods > Require Re-register MFA https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-userdevicesettings#next-steps

    Update: Here is a script also used by Microsoft support to analyze the adfs logs. Might be helpful https://github.com/CSS-Identity/ADFS-Diag/

    • 0
  2. Best Answer

    This is how we're going to work around this issue:

    I added an additional group to AD for managing MFA called MFA_ProofUpBypass. Then I created a new Access Control Policy in AD FS with three criteria:

    1. Permit everyone except from the MFA_Required group
    2. Permit users from the MFA_Required group and require multi-factor authentication except from the MFA_ProofUpBypass group
    3. Permit users from the MFA_ProofUpByPass group

    Access Control Policy image

    After successfully testing the policy, I applied it to our Micrsoft 365 relying party (and only this relying party) in AD FS.

    Now, as we add new users from this population (in batches of about 30/week, because we only have a two-person support team who also still need to handle regular requests, too), we will initially add users to both the MFA_Required and MFA_ProofUpBypass group at the same time.

    In this way, these users will be able to complete their MFA registration process, and existing MFA users won't lose account protection for the Microsoft 365 service.

    Then, as we know each batch has successfully completed registration we can remove them from the MFA_ProofUpBypass group, so they will also have MFA protection for the Microsoft 365 service.

    Going forward, as we have normal user churn and issues we can continue to use the MFA_ProofUpByass group to help support users for this kind of issue as well things like transferring to a new phone.

    I'd still like to fully solve this, but I'm out of time (sort of - we don't start till next term, but I need senior leadership to approve the migration plan this week before the holidays).

    • 0