Secure a User Directory with Entra ID

Set up users, groups, and MFA policies in Microsoft Entra ID.

Introduction

30 Second Summary

Every time you log into an app, someone decided who gets in and what they're allowed to do. In large organizations, managing thousands of these identities is one of the most critical jobs in cloud security.

In this project, you will build a realistic identity and access management setup using Microsoft Entra ID. You'll create test users, organize them into security groups, and enforce multi-factor authentication through a Conditional Access policy.

What You'll Build

You'll build a working user directory in Microsoft Entra ID, complete with users, groups, and a security policy that requires MFA for specific users accessing Azure management resources.

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

An Azure free account with Microsoft Entra ID configured for identity management.
Test users organized into security groups that mirror a real organization's department structure.
A Conditional Access policy that requires MFA for a specific group accessing Azure management tools, with a tested sign-in experience proving it works.
Secret Mission: Explore Microsoft Defender for Cloud to review your tenant's security posture and identify recommendations.

Are there any prerequisites?

You'll need a Microsoft account (Outlook, Hotmail, or Live). If you don't have one, you'll create it in Step 1. No prior Azure or cloud experience is required.

Set Up Your Azure Account and Entra Admin Center

Before you can create users, groups, or security policies, you need a home base. Microsoft Entra ID is the identity service built into Azure that manages who can access what.

In this step, you'll create a free Azure account, explore the Entra admin center, and activate a trial that unlocks Conditional Access. This is the foundation for everything you'll build in the rest of the project.

In this step, get ready to:

Create a free Azure account with $200 in credits.
Explore the Microsoft Entra admin center.
Activate the Microsoft Entra ID P2 free trial.

Create a free Azure account

Azure's free account comes with $200 in credits valid for 30 days, plus 12 months of free services. You won't be charged during this project.

In your browser, go to azure.microsoft.com/free.
Click Start free.
Sign in with your Microsoft account (Outlook, Hotmail, or Live).

Don't have a Microsoft account?

Click Create one during the sign-in flow. You'll set up a free Outlook account in about a minute.

Enter your name and phone number in the profile section.
Enter the verification code Azure sends to your phone via text.
Enter a credit or debit card number for identity verification. Prepaid cards are not accepted.

Will my card be charged?

No. Azure places a temporary $1 authorization hold to verify your card is real. The hold is reversed automatically.

You won't pay anything unless you manually upgrade to a pay-as-you-go plan later.

Check the agreement checkbox and click Sign up.

After a moment, you'll land on the Azure Portal dashboard at portal.azure.com. This is the main hub for all Azure services.

Having trouble signing up?

If your card is declined, make sure it is not a prepaid card. Azure requires a standard credit or debit card.
If you are not redirected to the dashboard after signing up, go to portal.azure.com in your browser and sign in.
Azure limits free accounts to one per customer. If you have used a free trial before, you may need to use a different email address.

Help me troubleshoot my Azure free account signup.

Navigate to the Microsoft Entra admin center

The Azure Portal is the general hub for everything in Azure. For identity management, there is a dedicated portal called the Microsoft Entra admin center.

What is Microsoft Entra ID?

Microsoft Entra ID is Microsoft's cloud-based identity and access management service. Organizations use it to control who can sign in and what resources they can access.

It was previously known as Azure Active Directory (Azure AD). If you see references to Azure AD online, they are talking about the same service.

Open a new browser tab and go to entra.microsoft.com.
Sign in with the same account you used for the Azure signup if prompted.
Explore the left-hand navigation panel.

The sections you'll use most in this project are Identity (for managing users and groups) and Protection (for Conditional Access policies).

Activate the Microsoft Entra ID P2 free trial

Your Azure free account includes the free tier of Microsoft Entra ID, which covers basic user and group management. To unlock Conditional Access and require Multi-Factor Authentication (MFA) for specific groups, you need to activate the P2 trial.

In the Entra admin center's left navigation, click Billing.
Click Licenses.
Click All products.
Click Try/Buy.
Find Microsoft Entra ID P2 and click Free trial.
Click Activate.

