Configure IAM Security Controls in Entra ID

Set up RBAC, MFA, and SAML SSO in Microsoft Entra ID.

Introduction

30 Second Summary

Think about how a building uses keycards to control who can enter which floors. Some employees can only access the lobby, while security staff can reach every room. Digital systems need the same layered protection for the people who use them.

In this project, you will configure three identity security controls in Microsoft Entra ID: role-based access control to limit permissions by job function, multi-factor authentication on privileged accounts, and SAML-based single sign-on for application access.

What You'll Build

You will layer identity access security controls onto an existing Entra ID environment, giving your simulated company a complete security posture with scoped roles, enforced MFA, and enterprise application SSO.

By the end of this project, you'll have:

Two scoped RBAC role assignments enforcing the principle of least privilege across your directory.
Per-user MFA enabled on privileged accounts, demonstrating the MFA state lifecycle from Disabled to Enabled to Enforced.
A SAML-based SSO enterprise application with a successful end-to-end sign-on test.
Secret Mission: Restrict a second enterprise application to a specific security group to prove that group membership enforces access boundaries.

Are there any prerequisites?

Yes. This project builds directly on the Entra ID environment you created in the "Manage Identity Lifecycle in Entra ID" project. You need the existing tenant with its 5 users, 3 administrative units, and 4 security groups already in place before starting.

Before We Start

In the previous project, you built a Microsoft Entra ID environment with users, security groups, and administrative units. Now it's time to add the security layer that protects those identities.

Before configuring RBAC roles, MFA, and SSO, you need to verify your existing resources are intact and disable a default setting that would block granular MFA control.

In this step, get ready to:

Verify existing users, groups, and administrative units in the Entra admin center.
Disable Security Defaults to unblock per-user MFA configuration.
Confirm the change took effect and user management still works.

Sign in and verify your existing users

Your Entra ID tenant already has the users, groups, and administrative units you created in the previous project. You need to confirm everything is still in place before adding security controls on top.

Open your browser and navigate to entra.microsoft.com.
Sign in with your Global Administrator account.
In the left navigation, expand Identity, then select Users, then All users.
Verify that all five users are present: Alex Kim, Jordan Patel, Sam Rivera, Taylor Brooks, and Casey Morgan (showing as disabled).
Select Taylor Brooks and confirm her job title shows Technical Project Manager.
Navigate back to All users.

Why verify before adding security controls?

The security controls you configure in this project (role assignments, MFA, SSO) depend on specific users and groups existing. If anything was accidentally deleted or modified since the last project, catching it now prevents confusing errors later.

Disable Security Defaults

Security Defaults is a tenant-wide setting that forces MFA for all users with no granularity. You need to disable it so you can selectively enable per-user MFA on only the privileged accounts.

In the left navigation, select Identity, then Overview.
Select the Properties tab.
Scroll down and select Manage security defaults.
In the Security defaults dropdown, select Disabled.
In the Reason for disabling section, select My organization is planning to use Conditional Access.
Click Save.

Why disable Security Defaults?

Security Defaults and per-user MFA conflict with each other. Security Defaults enforce MFA for everyone in the tenant with no exceptions. Per-user MFA lets you choose exactly which accounts require it.

For this project, you want to demonstrate risk-based MFA application by enabling MFA only on privileged accounts. Disabling Security Defaults is the required first step to unlock that granular control on the free tier.

Save button greyed out?

Make sure you are signed in with Global Administrator permissions. The Conditional Access Administrator role is the minimum required to change this setting. If the button is still greyed out, check that no existing Conditional Access policies are blocking the change.

help me figure out why the Save button is greyed out when I try to disable Security Defaults

Verify the change took effect

After saving, confirm the Security defaults status now shows Disabled.
Navigate back to Identity > Users > All users to confirm you can still access user management.

You should see all five users listed just as before. The only change is that your tenant no longer enforces MFA on every account by default.

Your environment is verified and Security Defaults are out of the way. Next up, you will assign directory roles to specific users following the principle of least privilege.

Implement RBAC with Least Privilege

Your environment is prepped and Security Defaults are out of the way. Now it's time to assign directory roles that control what each user can actually do.

In a real organization, not everyone needs the same level of access. A project manager might need to manage users in her own department, while a compliance analyst only needs to read security reports. Role-Based Access Control (RBAC) solves this by assigning permissions based on job function. In this step, you'll assign two scoped roles that demonstrate the principle of least privilege: each user gets only the permissions their role requires.

