Microsoft EntraID

Why This Topic Matters

Microsoft Entra ID is the cloud identity backbone for Azure, Microsoft 365 and many SaaS apps. Understanding its object model, licensing tiers and administration boundaries is essential for secure design, correct operations, and exam preparation (AZ-104 / identity topics).

Licenses (at a glance)

License	Intended scenarios	Key features
Free	Any Azure / M365 subscription	Users & groups, unlimited SSO for Microsoft cloud apps, Security Defaults (basic MFA), basic B2B
P1	Hybrid and advanced management	Everything in Free + Conditional Access, SSPR (with writeback), Dynamic groups, Administrative Units, advanced sync features
P2	Protection and governance	Everything in P1 + Identity Protection (risk-based policies), PIM, Access Reviews

Tip: remember what requires P1 (dynamic groups, AUs, Conditional Access) this is a common exam trap.

Tenant

• A tenant is a dedicated Entra ID instance (directory) that contains users, groups, devices and applications.
• Default domain: <tenantname>.onmicrosoft.com. Add and verify custom domains via TXT/MX records.
• Relationship with subscriptions:
  • 1 tenant ↔ multiple subscriptions
  • 1 subscription ↔ a single tenant at a time (can be transferred)
• Users can access multiple tenants (guests or linked accounts).

Identity Types

Users

• Cloud-only: created in Entra directly.
• Hybrid: synchronized from on-prem AD via:
  • Entra Connect Sync: full-featured agent, supports password and device writeback, requires on-prem resources.
  • Entra Cloud Sync: lightweight, highly available agents; supports password sync but not device/Exchange writebacks (Microsoft’s strategic direction).
• Guest (B2B): invited external users with limited access.

Bulk operations: Users > Bulk operations supports CSV-based bulk create/invite/delete/restore (async jobs, templates provided).

Applications

• App registration creates an Application object (publisher tenant) and a Service Principal (tenant instance, visible under Enterprise Applications).
• Authentication methods: client secrets (strings) or certificates (recommended for production).

Common traps:

• App Registration = you define an app. Enterprise Application = you use an app (service principal).
• Third-party SaaS often appears only as an Enterprise Application in your tenant (the publisher owns the App Registration).

Examples:

• Redirect URI (example): https://myapp.example.com/auth/callback must match exactly what you register.
• Client secret rotation: create secret → note value (visible once) → rotate before expiry, then update app settings.
• Delegated vs Application permission: User.Read (Delegated) reads profile for the signed-in user; User.Read.All (Application) lets the app read all users without a user present (requires admin consent).
• Verify service principal: check Enterprise applications for the app instance, or run az ad sp show --id <app-id>.

Managed Identities

• Provide identities to Azure resources without credentials (auto-rotated).

Type	Lifecycle	Reusable	Use case
System-assigned	Bound to resource	❌	Single VM needing Key Vault access
User-assigned	Independent resource	✅	Pool of VMs or Functions sharing one identity

Auth test examples (from a VM):

az login --identity                      # system-assigned
az login --identity --username <client-id-UA>   # user-assigned

Groups

Type	Members	Usage
Security	Users, devices, groups, service principals	Permissions (RBAC, app access, policies)
Microsoft 365	Users (+ guests)	Collaboration (Teams, SharePoint, mailbox)

Membership types:

• Assigned: manual.
• Dynamic user/device: rule-based membership (P1 required).

Important rules:

• Dynamic groups require P1 and cannot mix users and devices in the same rule.
• A dynamic group is fully rule-driven, you cannot manually add members.

M365 group naming & expiration (example):

• Naming policy: tenant policy can enforce prefixes/suffixes and block words. Example: policy prefix=GRP_; suffix=_[Department]; blocked=test,admin transforms Project Q3 created by José (Dept=Marketing) into GRP_Project Q3_Marketing and rejects blocked names like test team.
• Expiration policy (example): tenant-wide 180d policy forces renewal; if not renewed, the group is deleted and recoverable for 30 days.

Devices

Devices are identity objects that enable Conditional Access and SSO on trusted machines.

Type	Target	Auth	Example
Entra Registered	BYOD	Personal/Entra account	Personal iPhone adding a work account
Entra Joined	Corp cloud-only	Direct Entra login	New corporate laptop joined at OOBE
Hybrid Entra Joined	On-prem AD + Entra	On-prem login then Entra	Domain-joined PC synced via Connect

Join path: Settings > Accounts > Access work or school > Connect (Hybrid join configured via Entra Connect device options).

Device settings to review: Entra > Devices > Device settings (who can join, max devices/user, MFA for join, local admin settings).

Administrative Units (AU)

• AUs provide tenant segmentation for delegated administration, similar conceptually to on-prem OUs.
• P1 required.
• Members: users, groups, devices. An object can belong to multiple AUs. AUs cannot be nested.
• Roles can be assigned scoped to an AU to delegate administration without granting Global Admin.

Restricted Management AU: a locked variant that prevents modifications even by Global Admins unless they have a role on the AU, useful to protect break-glass or VIP accounts. This option is irreversible for the AU; to undo you must recreate it.

License assignment methods

Three common ways to assign licenses:

Method	How	Note
Direct	User > Licenses > Assign	Simple but not scalable
Group-based	Assign license to a group	Scales; P1 required for some features. Each member consumes a license (deduplication applies)
Bulk	Multi-select users → Assign	Useful for one-off operations

Frequent traps:

• Users need a Usage Location set (country) before some licenses can be assigned (licenseAssignmentNotAllowed).
• Duplicate service plans across licenses can conflict; use Reprocess when assignments error.

Portal paths & common traps (practical)

• Main admin center: entra.microsoft.com (or portal.azure.com, search “Microsoft Entra ID”).
• Tenant creation: Entra > Overview > Manage tenants > Create (creator is Global Admin).
• Subscription directory change: Subscription > Change directory (RBAC must be reconfigured after move).
• App registration tips: Entra > App registrations > New registration, pay attention to supported account types, redirect URIs, and secret vs certificate choices.
• Custom domain: Entra > Custom domain names > Add then verify with TXT/MX.

Quick commands to validate identities and managed identities:

az ad user show --id user@domain.com
az ad sp show --id <app-id>
az login --identity

Practical takeaways

• Use group-based assignments and least privilege for access control.
• Prefer certificates for production app authentication; rotate secrets regularly.
• Use Managed Identities for automation instead of long-lived credentials.
• Reserve P1/P2 features (dynamic groups, AUs, Identity Protection) for scenarios that need them.

---

This post condenses the core Entra ID concepts, administration notes, and practical portal tips for quick reference and study.