Entra ID Automation #1 The Big Picture: Tenants, Directory Objects, and the JML Lifecycle
In the Microsoft Graph in Practice series we drove mail, files, and Teams with code. This track goes one layer down: automating identity management itself. Account creation, group management, access policies, privilege grants. It is the most repetitive area of IT operations, the one where mistakes cost the most — and therefore the one where automation pays back most reliably.
Entra ID: the current name for Azure AD #
Names first. Microsoft Entra ID is the current name for Azure Active Directory (Azure AD). It was renamed in 2023; the product itself is continuous. Older documentation and tool names (the AzureAD PowerShell module, for instance) still carry the old name, so you need both names when searching.
What Entra ID does fits in one sentence: a cloud directory that manages, at the organization level, who can sign in (authentication) and what they may do (authorization). Every Microsoft 365 sign-in passes through it, your SaaS SSO can hang off it, and so can sign-in for the apps you build. Note that on-premises Active Directory (AD DS) is a different product. Many organizations synchronize the two, but this series covers the cloud side — Entra ID.
The directory’s structure: a tenant and four kinds of objects #
To know what you are automating, get the structure straight.
- Tenant: one organization’s directory instance. When a company signs up for Microsoft 365, a tenant is created, and everything is managed inside that boundary.
- Users: employee accounts and external collaborators (guests). They carry attributes like
userPrincipalName,employeeId, anddepartment— the fuel for the automation we build later. - Groups: the unit for distributing permissions, licenses, and app access. Two kinds: security groups and Microsoft 365 groups.
- Applications (app registrations / service principals): non-human principals. Your automation scripts run under an app identity registered here.
- Devices: PCs and mobile devices registered to the organization — the basis for Conditional Access decisions like “is this a company-managed device?”
For automation, this structure means one thing: every object is a resource you can query, create, and modify through an API. Everything done by clicking in the admin portal has a corresponding Graph endpoint.
JML: the backbone model of account automation #
Account administration reduces to three flows, known by the industry term JML (Joiner-Mover-Leaver).
| Stage | Situation | Work |
|---|---|---|
| Joiner | A new member arrives | Create the account, assign licenses, place into groups, deliver initial credentials |
| Mover | Department or role change | Revoke old access, grant new access, update attributes |
| Leaver | A member departs | Block access, reclaim licenses, transfer data, clean up the account |
Everyone knows what happens when these run on manual labor: joiners spend their first week without permissions, movers carry their old department’s access around, and leavers’ accounts stay alive for months. That last one is not an inefficiency — it is the standard opening scene of a security incident. Parts 2 (user lifecycle) and 3 (groups) turn JML into code.
The tooling landscape: what do you automate with? #
Entra ID automation tools sort into three layers.
- Microsoft Graph API: the foundation of everything. REST endpoints (
https://graph.microsoft.com/v1.0/...) plus per-language SDKs; this series’ code is Graph-based. Python SDK setup was covered in Graph in Practice #3. - Microsoft Graph PowerShell: the working standard for admin tasks. The
Connect-MgGraphfamily of cmdlets wraps the Graph API. For one-off cleanups and admin scripts, this path is faster. The old AzureAD and MSOnline modules are on the way out — do not use them in new scripts. - IaC (Terraform and friends): for things that are “configuration” — groups, Conditional Access policies, app registrations — declaring them as code and applying through review fits best. Policy-as-code returns in part 4.
The rule of thumb: recurring lifecycle work → Graph API (scripts, services); one-off admin work → PowerShell; stateful configuration → IaC.
Licensing: features are tied to tiers #
Design Entra automation without knowing the license tiers and you meet the “built it, but our tenant can’t run it” moment. The broad strokes:
| Tier | Features relevant to this series |
|---|---|
| Free (included with M365) | User and group CRUD, basic SSO |
| P1 | Dynamic groups, Conditional Access, self-service group management |
| P2 | P1 + PIM (headline feature), Identity Protection, access reviews |
| Entra ID Governance | Lifecycle workflows, advanced entitlement management |
Each feature’s required tier is called out as it appears in the series. Make “what is the minimum license this automation requires” a design-stage question.
Prerequisite: an app identity for automation #
The code in this series assumes automation that runs without a signed-in human, which means an app registration operating with application permissions. The setup procedure and the delegated-versus-application distinction were covered in detail in Graph in Practice #2 — follow that as-is. Two extra points for this track:
- Minimum permissions per purpose. User management automation needs
User.ReadWrite.All, but a read-only reporting script must not have it. Splitting apps by automation purpose shrinks the blast radius. - Certificates over client secrets, and managed identities where possible. Automation running inside Azure can eliminate the secret entirely.
The map of this series #
| Part | Topic |
|---|---|
| 1 (this post) | Structure, JML, tooling, licensing |
| 2 | User lifecycle: creation, disabling, licenses, lifecycle workflows |
| 3 | Groups: dynamic groups, group-based licensing, access management |
| 4 | Conditional Access: managing policy as code |
| 5 | PIM and auditing: eliminating standing admins, log automation |
Summary #
- Entra ID is Azure AD’s current name — the cloud directory for an organization’s authentication and authorization, distinct from on-premises AD.
- Users, groups, apps, and devices inside a tenant are the automation surface, and every portal action has a Graph API counterpart.
- The backbone of account automation is the JML model. A missed leaver is a security incident, not an inefficiency.
- Split tooling: recurring work = Graph API, one-off admin = PowerShell, configuration = IaC.
- Dynamic groups and Conditional Access need P1; PIM and access reviews need P2; lifecycle workflows need Governance. Check before designing.