10.1 Microsoft Entra ID Capabilities

Quick Answer: Microsoft Entra ID (formerly Azure Active Directory) is the cloud identity and access management service for Microsoft 365. A tenant is a dedicated directory. Entra stores users and groups, issues single sign-on (SSO) to Microsoft 365 and connected apps, holds app registrations, and assigns roles. Microsoft Entra ID Protection scores identity risk. Passwordless sign-in replaces the password with something you have or are.

The April 30, 2025 MS-900 outline asks you to describe the identity and access management capabilities of Microsoft Entra ID. This is a recommend-the-service skill. You will not be asked to write a Conditional Access policy in JSON, size a federation farm, or sit SC-300. You will be asked which cloud directory every Microsoft 365 tenant already has, what a tenant is, why users can open Teams and Salesforce after one sign-in, where an application gets its trust relationship, which role is too broad, what “risky sign-in” means, and what passwordless actually replaces.

Microsoft Entra ID is the directory, not the whole Entra family

Microsoft Entra is a product family. Microsoft Entra ID is the foundational product in that family: a cloud-based identity and access management service that authenticates people and apps, enforces policy, and protects access to users, devices, apps, and resources. Official Learn is blunt: if you subscribe to Microsoft 365, Azure, or Dynamics 365, you already use Microsoft Entra ID — every tenant is automatically a Microsoft Entra tenant.

Microsoft renamed Azure Active Directory (Azure AD) to Microsoft Entra ID so the cloud directory would stop being confused with Windows Server Active Directory. On this exam, use Microsoft Entra ID as the product name. Mention Azure AD only as the former name. Do not treat “Azure AD” and “Active Directory Domain Services” as synonyms. One is the cloud directory. The other is the on-premises Windows Server directory you will contrast in section 10.2.

Admins work in the Microsoft Entra admin center (entra.microsoft.com). The Microsoft 365 admin center can launch it. Identity depth lives in Entra, not in the usage-report blades from Chapter 9.

A tenant is a directory

A tenant is a dedicated instance of Microsoft Entra ID — the directory for one organization. It holds organizational objects: users, groups, devices, application registrations, and the roles that administer them. Every new directory gets an initial domain such as contoso.onmicrosoft.com. You can add custom domain names (contoso.com) so people sign in with a familiar address.

That sentence is the scoring key. A tenant is not an Azure subscription, a Microsoft 365 license SKU, a country, or a single SharePoint site. A subscription uses a tenant. A license is assigned to a user in a tenant. Several Azure subscriptions can trust the same Entra tenant. If the stem says “where do the user accounts live?” the answer is the Entra tenant / directory, not “in Exchange” and not “in Intune.”

Users and groups

Users are the people (and some service identities) who sign in. Typical workforce accounts are member users created in the tenant or synchronized from on-premises Active Directory. Guest users are the business-to-business collaboration path: a partner or contractor is invited, authenticates with their home identity when they can, and receives access you grant in your tenant. MS-900 only needs that split: employees and synced staff versus invited guests. It does not need a B2B protocol lab.

Groups let you assign access once instead of user by user. Official Learn: assign permissions to the group, then membership controls who receives them. Security groups are the usual bucket for app assignments, license assignment, and Conditional Access targeting. Microsoft 365 groups also create a shared collaboration workspace (mailbox, calendar, SharePoint site, Teams team). Membership can be assigned (an admin adds people) or dynamic (a rule such as department equals Sales). Synced on-premises groups are managed in Active Directory and flow into Entra; you do not treat the cloud copy as the editable source of truth.

On the exam, “assign the Sales team Exchange Online and a Conditional Access policy without clicking fifty names” is a group. “Invite a supplier for one SharePoint library” is a guest user. “Create the account that will exist only in Microsoft 365” is a cloud user — section 10.2 will contrast that with hybrid.

Single sign-on and app registrations

Single sign-on (SSO) means the user authenticates to Microsoft Entra ID once and can open many applications without a separate username and password for each one. Microsoft 365 apps — Outlook, Teams, SharePoint, the admin centers — already trust the tenant. Thousands of gallery SaaS apps and line-of-business apps can trust it too. SSO is an identity capability. It is not “the user never sees a prompt again on an unmanaged kiosk,” and it is not the same thing as Seamless SSO (a hybrid helper you will meet in 10.2).

App registrations are how an application becomes a first-class citizen of the tenant. Conceptually, a developer or admin registers the app so Entra can authenticate users (or the app itself) and issue tokens using open standards such as OAuth 2.0 and OpenID Connect. The registration is the trust record: application identity, the permissions it can request, and where tokens may be sent. You do not need redirect-URI trivia on MS-900. You need this contrast: users and groups are people and collections; an app registration is the application’s identity in the directory. Enterprise applications / service principals are the other side of that coin — the instance of the app in this tenant that you assign users and SSO to. If the stem says “the custom expense app should use Entra sign-in instead of its own password table,” the move is register the app and enable SSO, not “create fifty local app accounts.”

Roles: least privilege, not one superuser

