First Steps in Identity and Access Management with Microsoft Entra ID

Identity and Access Management (IAM) is the discipline of proving who someone or something is, and then deciding what that identity is allowed to do. In modern cloud environments, identity has effectively become the primary security boundary: every request to an application, an API or an administrative console is checked against an identity before anything else happens. Microsoft Entra ID

This guide is written for graduates and early-career practitioners who have not yet made a change inside a real identity directory and need to build sound judgement before they do. Rather than starting with commands, it starts with the mental model: what a tenant is, what objects live inside it, and why a small change to a group or a role can have consequences far beyond the object you touched. You will then design, run and safely reverse one bounded exercise, entirely inside an isolated or non-production tenant, with an explicit rollback for every state-changing step.

#Learning Objectives

• Explain the difference between authentication and authorisation within Microsoft Entra ID.
• Identify the core directory objects, tenants, users, groups, service principals and roles, and the trust boundaries between them.
• Describe why role and group changes have cause-and-effect consequences beyond the object directly modified.
• Create and validate a scoped, reversible group and membership change in a non-production Entra ID tenant.
• Interpret command output as evidence rather than assuming success.
• Apply a safe rollback and escalation path before making any equivalent change in production.

#Prerequisites

• Access to an isolated or non-production Microsoft Entra ID tenant used only for validation and learning.
• Confirmation of your current role and permission level in that tenant, and of the installed Microsoft Graph PowerShell version, before applying any change.
• Basic familiarity with command-line tools and reading structured command output.
• An understanding that this guide does not use, request or display real credentials or production data.

#Content

#

The Mental Model: Identity as the Trust Boundary

Before Microsoft Entra ID existed as a product name, the underlying problem it solves already existed: how does a system know that a request genuinely comes from the person or application it claims to come from, and how does it decide what that identity may do next? Authentication answers the first question, proving identity, typically with a password, a certificate or a multifactor challenge. Authorisation answers the second, deciding what an authenticated identity is permitted to access, usually through role or permission assignment. Treating these as two separate checks matters operationally: a user can authenticate perfectly and still be authorised for nothing, and a broken authorisation assignment can grant access to someone who authenticated entirely normally. Distinguishing the two early avoids confused troubleshooting later.

#

Core Objects and Trust Boundaries in Microsoft Entra ID

A Microsoft Entra ID tenant is the outer trust boundary: a dedicated, isolated directory instance associated with an organisation. Everything inside a tenant, users, groups, devices, service principals and the roles assigned to them, is managed within that boundary, and access across tenant boundaries requires an explicit trust relationship rather than happening by default. Users represent people; groups represent collections of users used to simplify access management; service principals and app registrations represent applications and automated workloads rather than people. This distinction matters because an over-permissioned service principal behaves like an over-permissioned administrator account, acting continuously and at scale without noticing an unusual prompt the way a person might. Roles connect identities to permissions: a role assignment grants a defined set of permissions, scoped to a resource, to a user, a group or a service principal. Because groups can hold role assignments, adding a single user to a group can silently grant that user everything the group was ever assigned.

The diagram below summarises these objects and the trust boundaries between them.

#

Cause and Effect: Why Role and Group Changes Propagate

A role or group change rarely affects only the object you edited. Adding a user to a group that already holds a role assignment immediately extends that role’s permissions to the new member, even though you never touched the role itself. Removing a user from a group can just as easily remove access the user still needs, if that access depended on group membership rather than a direct assignment. This propagation is the entire point of using groups for access management, but it means every group or role change should be treated as a change to every current and future member’s access. The safe habit is to check what a group or role currently grants before changing its membership, and to verify the resulting access afterwards with a read-only check, rather than assuming the change did exactly what you intended.

#Examples

#

Worked Example: Creating a Scoped Test Group and Verifying Membership

The following worked example uses Microsoft Graph PowerShell against a non-production Microsoft Entra ID tenant. Confirm the connected context first.

1Get-MgContext

Representative output: a TenantId, Account and Scopes list including Group.ReadWrite.All. This output is evidence, not assumption: it confirms which tenant and account are connected before any write operation. If the TenantId does not match your intended lab tenant, stop here.

1New-MgGroup -DisplayName "lab-iam-test-group" -MailEnabled:$false -MailNickname "labiamtestgroup" -SecurityEnabled:$true

A successful call returns a new group object containing a generated Id and the DisplayName. Treat the returned Id as authoritative evidence rather than the display name, because Ids are unique and names can collide.

1Get-MgGroup -Filter "displayName eq 'lab-iam-test-group'"

This should return exactly one group object matching the filter. Zero or multiple results indicates a naming or scope problem that should be resolved before continuing.