What does P2 unlock?

The P2 tier adds advanced security features on top of the free tier. The most important one for this project is Conditional Access, which lets you create policies that control when and how users must verify their identity.

For example, you can require MFA only for users in a specific group when they access a specific resource. That is exactly what you will build in Step 4.

The All products page now shows Microsoft Entra ID P2 with active licenses. The free trial lasts 30 days.

Can't find the trial option?

Make sure you are in the Entra admin center at entra.microsoft.com, not the Azure Portal.
If Try/Buy is not visible on the All products page, try refreshing the page. The button can take a moment to load.
If the P2 trial does not appear at all, your tenant may already have a P2 license from a previous trial. Check the All products list to see if P2 is already active.

Help me activate the Microsoft Entra ID P2 trial in the admin center.

Your Azure account is active and the Entra admin center is ready for action. Next up, you'll create test users and start building your identity directory.

Create Users and Explore Identity Concepts

Your Azure account is set up and your Entra ID P2 trial is active. Now it's time to populate your identity directory with the people who will use it.

Every organization needs a central place to manage who can access its resources. In this step, you'll create test users in Microsoft Entra ID to build a realistic directory that mirrors how real companies manage employee identities.

In this step, get ready to:

Create three test users in your Microsoft Entra ID directory.
Assign job titles to simulate different departments.
Explore user profiles to understand identity building blocks.

Create your first test user

Your directory is empty right now. Let's add the first user that your organization will manage.

In the Entra admin center, expand Identity in the left navigation.
Click Users, then click All users.
Click New user at the top of the page.
Select Create new user.
In the Display name field, enter Alex Johnson.
In the User principal name field, enter alex. The domain ending in .onmicrosoft.com is pre-selected based on your tenant.
Under Password, check Show password and copy the auto-generated password somewhere safe.
Click Review + create at the bottom of the page.
Review the user details, then click Create.

What is a user principal name?

A user principal name (UPN) is the sign-in name for a user in Microsoft Entra ID. It follows an email-like format: username@domain.

The domain part (ending in .onmicrosoft.com) is unique to your organization's Entra ID tenant. This is how Microsoft Entra ID identifies each user across all Microsoft services.

Confirm you see a notification at the top of the page saying the user was created successfully.

User not appearing after creation?

Make sure you clicked Create after the Review + create step. The review page alone does not create the user.

If you see an error about a conflicting name, try a slightly different user principal name like alexj instead.

I created a user in the Entra admin center but can't find them. How do I troubleshoot this?

Create two more test users with job titles

Real organizations have employees in different departments with different access needs. You'll now create two more users and assign each a job title to simulate this.

First, create Sam Lee, who represents an IT admin in your organization.

Click Users in the left navigation, then click All users.
Click New user, then select Create new user.
In the Display name field, enter Sam Lee.
In the User principal name field, enter sam.
Check Show password and copy the auto-generated password somewhere safe.
Click the Properties tab at the top of the form.
In the Job title field, enter IT Admin.
Click Review + create, then click Create.

Now create Jordan Rivera, who represents a marketing team member.

Click New user, then select Create new user.
In the Display name field, enter Jordan Rivera.
In the User principal name field, enter jordan.
Check Show password and copy the auto-generated password.
Click the Properties tab.
In the Job title field, enter Marketing.
Click Review + create, then click Create.

Save those passwords

You'll need Sam Lee's and Jordan Rivera's passwords in Step 5 when you test the sign-in experience. Store them in a note or text file you can easily find later.

Why assign job titles to test users?

Job titles help simulate a real organization where different roles need different levels of access. In the next steps, you'll use security groups to organize these users by role and apply different security policies to each group.

Verify your users in the directory

All three users should now be in your directory. Let's confirm they're there and explore what a user profile looks like.

Click Users in the left navigation, then click All users.

You should see all three test users (Alex Johnson, Sam Lee, and Jordan Rivera) listed alongside your admin account.

Click on Sam Lee to open their profile.
Look at the sections available on the profile page: Properties, Groups, Roles, and Sign-in logs.

What do these profile sections mean?