Microsoft Entra ID uses role-based access control (RBAC). Built-in roles package a job: Global Administrator can do almost everything and is the emergency / break-glass role, not the daily help-desk account. User Administrator creates and resets users. Helpdesk Administrator handles a narrower password and unlock set. Conditional Access Administrator authors access policies. Security Administrator works identity-security settings. Billing Administrator and Exchange Administrator are examples you already used in Chapter 9. The exam verb is least privilege: give the smallest role that completes the task. “Make the intern a Global Administrator so they can reset one password” is the trap.

Custom roles exist in premium licensing. You do not need to author one. You need to refuse the idea that identity administration is a single shared admin password.

Identity Protection, conceptually

Microsoft Entra ID Protection detects, investigates, and remediates identity-based risk. It is not antivirus and it is not a firewall. Official Learn: Microsoft scores signals (anonymous IP addresses, password spray, leaked credentials, and more) and produces risk detections, risky sign-ins, and risky users. Automation matters because the volume of attacks is too large for ticket-by-ticket review.

Two exam-sized ideas sit on top of those reports.

• Sign-in risk asks “how likely is this attempt compromised?”
• User risk asks “how likely is this account already compromised?” (for example, the password appeared in a leaked list).

Those scores can feed risk-based Conditional Access: require multifactor authentication, require a password change, or block. If the user completes the control, the risk can be automatically remediated. If nobody turned on those policies, an admin reviews the reports and confirms compromise, confirms safe, or dismisses the risk. Full ID Protection policy and reporting capabilities are a Microsoft Entra ID P2 (or equivalent Microsoft 365 E5-class) feature. You do not invent a price. You remember the job: risk in, access decision out.

ID Protection is also why Microsoft tells hybrid customers to enable password hash synchronization even when they use another sign-in method: leaked-credential detection needs a hash in the cloud to compare. That sentence belongs conceptually here; the hybrid methods themselves are section 10.2.

Passwordless, conceptually

Passwordless authentication still proves who you are. It stops using a shared secret the user types. Official MFA language still applies: something you have (a phone, a hardware key) and/or something you are (biometrics), often bound to a device. Methods you should be able to name at fundamentals level:

• Windows Hello for Business — PIN or biometric unlocks keys stored on the PC.
• Passkeys (FIDO2) — a security key or platform passkey the user possesses.
• Microsoft Authenticator passwordless — approve a sign-in on a registered phone, often with a number match, without typing the directory password.

Temporary Access Pass (TAP) is a time-limited passcode an admin can issue so a user can onboard or recover and then register stronger methods. It is a bootstrap, not the long-term passwordless method.

Passwordless is not “there is no identity.” It is not “MFA is turned off.” Many passwordless methods are phishing-resistant MFA. It is not the same as self-service password reset, which still assumes a password exists and needs changing. If the stem says “stop relying on passwords that leak on the dark web,” passwordless is the direction. If the stem says “users forgot the password and the help desk is drowning,” that is SSPR in section 10.3.

Capability map for the exam

Realistic exam-style scenarios

Already included. A startup buys Microsoft 365 Business Premium and asks which extra directory product it must stand up before anyone can sign in to Teams. None. The tenant is an Entra tenant.

Name change. A question still says Azure AD. Treat it as Microsoft Entra ID. Do not pick Windows Server Active Directory just because you saw the words “Active Directory.”

One login, many apps. Finance wants Salesforce, ServiceNow, and Exchange Online to stop issuing their own passwords. SSO against the Entra tenant, with each app represented as an enterprise app / registration. That is not Intune and not a new forest.

Custom app. Developers built an internal expense site and want work-or-school sign-in. Register the application in the tenant so Entra can authenticate users and issue tokens. Do not create a shadow password file.

Least privilege. The service desk only resets passwords. Helpdesk Administrator or Password Administrator, not Global Administrator.

Leaked password list. Security hears that employee passwords appeared in a public dump. ID Protection user risk / leaked credentials, typically remediating with a password reset and MFA — not Autopilot.

No more typed secrets. Leadership wants sign-in that is a face scan on a corporate laptop or a tap on a security key. Passwordless (Windows Hello for Business or FIDO2), not “disable MFA.”

Exam traps

• Entra ID is not AD DS. Cloud directory versus on-premises Windows Server directory.
• Entra ID is not the whole Entra family. ID Governance, Verified ID, and Private Access are related products; the MS-900 bullet is Entra ID IAM.
• A tenant is not a subscription or a license. It is the directory.
• SSO is not Seamless SSO. SSO is the outcome. Seamless SSO is a hybrid convenience feature.
• App registration is not a user account. It is how the application trusts Entra.
• ID Protection is not Defender for Endpoint. It scores identity risk.
• Passwordless is not anonymous access. The user still has an identity.
• Do not turn this into SC-300. No custom role JSON, no token-lifetime labs, no Graph permission catalogs.

Official sources

• What is Microsoft Entra? — Entra ID as the cloud IAM service; every Microsoft 365 tenant is an Entra tenant
• New name for Azure Active Directory — Microsoft Entra ID replaces Azure AD as the product name
• Learn about groups — groups assign access to users
• What is Microsoft Entra ID Protection? — risk detections, risky sign-ins, risky users, risk-based remediation
• Microsoft Entra multifactor authentication overview — something you know, have, or are; passwordless methods in the verification list
• Study guide for Exam MS-900 — identity and access management capabilities of Microsoft Entra ID