1New-MgGroupMember -GroupId <id> -DirectoryObjectId <testUserId>
2Get-MgGroupMember -GroupId <id>

Adding a member typically returns no content on success, which is not sufficient evidence on its own. The membership addition is only confirmed once Get-MgGroupMember returns an array containing the test user’s object Id: the read closes the loop that the write alone does not.

#Exercises

#

Exercise: Bounded Group Creation, Membership Change and Safe Rollback

Objective: create a disposable group, add a single designated test user, confirm the resulting membership with command evidence, and remove both changes, leaving the tenant unchanged.

Setup: a non-production Microsoft Entra ID tenant, an authenticated Microsoft Graph PowerShell session with Groups Administrator or equivalent scoped permission, and a designated disposable test user that exists only in that tenant.

Steps: confirm context with Get-MgContext; create the group with New-MgGroup; confirm creation with Get-MgGroup; add the test user with New-MgGroupMember; confirm membership with Get-MgGroupMember.

Expected evidence: a tenant-matching context object, a single created group object with a stable Id, and a membership array that contains the test user’s Id after the addition step.

Pass condition: Get-MgGroupMember returns the test user’s object Id inside the group after the addition step.

Stop condition: if Get-MgContext shows a tenant other than the confirmed lab tenant, or if any command returns an authorisation error, stop immediately and do not retry with elevated credentials.

Cleanup: remove the membership, then the group, and confirm removal with a follow-up read that returns a not-found result rather than an object.

#Validation Guidance

Validation in identity systems means treating every step’s command output as evidence to be read, not a formality to be skipped. Before a change, capture what currently exists (an empty search, an absent membership). After a change, capture what now exists and compare it explicitly against what you expected. An unexpected result, an extra object, a missing member, an authorisation error, is a signal to stop and diagnose, not a prompt to retry the same command with broader permissions. The rollback is not complete until a read-only check confirms the object is genuinely gone, because a failed or partial deletion can otherwise be mistaken for success.

#Common Mistakes

Insufficient privilege on a write command. Symptom: New-MgGroup or New-MgGroupMember returns an authorisation error. Cause: the connected account holds a role that does not include group management permission. Diagnosis and correction: re-run Get-MgContext to confirm current scopes, then obtain the correct scoped role in the test tenant rather than escalating broadly. Recovery: no directory state has changed, so no rollback is required beyond re-authenticating.

Membership addition appears to succeed but evidence is missing. Symptom: Get-MgGroupMember returns an empty array after New-MgGroupMember ran without error. Cause: the wrong DirectoryObjectId or GroupId was supplied. Diagnosis and correction: re-confirm both Ids from their own command output rather than from memory, then repeat the addition against the confirmed Ids. Recovery: no incorrect object was modified, so cleanup is unaffected.

A test object survives after cleanup is believed complete. Symptom: the test group or test user still exists after the exercise. Cause: the rollback command was skipped, failed silently, or targeted an incorrect Id. Diagnosis and correction: search by the known test name, confirm the Id, and repeat the deletion against that confirmed Id, followed by a read-only check. Recovery: escalate to the tenant administrator if the object cannot be located or removed with your current permissions.

#Production Bridge

Everything in the exercise scales directly to production, and so does the risk. In production, request the narrowest directory role that permits the task, such as a scoped Groups Administrator assignment, rather than a broad administrative role, and confirm that assignment is time-bound where your tenant supports eligible rather than permanent role assignment. Microsoft Entra ID environments commonly layer additional controls, such as Conditional Access policies and sign-in or audit logging, around administrative actions; the specific controls, licensing tier and default configuration available in any given tenant should be confirmed locally rather than assumed from this guide. Before making an equivalent change against a real directory, identify who owns the affected resource, what evidence you will capture before and after, and who you will notify if the result does not match expectations. If a production change cannot be reversed with a documented rollback step, that is itself a reason to escalate for a second review before proceeding, not a reason to proceed carefully.

#Key Takeaways

• Authentication proves identity; authorisation decides what that identity may do. Most operational failures trace back to one or the other.
• Tenants, users, groups and service principals sit inside layered trust boundaries; a change to a group can silently change access for every current member.
• Command output is evidence: confirm tenant context before writing, and confirm the resulting state with a read-only check afterwards.
• Every state-changing step in this guide has a paired rollback step, and cleanup is only confirmed once a read-only check shows the object is genuinely gone.
• Production identity changes require the narrowest workable role, explicit evidence capture and a named escalation path before you begin.

The next safe decision is to repeat this exact bounded exercise once more in your own lab tenant, from memory rather than by copying commands, before requesting any scoped identity permission in a shared or production directory.