In today’s post, I’m sharing how I tackled the “Can You Configure Multifactor Authentication and Self-service in Microsoft Entra ID?” challenge lab. This advanced-level 45-minute lab gave me hands-on experience with setting up and managing MFA and Self-Service Password Reset (SSPR) in a secure and scalable way. I’m not just documenting steps—I’m explaining why each step matters, what could go wrong, and how these features strengthen security in real-world scenarios.

What Is This Lab About?

The lab revolves around two critical security features:

  • Multifactor Authentication (MFA): Adding an extra layer of security by requiring users to confirm their identity using a second factor (like SMS) in addition to their password.
  • Self-Service Password Reset (SSPR): Allowing users to reset their own passwords using verified methods like security questions, reducing helpdesk dependency.

I learned how to configure these settings using Microsoft Entra ID (Azure AD), ensuring that only authorized users can access sensitive information, while giving them tools to manage their own access securely.

Why Do We Need These Features?

With remote work and bring-your-own-device (BYOD) policies becoming widespread, the risk of unauthorized access and password fatigue is higher than ever. MFA helps prevent identity theft and reduces the risk of compromised accounts. SSPR reduces administrative overhead by empowering users to recover or reset credentials without direct IT intervention.

However, these features come with risks if misconfigured:

  • Granting excessive access or enabling MFA incorrectly could lock users out or expose systems.
  • Overly permissive SSPR settings could let attackers reset passwords using easily guessable information.
  • If audit logs aren’t reviewed, suspicious activity might go unnoticed.

How I Completed the Lab – The Process Step by Step

Step 1 – Setting Up Users for Testing

  1. Created Six Users (Student01 to Student06)
    Each user had specific properties like job title and department. For instance:

  • Student01 – Sales Associate in Sales
  • Student02 to Student06 – IT Admins in IT
Passwords were set to InitialPwd!-5182989 and the auto-generate password option was disabled.

Why this matters: Creating controlled test accounts allowed me to safely experiment without affecting real users. In production, mistakes like auto-generating insecure passwords or mislabeling job roles could compromise access controls.

Proceed with the same process for other users' creation as shown in the pictures.

Step 2 – Configuring MFA for the MFAUsers Group

Once users were ready, I set up MFA to ensure secure access.

  1. Created MFAUsers Group

    • Group type: Security
    • Membership: Assigned

    • Added Student01 and Student02 to this group.


  • Enabled Authentication Methods
I enabled SMS authentication as the fallback method by going to "Authentication methods" on the Azure portal and choosing SMS in Policies. Choose "Enable" toggle on and select groups then choose the group name.

  • Set Up Per-user MFA for Student03
In the portal, I enabled MFA for Student03, allowing them to remember MFA on trusted devices for 90 days by going to Multifactor Authentication page on Azure then going to "Per-user multifactor authentication" and choosing student03. For remembering MFA on trusted devices go to "User MFA settings" and on the end check the box for enabling remembering MFA on trusted devices and on the input box write 90 as per requirement.


  1. Completed MFA Registration for Student03
    Signed in using an incognito window after entering the password it shows to add authentication methods where we have to choose "I want to set up a different method" and registered phone-based authentication via text messages.

  2. Reviewed Audit Logs
    After configuring MFA, I checked the audit logs to confirm that the changes were recorded. This ensures transparency and traceability.

  1. Enabled MFA Registration Policy for MFAUsers
    Applied a policy that would enforce MFA registration for users in the group, allowing them 14 days to complete the process. On the "Multifactor authentication registration policy" page toggle enabled then on the include tab choose to select individual and groups and choose "MFAUsers" group.


  2. Tested the Policy with Student01
    As Student01 is in MFAUsers group so I signed in as student01 and confirmed that the prompt to register for MFA appeared but could be skipped for 14 days.

Why this matters: MFA protects against password theft, but if not enforced or monitored properly, users might delay adoption or leave accounts vulnerable. Audit logs ensure that suspicious or unauthorized changes are traceable.

Step 3 – Configuring SSPR for the SSPRUsers Group

Next, I set up password recovery tools to make user support more efficient.

  1. Created SSPRUsers Group
    Added Student04 and Student05 to this group.

  2. Defined Authentication Methods

    • Required 1 method: Security questions. Go to the Azure password reset page then go to "Authentication Methods" and choose "Security questions".
    • Registered with 5 questions; users must answer 3 to reset their password. On te Select security questions page click on predefined and choose 5 security questions to proceed.

  • Enabled Password Reset Policies
    • Set policies to require users to register at sign-on and reconfirm every 90 days. On the Entra admin page go to "Password reset" page and on the "Properties" tab click on selected to choose the SSPRUsers group on select users and then click on save. For the "Require users to register when signing in?" go to "Registration" tab on the manage page and choose Require users to register when signing in? to yes and set Number of days before users are asked to re-confirm their authentication information to 90.

  1. Tested SSPR with Student06 (Negative Test)
    Attempted password reset as Student06, who wasn’t in the group, and confirmed that access was denied.

  2. Registered Student04’s SSPR Details
    Signed in, updated the password, and set answers to security questions.

  3. Tested Password Reset for Student04
    Successfully reset the password using the configured questions.

  4. Verified Audit Logs
    Checked logs to confirm that the password reset action was recorded and retrieved details like the user principal name and new value.

Why this matters: SSPR reduces helpdesk load but requires strict access controls. Allowing all users to reset passwords without proper validation could open doors for attackers. Monitoring logs ensures suspicious activity doesn’t go unnoticed.

What If Something Goes Wrong?

Throughout the lab, I kept thinking about potential pitfalls:

  • Misconfigured MFA: A wrong setting could prevent users from accessing their accounts, causing operational downtime.

  • Over-assigned groups: Adding users to sensitive groups like MFAUsers without proper vetting could expose accounts.

  • Weak security questions: Using easily guessable answers could allow unauthorized resets.

  • Neglected audit logs: Without monitoring, attackers could exploit gaps without detection.

To mitigate these risks, I recommend:

  • Always verifying user details before assignment.

  • Enforcing least privilege policies.

  • Reviewing logs regularly and setting alerts for suspicious activities.

  • Educating users on secure practices and updating configurations as needed.

Final Thoughts

This lab wasn’t about blindly clicking through a setup wizard—it’s about understanding how identity protection works in the cloud. I now have hands-on experience with configuring MFA and SSPR, including what features to use, why they matter, and how to troubleshoot them. I’m confident this knowledge applies beyond labs, especially in real-world environments where mistakes can lead to security breaches.

If you’re learning or managing identities in the cloud, start with these tools—they form the backbone of secure access management. Stay curious, stay secure! 🚀