Properties stores the user's personal and organizational details like job title and department.
Groups shows which security groups the user belongs to. You'll create groups in the next step.
Roles displays any administrative roles assigned to the user.
Sign-in logs tracks when and how the user signs in. You'll check these logs in Step 5.

These sections are the building blocks of Identity and Access Management. Together, they tell you who someone is, what they belong to, what they can do, and what they've done.

Your directory now has three test users across different roles. Next up, you'll organize them into security groups so you can manage access at scale instead of configuring each person individually.

Organize Users into Security Groups

You now have three test users representing different roles in your organization. The next step toward a realistic directory is organizing those users into groups.

In a real company, you wouldn't manage permissions for each person individually. Security groups let you bundle users together and apply policies to the entire group at once.

In this step, get ready to:

Create a security group for your IT administrators.
Create a security group for your marketing team.
Verify that each group has the correct members.

Create the IT Admins security group

Your first group will contain users who need elevated access to Azure management tools. You'll add Sam Lee to this group since they represent an IT administrator.

In the Microsoft Entra admin center left-hand navigation, select Identity.
Select Groups, then All groups.
Select New group at the top of the page.
Set Group type to Security.
Enter IT Admins in the Group name field.
Enter IT administrators with elevated Azure access in the Group description field.
Confirm that Membership type is set to Assigned.
Under Members, select No members selected.
Search for Sam Lee.
Select the checkbox next to their name, then click Select.
Select Review + create, then Create.

What is a security group?

A security group is a container that bundles users together so you can manage their permissions as a single unit. Instead of granting access to each person one by one, you assign permissions to the group.

"Assigned" membership means you manually add and remove members. Microsoft Entra ID also supports dynamic membership, where users are automatically added based on attributes like department or job title.

You should see a notification confirming the group was created successfully.

Don't see the new group?

Refresh the All groups page. Newly created groups can take a few seconds to appear in the list.

If you received an error during creation, make sure Group type was set to Security and that you selected at least one member.

Still stuck? Help me troubleshoot why my security group wasn't created in Microsoft Entra ID

Create the Marketing Team security group

Your second group represents a team with standard access levels. Later, you'll see how policies treat this group differently from the IT Admins group.

From the All groups page, select New group again.
Set Group type to Security.
Enter Marketing Team in the Group name field.
Enter Marketing department team members in the Group description field.
Confirm that Membership type is set to Assigned.
Under Members, select No members selected.
Search for Jordan Rivera.
Select the checkbox next to their name, then click Select.
Select Review + create, then Create.

You should see another confirmation notification. Both groups now exist in your directory.

Verify your groups and their members

A misconfigured group means the wrong people get the wrong level of access. Before moving on, confirm that each group has the correct member.

In the left-hand navigation, select Groups, then All groups.
Confirm that both IT Admins and Marketing Team appear in the groups list.
Select the IT Admins group.
Select Members in the left-hand menu of the group page.
Confirm that Sam Lee is listed as a member.
Navigate back to All groups using the breadcrumb at the top of the page.
Select the Marketing Team group.
Select Members and confirm that Jordan Rivera is listed.

Why organize users into groups?

Groups are the backbone of scalable access management. Instead of creating a security policy for each individual user, you create one policy and apply it to a group.

When a new IT admin joins the company, you just add them to the IT Admins group. They instantly inherit all the group's permissions without any extra configuration.

Missing a member in one of your groups?

Select the group, then select Members. Select Add members, search for the missing user, and click Select.

Still having trouble? Help me fix my security group membership in Microsoft Entra ID

Your users are now organized into groups that mirror a real company's team structure. Next up, you'll create a Conditional Access policy that treats these two groups very differently.

Create a Conditional Access Policy Requiring MFA

Your directory now has test users organized into security groups. That structure mirrors how real organizations manage their workforce, but it doesn't enforce any security rules on its own.

Conditional Access is the policy engine in Microsoft Entra ID that adds enforcement. It evaluates every sign-in attempt and decides whether to allow, block, or require additional verification like MFA.

In this step, get ready to:

