The Microsoft Entra admin center: a practical guide to identity and access
One portal holds the keys to a Microsoft tenant: who the users are, what they can touch, and how they prove it. If you can find your way around the Entra admin center, you can do most of the identity work a cloud engineer is asked for.
New to cloud? CAMPUX is a free, build-first course. Start here →
The Microsoft Entra admin center (entra.microsoft.com) is the portal for managing identity and access: users and groups, roles, Conditional Access, and enterprise application single sign-on. It is the modern home for what used to live under Azure Active Directory. Most day-to-day identity administration for a tenant happens here. Everything below is a tour of that portal from the seat of someone who actually has to get work done in it.
What the Entra admin center is (and its Azure AD lineage)
If you learned this world a few years ago, you knew it as Azure Active Directory, and you managed it from a blade in the Azure portal. In 2023 Microsoft renamed the product to Microsoft Entra ID and gave it a dedicated portal at entra.microsoft.com. The part that trips people up is worth saying plainly: the rename is a name change, not a rebuild. Your tenant, your users, your groups, your app registrations — they are the same objects with the same IDs they had before. Nothing was migrated or lost. "Entra" is an umbrella brand for Microsoft's identity products, and Entra ID is the directory service that sits at the center of it.
You can still reach identity settings from the Azure portal, and the two portals talk to the same directory, so a change in one shows up in the other. But the Entra admin center is where Microsoft now puts new identity features first, so it is the one to learn. Sign in with an account that holds an administrative role, and you land on an overview of your tenant.
The areas you'll use most
The left-hand navigation groups features into a handful of areas. Portals get reorganized often, so treat these as capabilities to find rather than a map to memorize — the labels move, the ideas do not.
- Users — the accounts of the people (and some service identities) in your tenant. Create them, edit their profile and licenses, reset passwords, disable them when someone leaves.
- Groups — collections you assign access to once instead of person by person. Security groups gate resources; Microsoft 365 groups also carry a mailbox and shared tools.
- Roles & administrators — the built-in administrative roles, from Global Administrator down to narrow ones like Helpdesk Administrator or User Administrator. This is where you decide who can change what.
- Applications, including Enterprise applications — the apps your organization has connected for sign-in, and the app registrations developers create. This is the home of single sign-on.
- Protection, including Conditional Access — the sign-in policies and security controls: multi-factor requirements, device rules, risk-based access.
Almost every task in this article is one of those five areas. Get comfortable finding them and the portal stops feeling large.
Users, groups, and roles
These three are the backbone, and the relationship between them is the whole game. A user is an identity — one person, one account. A group is a bucket you drop users into so you can grant access in one move: give the group access to a resource, and every member inherits it. When someone joins the team, adding them to the right groups can hand them most of what they need without touching a single resource.
A role is different, and the distinction matters. Groups usually control access to resources — a shared drive, an application, a subscription. Administrative roles control access to managing the tenant itself: who can create users, who can edit Conditional Access, who can read sign-in logs. Global Administrator can do all of it, which is exactly why it should be rare. The next section is about handing out only the piece someone actually needs.
Least-privilege access, step by step
The instinct under time pressure is to grant Global Administrator and move on. Resist it. Every account with that role is a full-tenant compromise waiting to happen, and auditors count them. The discipline is simple: give the most specific role that covers the task, scoped as narrowly as the role allows. Here is the walkthrough for a common case — letting a help-desk hire reset passwords without giving them the tenant.
- In the Entra admin center, open Roles & administrators.
- Find the role that matches the task. For password resets and basic user support, that is Helpdesk Administrator, not Global Administrator. Read the role's description — Entra lists what each one grants — and pick the smallest one that still does the job.
- Open the role and choose Add assignment.
- Select the user (or, better, a group you use for that job function, so future hires inherit it).
- Where the role supports it, set the scope to a single administrative unit — a slice of the directory, such as one department — instead of the whole tenant. Now the assignment only reaches the users in that unit.
- If your tenant has Privileged Identity Management, make the assignment eligible and time-bound rather than permanent. The person activates the role when they need it, for a set window, and it lapses on its own.
The result is an account that can do one job on one slice of the directory, and nothing else. If that account is ever phished, the blast radius is a department's password resets, not the entire company.
The right question is never "which role lets them in," it's "which is the smallest role that still lets them finish the task."
Enterprise application SSO, step by step
Single sign-on is the feature people feel most: employees sign in once with their work account and reach their tools without a separate password for each. In Entra you set this up by adding the tool as an enterprise application, which makes Entra ID the identity provider for it. Here is the shape of it for a typical software-as-a-service app.
- Go to Enterprise applications and choose New application. Many well-known apps are in the gallery with SSO pre-templated; if yours is there, pick it. If not, add it as a custom application.
- Open the app's Single sign-on settings and choose the protocol the app supports — SAML or OpenID Connect (OIDC). The app's own documentation tells you which.
- Exchange the configuration both sides need. For SAML, that means the identifier and reply URL from the app, and the login URL and certificate from Entra. For OIDC, it is the client ID, secret, and redirect URI. This is the step people rush and then spend an hour debugging — copy each value carefully; a trailing slash on a reply URL is enough to break a login.
- Under Users and groups for that application, assign the users or groups who are allowed to use it. Assignment is access: if a user is not assigned (and the app is set to require assignment), they cannot sign in, even inside your tenant.
- Test with one account before you announce it. Sign in through the app and confirm the round trip works, then roll it out to the group.
Once it is wired, joiners and leavers become a group-membership change instead of an account in yet another system, which is the quiet payoff of doing identity centrally.
Assign access to groups, not individual people, almost every time — for both resources and application access. It feels like extra work for one user, but it turns onboarding, offboarding, and audits into a single membership change instead of a hunt through every app and resource. The one place to be deliberate is administrative roles, where you still want to know exactly which humans hold each one.
Conditional Access in one paragraph
Conditional Access, under Protection, is the policy engine that decides what a sign-in must satisfy before it is allowed. Each policy is an if-then: if these users reach this app under these conditions — a certain location, an unmanaged device, an elevated sign-in risk — then require something, such as multi-factor authentication or a compliant device, or block the attempt outright. It is how "require MFA for admins" or "block sign-ins from outside our countries" stops being a wish and becomes an enforced rule. It is a deep area with real potential to lock people out, including yourself, so build policies in report-only mode first, watch what they would have done, and only then turn them on.
Where to go next
You now have the shape of the portal: five areas, the user-group-role backbone, and the two workflows — least-privilege roles and enterprise-app SSO — that make up a large share of real identity work. The way to make it stick is to open entra.microsoft.com in a test tenant and actually create a user, drop them in a group, assign a narrow role, and connect one app for SSO. Reading gets you the map; doing it once turns the portal from intimidating into routine.
Questions people also ask
What is the Microsoft Entra admin center?
The Microsoft Entra admin center is the web portal at entra.microsoft.com for managing identity and access in a Microsoft tenant. From it you manage users and groups, assign roles, configure Conditional Access, and set up single sign-on for enterprise applications. It is the place most day-to-day identity administration happens.
Is Entra admin center the same as Azure Active Directory?
It manages the same service. Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023, and the Entra admin center is its dedicated portal. The rename is a name change, not a re-architecture: your users, groups, roles, and tenant are the same objects they always were. You can still manage identity from the Azure portal, but Entra is now the primary home.
How do I assign least-privilege access in Entra?
Pick the most specific built-in role that covers the task rather than Global Administrator, and scope it as narrowly as the role allows. Go to Roles and administrators, open the role you need, choose Add assignment, select the user, and where the role supports it, set the scope to a single administrative unit or application instead of the whole tenant. Prefer eligible, time-bound assignments over permanent ones where Privileged Identity Management is available.
What is an enterprise application in Entra?
An enterprise application is the representation of a software-as-a-service or internal app that your tenant has connected for single sign-on and user access. Adding one lets Entra ID act as the identity provider, so users sign in with their organization account through SAML or OpenID Connect, and you control who can reach the app by assigning users and groups to it.