In this step, get ready to:

Assign the User Administrator role to Taylor Brooks, scoped to the AU-Engineering administrative unit.
Assign the Security Reader role to Sam Rivera at tenant (directory) scope.
Verify both assignments and confirm least privilege is in place.

Assign User Administrator to Taylor Brooks (scoped to AU-Engineering)

Taylor Brooks is a Technical Project Manager in the Engineering department. She needs the ability to manage users within her unit, but she should not be able to touch users in Finance or Marketing.

By scoping her role to the AU-Engineering administrative unit, you limit her permissions to only the users inside that boundary.

In the Microsoft Entra admin center, navigate to Identity in the left navigation.
Expand Roles & admins and select Admin units.
Select AU-Engineering from the list.
In the left navigation for AU-Engineering, select Roles and administrators.
Click the User Administrator role name (do not check the box next to it, click the name itself).
Click Add assignments.
Search for Taylor Brooks and select her from the results.
Click Add.

What does scoping to an administrative unit do?

When you assign a role at the administrative unit level, the user can only exercise those permissions on members within that specific unit. Taylor can now reset passwords and manage users inside AU-Engineering, but she has zero control over users in AU-Finance or AU-Marketing.

This is the core of least privilege: permissions are bounded to exactly what the job requires.

Don't see Add assignments?

Make sure you clicked the role name text (User Administrator), not the checkbox next to it. Clicking the checkbox selects the role for bulk operations but does not open the assignment page.

Also confirm you navigated through Admin units first, not through the top-level Roles & admins page. The scoped assignment option only appears when you enter through the AU.

Help me troubleshoot the Add assignments button for AU-scoped role assignment

Assign Security Reader to Sam Rivera (tenant scope)

Sam Rivera works in a compliance-adjacent role and needs visibility into security reports and sign-in logs. The Security Reader role gives read-only access to this data without the ability to change any settings.

Navigate to Identity > Roles & admins (the top-level page, not Admin units).
Click the Security Reader role name (again, click the name itself, not the checkbox).
Click Add assignments.
Search for Sam Rivera and select him from the results.
Click Add.

Why is this assignment at tenant scope instead of an AU?

Security reports and sign-in logs are directory-wide. If you scoped Security Reader to a single AU, Sam would only see data for users in that unit. For audit purposes, he needs visibility across the entire tenant.

This is still least privilege because the role is read-only. Sam can view security data but cannot modify any settings, reset passwords, or manage users.

Verify both role assignments

With both roles assigned, you can now confirm that each user has exactly the permissions their job function requires. You'll also confirm that the remaining users have no admin roles.

Navigate to Identity > Users.
Select Taylor Brooks from the user list.
In the left menu, select Assigned roles.
Confirm that User Administrator appears with a scope showing AU-Engineering.
Navigate back to Identity > Users and select Sam Rivera.
Select Assigned roles from the left menu.
Confirm that Security Reader appears with Directory scope.
Optionally, check Alex Kim and Jordan Patel the same way. Their Assigned roles page should be empty.

What should I see?

Taylor Brooks shows User Administrator scoped to AU-Engineering. Sam Rivera shows Security Reader scoped to the directory. Alex Kim and Jordan Patel show no assigned roles. This is least privilege in action: only accounts with elevated job responsibilities carry admin permissions.

Role not showing up?

Role assignments can take a few moments to propagate. Wait 30 seconds and refresh the page.

If the role still does not appear, navigate back to the role assignment page and confirm you completed the final Add step. The assignment is not saved until you click Add in the panel.

Help me troubleshoot a missing role assignment in Entra ID

Your RBAC assignments are locked in. Taylor can manage her engineering team, Sam can audit security data, and everyone else stays at standard access. Next up, you'll add another layer of protection by enabling MFA on the accounts that hold these elevated roles.

Enable and Configure MFA

Your RBAC assignments now control who can do what in your directory. But what happens if someone compromises Taylor's password? An attacker would inherit her User Administrator permissions instantly.

Multi-Factor Authentication (MFA) solves this by requiring a second form of verification beyond a password. In this step, you'll enable per-user MFA selectively on accounts that hold elevated roles, leaving standard users unaffected.

In this step, get ready to:

Enable per-user MFA for Taylor Brooks (User Administrator).
Enable per-user MFA for your Global Administrator account.
Understand the MFA state lifecycle: Disabled, Enabled, and Enforced.

Enable per-user MFA for Taylor Brooks