Navigate to Conditional Access and explore existing policies.
Create a policy that targets the IT Admins group and Azure management resources.
Enable MFA enforcement so IT admins must verify their identity when managing Azure.

Navigate to Conditional Access policies

In the Entra admin center left-hand navigation, expand Protection.
Click Conditional Access.
Click Policies.

Before creating your own policy, notice any Microsoft-managed policies already listed on this page. These are pre-configured by Microsoft to protect common scenarios.

What are Microsoft-managed policies?

Microsoft automatically creates a set of Conditional Access policies for every tenant. They start in Report-only mode and are designed to cover common security baselines.

You don't need to change any of them for this project. The custom policy you're about to create will work alongside them.

Seeing a prompt about Security Defaults?

New Azure tenants have Security Defaults enabled, which provide basic MFA for all users. Security Defaults and Conditional Access policies cannot be active at the same time.

If you see a banner or prompt asking you to disable Security Defaults, click the link to disable them. This is required before you can create or enable a Conditional Access policy.

Click New policy.
In the Name field, enter Require MFA for Azure Management.

Configure the policy assignments

Every Conditional Access policy needs two things: who it applies to, and what resource it protects. You'll assign the IT Admins group as the target users and Azure management tools as the target resource.

Under Users, click the link that says 0 users and groups selected.
On the Include tab, select Select users and groups.
Check the Users and groups checkbox.
Click the Select link that appears below the checkbox.
Search for IT Admins and select it.
Click Select to confirm your choice.

Now you'll define which resource the policy protects.

Under Target resources, click the link that says No target resources selected.
Under Resources (formerly Cloud apps), make sure Include is selected.
Select Select resources.
In the search box, type Windows Azure Service Management API.
Select Windows Azure Service Management API from the results.
Click Select to confirm.

What is the Windows Azure Service Management API?

This resource represents all Azure management tools: the Azure Portal, Azure PowerShell, and the Azure CLI. By targeting it, your policy applies whenever someone tries to manage Azure resources through any of these tools.

This is a common real-world policy pattern recommended by Microsoft. It protects the most sensitive access point without affecting everyday apps like email or Teams.

Set access controls and enable the policy

You've told the policy who to watch and what to protect. Now you'll tell it what to do when those conditions are met.

Under Access controls, click 0 controls selected under Grant.
Select Grant access.
Check Require multifactor authentication.
Click Select.

The policy is fully configured. Now you need to turn it on.

At the bottom of the policy page, find Enable policy and set it to On.
Click Create.

You should see your new policy listed on the Conditional Access Policies page with its state showing as On.

What does this policy do?

You just created a live Conditional Access policy that evaluates sign-ins in real time. Here's what it enforces:

Anyone in the IT Admins group who tries to access Azure management tools must complete MFA.
Users outside the IT Admins group (like Jordan Rivera in Marketing Team) are not affected by this policy.
The policy only triggers when accessing Azure management resources. Other apps like email remain unaffected.

Policy not saving?

Make sure you selected at least one user or group under Users, at least one resource under Target resources, and at least one control under Grant. All three are required for a valid policy.

If you see an error about Security Defaults, scroll back up to the error callout in this step for instructions on disabling them.

Help me troubleshoot why my Conditional Access policy won't save in the Microsoft Entra admin center.

Your Conditional Access policy is live. Next up, you'll test it by signing in as different users to see MFA enforcement in action.

Test the MFA Experience

Your Conditional Access policy is live. But a security policy is only as good as its enforcement.

In this step, you'll sign in as two different test users to prove the policy works correctly. Sam Lee (in the IT Admins group) should be prompted for MFA. Jordan Rivera (in the Marketing Team) should not. This side-by-side test confirms your policy targets the right people.

In this step, get ready to:

Sign in as Sam Lee and complete MFA registration.
Sign in as Jordan Rivera and confirm no MFA prompt appears.
Review sign-in logs to verify selective policy enforcement.

Sign in as Sam Lee and set up MFA

Sam Lee is in the IT Admins group, which your Conditional Access policy targets. When Sam tries to access the Azure Portal, the policy detects the group membership and requires MFA before granting access.

