Microsoft Entra ID, authentication and role-based access control

Entra ID is the directory, and the tenant is its boundary

Microsoft Entra ID is a cloud identity and access service. It holds users, groups, and the non-human principals — service principals and managed identities — that applications sign in as, and it speaks the modern web protocols: OAuth, SAML and OpenID Connect. A tenant is one instance of that directory, belonging to one organisation, and it is the boundary identity lives inside; Azure subscriptions trust a tenant for authentication. Guests brought in from other organisations are handled as external identities in the same directory rather than as a second one.

What Entra ID does not offer is the older on-premises machinery: no LDAP binds, no Kerberos tickets, no domain to join and no group policy. Microsoft Entra Domain Services fills exactly that gap, providing those as a managed domain populated from the same directory, so a lifted-and-shifted application can domain join and authenticate the way it always did without anybody building, patching and replicating domain controllers. The two are complementary rather than alternatives, and a stem that says Kerberos, LDAP or domain join has named the second one.

Authentication methods: single sign-on, multifactor, passwordless

Single sign-on means one authentication with a central identity provider grants access to many applications. The benefit is not only convenience: fewer systems hold credentials, so there are fewer places to breach and exactly one place to disable an account when somebody leaves. The cost is concentration — that one door is now worth strengthening, which is what the other two methods are for.

Multifactor authentication combines proofs from DIFFERENT categories: something you know, something you have, something you are. Two passwords are not multifactor, because the independence is the whole point — stealing a password does not also steal a phone or a fingerprint. Passwordless methods go further by removing the password rather than adding a step to it: a device sign-in, a hardware security key or an authenticator app produces a credential that is never typed and never reused, so it cannot be phished or replayed the way a password can.

Conditional Access decides whether you get in

Conditional Access is the if-then layer of identity. It evaluates signals at sign-in — which user, from where, on what device, reaching which application, at what assessed risk — and applies a decision: allow, allow but require something more such as multifactor authentication, or block outright. That is what makes strong authentication proportionate instead of constant, and it is where device state and location enter the decision at all.

Turning multifactor authentication on for everybody, everywhere, always is the blanket alternative and it is offered as a wrong answer because it satisfies one clause of a requirement by ignoring the others. It cannot express "not from the office", and it cannot refuse an unmanaged device.

Role-based access control decides what you may touch

A role assignment is three things joined together: a security principal, a role definition, and a scope — a management group, a subscription, a resource group or a single resource. It flows downward from wherever it is made, so an assignment at a subscription covers resource groups and resources created there next month without anybody revisiting it. The default is no access at all until an assignment says otherwise.

Two habits are what the exam rewards. Assign to a group rather than to people, so that joining and leaving a team is one membership change instead of a hunt through scopes. And assign at the highest scope where the sentence you are enforcing stays true, using the least privileged built-in role that covers the need — Reader views, Contributor changes, Owner changes and also grants access to others, which is why Owner is so rarely the right answer to a stated requirement.