A password on a sticky note
Most cloud breaches don't start with clever hacking — they start with a stolen password. Sita's cashier signs in from the shop; her admin signs in from home, from a café in Lakeside, sometimes from a phone. One password can't tell those situations apart. Identity has to look at the whole sign-in.
Azure's identity service is Microsoft Entra ID. Older books and blog posts call it Azure Active Directory (Azure AD) — Microsoft renamed it in 2023, and the features are the same. RBAC from Day 2 decides what a principal can do; Entra ID decides who the principal is, and whether this sign-in should be trusted at all.
Tenants, users and identities for code
A tenant is your organisation's own instance of Entra ID, with a domain like momoshop.onmicrosoft.com (you can add your own). Every subscription trusts exactly one tenant, though one tenant can hold many subscriptions. Entra ID is not Windows Server Active Directory in the cloud: it speaks web protocols — OAuth 2.0, OpenID Connect, SAML — not LDAP and Kerberos, and it has no organisational units or Group Policy.
- Users: members of your tenant, or guests from other organisations (B2B collaboration).
- Groups: security groups for access, Microsoft 365 groups for collaboration; groups can contain groups.
- App registrations and service principals: an application's identity, so it can sign in and be granted roles.
- Managed identities: a service principal that Azure creates and rotates for a resource, so your Function can read Key Vault or Storage with no secret in its code.
- Entra roles (Global Administrator, User Administrator…) manage the directory; Azure RBAC roles manage resources. They're separate systems.
Keep two break-glass accounts: cloud-only Global Administrators excluded from your Conditional Access policies and stored safely, so a bad policy can never lock everyone out.