Open a private or incognito browser window. Press Cmd+Shift+N (macOS) or Ctrl+Shift+N (Windows) to open one.
Go to portal.azure.com.
Enter Sam Lee's user principal name in the sign-in field (e.g., sam@yourtenantname.onmicrosoft.com).
Click Next.
Enter the auto-generated password you noted when you created Sam Lee's account.

Since this is Sam Lee's first sign-in, you'll be asked to update the password.

Create a new password for Sam Lee and note it down.
Click Sign in.

After the password update, you'll see a prompt requiring additional verification. This is your Conditional Access policy in action.

Follow the on-screen prompts to register a phone number or the Microsoft Authenticator app for MFA.
Complete the verification step by entering the code sent to your phone or approving the notification in the authenticator app.

After completing MFA, you should see the Azure Portal dashboard. Sam Lee has successfully signed in with MFA enforced.

What just happened?

Your Conditional Access policy detected that Sam Lee is a member of the IT Admins group and is accessing the Windows Azure Service Management API (which covers the Azure Portal). Both conditions matched, so the policy required MFA before granting access.

This is exactly how organizations protect sensitive management resources in production environments.

Not seeing an MFA prompt?

Make sure Security Defaults are disabled. Conditional Access and Security Defaults cannot be active at the same time. In the Entra admin center, go to Identity > Overview > Properties > Manage Security defaults and set it to Disabled.
Confirm Sam Lee is a member of the IT Admins group by checking Entra ID > Groups > IT Admins > Members.
Verify the policy status is set to On (not Report-only) under Entra ID > Conditional Access > Policies.
Why isn't Sam Lee being prompted for MFA when signing into the Azure Portal?

Sign in as Jordan Rivera and compare the experience

Now test a user who is outside the targeted group. Jordan Rivera is in the Marketing Team, which your Conditional Access policy does not include.

In the Azure Portal (where Sam Lee is signed in), click the user icon in the top right corner.
Select Sign out.
Close all incognito/private browser windows to clear the session completely.
Open a new private/incognito browser window.
Go to portal.azure.com.
Enter Jordan Rivera's user principal name (e.g., jordan@yourtenantname.onmicrosoft.com) and click Next.
Enter the auto-generated password you noted when you created Jordan Rivera's account.
Update the password when prompted. This is the standard first-sign-in password change.

Notice that Jordan Rivera is NOT prompted for MFA. After updating the password, Jordan goes straight to the Azure Portal dashboard without any additional verification.

Why wasn't Jordan prompted for MFA?

Your Conditional Access policy only includes the IT Admins group. Jordan Rivera belongs to the Marketing Team group, which is not part of the policy.

This selective enforcement is the core value of Conditional Access. You apply the right level of security to the right people based on who they are and what they're accessing.

Sign out of Jordan Rivera's session by clicking the user icon in the top right corner and selecting Sign out.

Jordan was prompted for MFA too?

If both users are prompted for MFA, Security Defaults might still be enabled. Security Defaults enforce basic MFA for all users, regardless of group membership.

To fix this, go to the Entra admin center and navigate to Identity > Overview > Properties > Manage Security defaults. Set it to Disabled, then test Jordan's sign-in again.

Both users are being prompted for MFA when only Sam Lee should be. How do I fix this?

Review sign-in logs to verify policy application

Sign-in logs record every authentication event in your tenant. They show which Conditional Access policies applied, whether MFA was required, and whether it was satisfied.

Open a regular (non-incognito) browser window and go to entra.microsoft.com.
Sign in with your admin account.

In the left navigation, go to Entra ID > Conditional Access > Policies.
Select your Require MFA for Azure Management policy and confirm it's still enabled.

Now check the sign-in logs to see exactly what happened during each test user's authentication.

Navigate to Entra ID > Sign-in logs.
Look for sign-in entries from Sam Lee and Jordan Rivera in the list.
Select Sam Lee's sign-in entry. You should see that the Conditional Access policy was applied, MFA was required, and MFA was satisfied.
Select Jordan Rivera's sign-in entry. You should see that no Conditional Access policy required MFA for this sign-in.