Taylor Brooks holds the User Administrator role scoped to AU-Engineering. That elevated access makes her account a high-value target. Enabling MFA ensures that even if her password is compromised, an attacker cannot sign in without a second verification factor.

In the Microsoft Entra admin center, expand Identity in the left navigation.
Select Users, then All users.
Click the Per-user MFA button at the top of the users list.

This opens the multifactor authentication management page in a new view.

Locate Taylor Brooks in the user list.
Select the checkbox next to her name.
In the quick steps panel on the right, click Enable.
Click Enable multi-factor auth in the confirmation pop-up dialog.

Taylor's MFA status column changes from Disabled to Enabled.

What does Enabled mean?

An Enabled status means MFA is now required for that user, but they have not yet registered an authentication method. The next time Taylor signs in, she will be prompted to set up a method such as Microsoft Authenticator.

Once she completes registration, her status automatically transitions to Enforced. You'll learn more about these states in the final substep.

Don't see the Per-user MFA button?

Make sure you are on the Identity > Users > All users page, not inside an individual user's profile. The button appears in the toolbar above the user list.

Your account needs at least the Authentication Policy Administrator role. Since you're signed in as Global Administrator, you have this permission already.

If the button is greyed out, confirm Security Defaults is still disabled (you did this in Step 1).

Why can't I find the Per-user MFA button in my admin center?

Enable per-user MFA for your admin account

Your own Global Administrator account holds the highest privilege level in the entire directory. It should be protected with MFA as well.

Back on the per-user MFA page, locate your Global Administrator account in the user list.
Select the checkbox next to your account.
Click Enable in the quick steps panel on the right.
Confirm in the pop-up dialog.

Both privileged accounts now require MFA. Standard users (Alex Kim, Jordan Patel, Sam Rivera) remain at Disabled status.

Why not enable MFA for everyone?

In a real organization, you would likely enforce MFA for all users through Conditional Access policies (requires Entra ID P1). For this project, per-user MFA on the free tier lets you demonstrate risk-based MFA application. Elevated privileges demand stronger authentication.

This directly connects to the RBAC work you did in the previous step. The accounts you gave admin roles are the same accounts you're now protecting with MFA.

Understand the MFA state lifecycle and verify

Per-user MFA tracks each account through three states. Understanding this lifecycle helps you know what to expect when users sign in for the first time after MFA is enabled.

Review the Multi-Factor Auth Status column on the per-user MFA page.
Confirm Taylor Brooks shows Enabled.
Confirm your Global Administrator account shows Enabled.
Confirm Alex Kim, Jordan Patel, and Sam Rivera all show Disabled.

What are the three MFA states?

Disabled means MFA is not required for the user. They sign in with just a password. This is where Alex Kim, Jordan Patel, and Sam Rivera currently sit.

Enabled means MFA is required, but the user has not yet registered an authentication method. The next time they sign in, they will be prompted to register (for example, setting up Microsoft Authenticator).

Enforced means the user has completed MFA registration and now uses it at every sign-in. The transition from Enabled to Enforced happens automatically after the user registers.

Seeing Enforced instead of Enabled on your admin account?

If your Global Administrator account already shows Enforced, that means you previously registered an MFA method for this account (possibly during initial tenant creation). This is fine. It means your account already has full MFA protection.

Taylor Brooks should still show Enabled since she has never signed in to register a method.

My admin account shows Enforced but Taylor shows Enabled. Is this correct?

Your privileged accounts are now protected with MFA. The security posture of your directory has two layers working together: RBAC controls what each user can do, and MFA protects the accounts with the most power. Next up, you'll configure an enterprise application with SAML-based SSO to complete the third pillar of identity security.

Configure SSO with an Enterprise Application

Your Entra ID environment now has RBAC controlling what each user can do and MFA verifying who they are. The final layer of access security is Single Sign-On (SSO), which connects users to applications using their Entra ID credentials.

In this step, you will add an enterprise application from the Microsoft Entra gallery, configure SAML-based SSO, and test a complete sign-on flow. This proves that Entra ID can issue a signed assertion to a service provider, granting your user access without a separate password.

In this step, get ready to:

Add the Microsoft Entra SAML Toolkit from the gallery as an enterprise application.
Configure SAML-based single sign-on with the correct URLs and certificate.
Test end-to-end SSO by signing in as an assigned user.

Add the Microsoft Entra SAML Toolkit from the gallery

