Microsoft Azure Administrator Training Course

Before you create a single user, you need an accurate picture of where identity lives in Azure. Almost every confusing AZ-104 question about permissions comes from mixing up two hierarchies that look similar and are not connected the way people assume.

Two hierarchies, one trust relationship

The first hierarchy is the identity plane: Microsoft Entra ID, formerly Azure Active Directory. A single instance of it is a tenant, and a tenant represents one organization. It holds user accounts, groups, service principals, application registrations, and the policies that govern them. It has no notion of virtual machines or storage accounts.

The second is the resource plane: management groups, subscriptions, resource groups, and resources. This is where everything you deploy lives and where everything you spend is billed.

The two are joined by a trust relationship. Every subscription trusts exactly one Entra tenant to authenticate the people and services acting on it. A tenant, by contrast, can be trusted by many subscriptions — a large organization commonly runs one tenant and dozens of subscriptions for different environments, departments, or cost centers.

Two consequences follow, and both are examinable:

• Deleting or leaving a subscription does not delete the users. They live in the directory, not the subscription.
• Transferring a subscription to a different tenant breaks every existing role assignment in it, because those assignments point at object IDs that mean nothing in the new directory. Plan a re-assignment pass as part of any tenant move.

What identifies a tenant

A tenant has a globally unique tenant ID, a GUID, and an initial domain in the form yourorg.onmicrosoft.com that can never be removed. You then add and verify your own custom domains — contoso.com — by publishing a TXT or MX record that Microsoft checks. Only after verification can you assign that suffix to user principal names. Any single domain can be verified in only one tenant at a time, which is why domain verification failures usually mean the name is already claimed elsewhere in your organization.

You will see tenants described by license tier as well. The free tier covers user and group management, basic reporting, and self-service password change for cloud accounts. Premium tiers add capabilities such as conditional access, self-service password reset for accounts synchronized from on-premises Active Directory, dynamic group membership, and identity protection. Because Microsoft revises tier names and feature boundaries regularly, confirm what a specific feature requires in the current licensing documentation rather than trusting a memorized list.

Directory roles are not Azure RBAC roles

This distinction produces more wrong answers than any other topic in the domain. Entra roles — Global Administrator, User Administrator, Groups Administrator, Billing Administrator — grant authority over identity objects: creating users, resetting passwords, managing application registrations. Azure RBAC roles — Owner, Contributor, Reader, Virtual Machine Contributor — grant authority over Azure resources at a management group, subscription, resource group, or resource scope.

A Global Administrator has sweeping power over the directory and, by default, no access at all to Azure resources. There is a deliberate exception you should understand rather than memorize blindly: a Global Administrator can elevate access in the Entra properties blade, which grants them the User Access Administrator role at the root scope so they can recover a subscription that has lost its Owner. It is an emergency mechanism, it is logged, and the elevation should be removed once the repair is done.

Where accounts come from

Accounts in a tenant fall into three broad categories, and AZ-104 expects you to recognize each:

• Cloud-only accounts are created directly in Entra ID and exist nowhere else.
• Synchronized accounts originate in on-premises Active Directory Domain Services and are pushed into the tenant by Microsoft Entra Connect or Entra Cloud Sync. Their source of authority is on-premises, so most attribute edits must be made there; the synchronized copy is read-only in the portal for those attributes.
• Guest accounts are external identities invited into your tenant through business-to-business collaboration. They authenticate against their own home directory and appear in yours as objects of user type Guest.

Hybrid organizations usually combine all three. When a question tells you an account is synchronized and then asks why you cannot change its user principal name in the Azure portal, the answer is the source of authority, not a permissions problem.

Domain services, briefly

Entra ID is not a domain controller. It speaks modern protocols — OAuth 2.0, OpenID Connect, SAML — not Kerberos and LDAP against a domain. Workloads that genuinely need those legacy protocols, such as a lift-and-shift application that must join a domain, use Microsoft Entra Domain Services, a managed domain deployed into one of your virtual networks and populated from the tenant. Recognize it as the answer when a scenario needs domain join or LDAP without on-premises domain controllers, and recognize that it is a separate service you deploy and pay for, not something a tenant provides by default.

What to take away

Identity is separate from resources and joined by trust. Directory roles govern the directory; RBAC roles govern resources. The source of an account determines where you can edit it. Fix those three ideas and the rest of this module — users, groups, licenses, external collaboration, and role assignment — becomes a matter of detail rather than a matter of confusion.