Why do sign-in logs matter?

In real organizations, sign-in logs are critical for security monitoring. They let administrators verify that policies are working, investigate suspicious sign-ins, and audit who accessed what resources.

Sign-in logs and monitoring are key topics on both the SC-900 and AZ-500 exams.

Not seeing sign-in entries?

Sign-in logs can take a few minutes to appear. Wait 5-10 minutes and refresh the page.
Make sure you're viewing the correct time range. Adjust the date filter at the top of the logs page to include today.
Try searching for the user's name in the search bar above the log entries.
Why can't I see sign-in log entries for my test users in the Entra admin center?

Secret mission

Explore Your Security Posture with Microsoft Defender for Cloud

You've secured your directory with users, groups, and Conditional Access. But how do you know if your setup actually follows security best practices? In this Secret Mission, you'll explore Microsoft Defender for Cloud to review your tenant's security posture and find recommendations to improve it.

Before you go

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses the Azure free account and a free Microsoft Entra ID P2 trial, so there are no charges as long as you stay within the free tier.

Cost warning

Your Azure free account includes $200 in credit valid for 30 days. Your credit card will not be charged unless you manually upgrade to a pay-as-you-go subscription.

Your Microsoft Entra ID P2 trial is free for 30 days. After it expires, Conditional Access policies you created will remain visible but cannot be edited or created. Your users and groups will remain.

Resources you used:

Azure free account with $200 in credit for 30 days, plus 12 months of select free services.
Microsoft Entra ID P2 trial (free for 30 days), which unlocks Conditional Access policies.
Three test users (Alex Johnson, Sam Lee, Jordan Rivera) created in your Entra ID tenant.
Two security groups (IT Admins, Marketing Team) organizing your test users.
One Conditional Access policy requiring MFA for the IT Admins group when accessing Azure management resources.

Keep everything running

No action needed. Choose this if you're still actively exploring Azure and Entra ID, or if you plan to build on this project soon.

Your test users and security groups cost nothing to keep.
Your Conditional Access policy remains active as long as the P2 trial is valid.
Sign into the Azure Portal at least once every 30 days to keep your free account active. Inactive accounts may have compute resources removed.

Pause - I'll come back to this later

Clean up your test users and policy to start fresh later, while keeping your Azure account and Entra tenant intact.

Go to Entra ID > Conditional Access > Policies. Select your Require MFA for Azure Management policy and set Enable policy to Off, then click Save.
Go to Entra ID > Users. Select each test user (Alex Johnson, Sam Lee, Jordan Rivera) and click Delete. Deleted users can be restored within 30 days from the Deleted users page.
Go to Entra ID > Groups > All groups. Select the IT Admins and Marketing Team groups and delete them.
Your Azure account stays active. Sign in at least once every 30 days to keep it from going inactive.

Delete - I don't want to use this again

Remove all project resources and cancel your Azure account entirely.

First, delete your test users and groups by following the steps in the Pause tab above.
Delete the Conditional Access policy by going to Entra ID > Conditional Access > Policies, selecting the policy, and clicking Delete.
To cancel your Azure account, go to the Azure Portal at portal.azure.com. Navigate to Subscriptions, select your subscription, and click Cancel subscription.
If you stayed within the free tier, there are no outstanding fees.

Mission accomplished

That's a Wrap!

Nice work! You just built a real identity and access management setup in Microsoft Entra ID from scratch. That's the actual tool enterprises use to manage who can access what.

You've learned how to:

Built a user directory with test users organized into security groups for scalable access management across departments.
Created a Conditional Access policy requiring MFA for Azure management access.
Tested MFA enforcement and verified selective policy application through sign-in logs.
Explored Microsoft Defender for Cloud and reviewed your tenant's security posture and recommendations.

These skills map directly to the SC-900 exam domains (Microsoft Entra: 25-30%, Security Solutions: 35-40%) and the AZ-500 exam's identity and access section (15-20%). You're building real hands-on evidence while studying for your certifications.

Ready to quiz yourself?