Enterprise applications in Entra ID represent third-party or internal services that your users sign into. The Microsoft Entra SAML Toolkit is a purpose-built test application in the gallery designed for verifying SAML SSO configurations.

In the left navigation of the Entra admin center, navigate to Identity > Applications > Enterprise applications > All applications.
Click New application at the top of the page.
In the Browse Microsoft Entra Gallery search box, type Microsoft Entra SAML Toolkit.
Select Microsoft Entra SAML Toolkit from the results.
In the Name field, enter Microsoft Entra SAML Toolkit 1 as the display name.
Click Create.
Wait a few seconds for the application to be provisioned. You will be taken to the application's overview page.

What is an enterprise application?

In Entra ID, an enterprise application is a representation of a service that users can sign into. When you add an app from the gallery, Entra ID creates a service principal that acts as the identity link between the app and your directory.

The Microsoft Entra SAML Toolkit is Microsoft's own test application specifically designed for validating SAML SSO configurations. It requires no third-party accounts or subscriptions.

Configure SAML-based SSO

SAML SSO requires two sides to be configured: your identity provider (Entra ID) and the service provider (the application). You will start by configuring the Entra ID side with the URLs the application expects.

In the newly created application, select Single sign-on from the left menu under Manage.
Select SAML as the single sign-on method.

You are now on the Set up Single Sign-On with SAML page. This page has multiple sections you will configure.

Scroll down to the Set up Microsoft Entra SAML Toolkit 1 section (near the bottom of the page).
Record the Login URL, Microsoft Entra Identifier, and Logout URL values. Copy them to a text file or notepad. You will need these later.

Keep these values handy

You will paste the Login URL, Microsoft Entra Identifier, and Logout URL into the SAML Toolkit website later in this step. Copy them somewhere accessible now to save time.

Scroll back up to the Basic SAML Configuration section and click Edit (the pencil icon).
In the Reply URL (Assertion Consumer Service URL) field, enter https://samltoolkit.azurewebsites.net/SAML/Consume.
In the Sign on URL field, enter https://samltoolkit.azurewebsites.net/.
Click Save at the top of the Basic SAML Configuration pane.

What are these URLs?

The Reply URL (also called the Assertion Consumer Service URL) is where Entra ID sends the signed SAML assertion after authenticating the user. The Sign on URL is the application's login page where users initiate the sign-in flow.

These two URLs tell Entra ID where to redirect users during the SAML authentication exchange. They must match exactly what the application expects.

On the same SAML configuration page, scroll to the SAML Certificates section.
Find Certificate (Raw) and click Download.
Save the certificate file to your computer. You will upload this to the SAML Toolkit later.

Why download a certificate?

The certificate allows the SAML Toolkit to verify that the SAML assertion truly came from your Entra ID tenant. Without it, the application has no way to trust the authentication response. This is how SAML prevents impersonation.

Don't see the SAML Certificates section?

Make sure you clicked Save in the Basic SAML Configuration pane first. The certificate section only appears after the basic configuration is saved.

Help me find the SAML Certificates section on the SSO configuration page.

Assign a user, configure the toolkit, and test SSO

Before you can test SSO, you need to assign a user to the application. Only assigned users can authenticate via SAML. You will assign Alex Kim, then configure the SAML Toolkit's own settings, and finally run the SSO test.

In the left menu of the Microsoft Entra SAML Toolkit 1 application, click Users and groups.
Click Add user/group.
Under Users, click None Selected.
Search for and select Alex Kim.
Click Select, then click Assign.

Alex Kim is now assigned to the application. Next, you will configure the SAML Toolkit website itself so it knows how to communicate with Entra ID.

Open a new browser tab and navigate to https://samltoolkit.azurewebsites.net/.
Click Register in the upper-right corner of the page.
Register a new account using Alex Kim's email address and a password of your choice.
After registering, sign in to the SAML Toolkit with the credentials you just created.

Why register separately?

The SAML Toolkit is a standalone web application that needs its own user record before SSO can be configured. This initial registration creates a local account in the toolkit that SAML assertions will later map to. In production, most applications handle this through automated user provisioning.

Once signed in to the toolkit, click SAML Configuration in the upper-left corner of the page.
Click Create.
In the Login URL field, paste the Login URL value you recorded earlier from the Entra admin center.
In the Microsoft Entra Identifier field, paste the Microsoft Entra Identifier value you recorded.
In the Logout URL field, paste the Logout URL value you recorded.
Click Choose file and upload the Certificate (Raw) file you downloaded earlier.
Click Create.

The SAML Toolkit now trusts your Entra ID tenant as an identity provider. Time to test the full flow.

Switch back to the Entra admin center browser tab.
Navigate to the Single sign-on page for Microsoft Entra SAML Toolkit 1 (you may already be there).
Scroll down to the Test single sign-on with Microsoft Entra SAML Toolkit 1 section.
Click Test.
Sign in with Alex Kim's Entra ID credentials when prompted.

A successful sign-in confirms that SAML SSO is working end-to-end. Entra ID issued a signed assertion, the SAML Toolkit validated it, and Alex Kim was authenticated without entering a separate application password.

SSO test failed?

Make sure Alex Kim is assigned to the application under Users and groups. Unassigned users cannot authenticate via SAML.

Double-check that the Reply URL in Entra ID exactly matches https://samltoolkit.azurewebsites.net/SAML/Consume. A trailing slash or typo will cause the assertion delivery to fail.

Verify that the Login URL, Microsoft Entra Identifier, and Logout URL you pasted into the SAML Toolkit match the values from the Entra admin center exactly.

Help me troubleshoot my SAML SSO test failure for the Microsoft Entra SAML Toolkit.

Secret mission

Enforce Group-Based Application Access

In Step 4, you assigned an individual user to an enterprise application. But what happens when your company has 500 engineers who all need access? Assigning them one by one is not scalable. In this secret mission, you'll restrict a second enterprise application to a security group, proving that RBAC, group-based access control, and SSO work together as a unified security posture.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely within the free tier of Microsoft Entra ID, so there are no ongoing costs regardless of what you choose.

Resources you used:

Two RBAC role assignments (User Administrator for Taylor Brooks scoped to AU-Engineering, Security Reader for Sam Rivera at tenant scope).
Per-user MFA enabled on two accounts (Taylor Brooks and your Global Administrator account).
Two Enterprise Applications (Microsoft Entra SAML Toolkit 1 and Engineering Portal).
Security Defaults set to Disabled.

Keep everything running

No action needed. Choose this if you are still actively building or plan to use this tenant for future projects.

All resources in this project are free. Your Entra ID tenant costs nothing to maintain.
Role assignments, MFA configurations, and enterprise applications will remain in place indefinitely.

Pause - I'll come back to this later

There are no running compute resources or billable services to pause. Everything in this project is configuration-based and persists at no cost.

No action is required. Your configurations will be exactly as you left them when you return.

Delete - I don't want to use this again

Remove all project resources to start fresh. Follow the steps below to undo each configuration you created.

Remove the role assignments:

Navigate to Identity > Roles & admins.
Select the User Administrator role name to open it.
Add a check mark next to Taylor Brooks.
Click Remove assignment and confirm with Yes.
Return to Identity > Roles & admins and select the Security Reader role name.
Add a check mark next to Sam Rivera.
Click Remove assignment and confirm with Yes.

Disable per-user MFA:

Navigate to Identity > Users > All users.
Click the Per-user MFA button at the top of the users list.
Select the checkbox next to Taylor Brooks.
In the quick steps panel, click Disable and confirm.
Repeat for your Global Administrator account.

Delete the Enterprise Applications:

Navigate to Identity > Applications > Enterprise applications > All applications.
Search for and select Microsoft Entra SAML Toolkit 1.
In the left menu under Manage, select Properties.
At the top of the Properties pane, select Delete, then confirm with Yes.
Repeat for the Engineering Portal application.

Re-enable Security Defaults (optional):

Navigate to Identity > Overview > Properties.
Select Manage security defaults.
Set Security defaults back to Enabled and click Save.

Nice Work!

You just secured a Microsoft Entra ID environment with layered identity access controls. Your simulated company now has role-based access, multi-factor authentication on privileged accounts, and SAML-based single sign-on for application access.

You've learned how to:

Implement Role-Based Access Control by assigning scoped directory roles (User Administrator at the AU level, Security Reader at tenant scope) following the principle of least privilege.
Enable per-user MFA on privileged accounts and understand the MFA state lifecycle (Disabled, Enabled, Enforced) to protect elevated access.
Configure a SAML-based SSO enterprise application using the Microsoft Entra SAML Toolkit and test end-to-end single sign-on with assigned users.
Secret Mission: Restricted an enterprise application to a security group, proving that group membership enforces who can and cannot access an application via SSO.

Ready to quiz yourself?