0.1 What Identity and Access Management Decides

Introduction

Every time a person opens an application at work, three separate decisions have already been made. Someone decided how that person proves who they are. Someone decided what the application may do on their behalf.

Someone decided whether this person may use the application at all. Identity and access management is the work of making those three decisions well, recording them, and being able to read them back when access goes wrong.

This lesson covers each decision in turn, how an administrator's own access is decided, where each decision is recorded, and who this course is written for. Northgate Engineering's tenant supplies the examples: 820 members, 8 guests and the applications they use.

Authentication is the process of proving you are who you say you are. Authorization is granting an authenticated party permission to do something. In Entra ID, authorization is split again, because an application acts for a person, and the application's permissions and the person's permissions are granted separately.

So a single request, an engineer opening the site reporting application to submit a day's report, passes three gates. First, the sign-in: the engineer proves who they are, and Conditional Access decides whether that proof is enough for this application from this device.

Second, consent: the application was granted, once, permission to read the engineer's profile so it can show their name. Third, assignment: the application only admits people who were assigned to it, and the engineer is a member of the group assigned the Site Engineer role.

The three gates are kept apart for a reason. They are owned by different people. Authentication policy is usually the identity team's. Consent is granted by an administrator, or by users themselves where the tenant allows it, typically when the application is first set up. Assignment is often delegated to the application's owner, who knows which people need it.

Because they are separate, they fail separately, and the failure looks different each time. A failed sign-in shows an error in the sign-in log and the user never reaches the application. A missing consent shows a consent prompt, or an error asking for administrator approval.

A missing assignment is refused after the user's password and second factor were accepted: the sign-in log records a failure with error 50105, saying the user is not assigned to a role for the application.

That difference matters for troubleshooting. A user who says "I can't get into the app" might have a password problem, a consent problem or an assignment problem, and the fix for each is in a different place:

Reading which gate refused them comes before changing anything, and the rest of this course trains that habit. Changing the wrong gate is worse than doing nothing: adding a user to a group when the real fault was a blocked sign-in grants access they may not need, and leaves the original fault in place for the next person who meets it.

Every sign-in to Entra ID is recorded, and the record says how the person proved who they are. Interactive sign-ins, where a person types or approves something, are kept apart from the background sign-ins applications make on their behalf, and both are kept apart from sign-ins by applications and workloads acting as themselves. This is the sign-in for Karen Foster opening SharePoint on the morning of 20 October:

The Authentication Details tab lists each step. Her password was checked first, against the hash that Password Hash Sync copies from Active Directory, and then she approved a notification in Microsoft Authenticator on her phone. The Conditional Access tab shows why the second step happened: a policy that requires multifactor authentication for all users applied and was satisfied.

The record is complete for its own question. It shows which factors were used, which device she used, whether that device was compliant, which policies applied, and the result. It does not show whether she can open a particular document library, because SharePoint decides that from its own permissions after the sign-in.

The record also says what was not checked. There is no risk detail on this row, no session control and no failure, so this sign-in needs no investigation; it is the shape a normal morning sign-in takes, and recognizing that shape quickly is what makes the abnormal one stand out when it appears.

Authentication is also where most of an identity team's policy lives. Which methods a person may register, how they recover a lost one, which sign-ins need a second factor or a compliant device, and which are blocked outright are all authentication decisions. They apply before any application sees the user, which makes them the broadest controls the tenant has and the ones most able to lock everyone out at once.

When a sign-in fails, the same tabs explain why: which step failed, with what error, and which policy demanded the step. Reading them is quicker and more reliable than asking the user what they saw.

Nearly every user in this tenant signs in with a password checked against Active Directory, because 818 of its 828 accounts are synchronized from there. That one fact shapes a lot: a password changed in Active Directory changes the cloud sign-in, and an account disabled there is disabled in the cloud only after the next synchronization.

An application that calls an API, such as Microsoft Graph, needs permission to do so. A delegated permission lets the application act as the signed-in user, limited to what that user could do. An application permission lets it act as itself, with no user present. Consent is the act of granting either.

Consent can be given by a user for themselves, if the tenant allows it, or by an administrator for the whole organization. Every delegated grant in Northgate's tenant can be read in one command, which replaces the service principal IDs with their names:

PS C:\> Connect-MgGraph -Scopes "Directory.Read.All" -NoWelcome
PS C:\> $sp = @{}
PS C:\> Get-MgServicePrincipal -All | ForEach-Object { $sp[$_.Id] = $_.DisplayName }
PS C:\> Get-MgOauth2PermissionGrant -All | Sort-Object ConsentType |
    Format-List @{n="Client";e={$sp[$_.ClientId]}}, ConsentType, Scope

Client      : Adobe Acrobat Sign
ConsentType : AllPrincipals
Scope       : User.Read Files.Read

Client      : Autodesk Construction Cloud
ConsentType : AllPrincipals
Scope       : User.Read Files.Read.All

Client      : Miro
ConsentType : AllPrincipals
Scope       : User.Read openid profile

Client      : Smartsheet
ConsentType : AllPrincipals
Scope       : User.Read openid email

Client      : Zoom
ConsentType : AllPrincipals
Scope       : User.Read Calendars.ReadWrite

Client      : DocuSync Pro
ConsentType : Principal
Scope       : Mail.Read Mail.Send Files.ReadWrite.All offline_access

Client      : Mail Reader Pro
ConsentType : Principal
Scope       : Mail.Read Mail.ReadWrite Contacts.Read offline_access

Five applications were granted delegated permissions for all users, by an administrator, and each grant lists its scopes as one space-separated string. Two were granted by a single user for themselves: Mail Reader Pro by Catherine Richardson and DocuSync Pro by Elena Petrova, each with permission to read mail, and DocuSync Pro also to send it.

Those two grants are why this course spends time on consent settings: a user consenting for themselves can hand an application access to their own mail without anyone else deciding.

The same grants are visible on each application's page in the admin center, which is how most reviews start:

Reading a grant means reading three things together: which application holds it, whether it covers everyone or one person, and what the scopes allow. User.Read lets an application read the signed-in user's own profile, which nearly every application needs. Files.Read.All lets it read every file the user can read, which is a different order of access, and the grant to Autodesk Construction Cloud includes it for every user in the tenant.

Consent is granted once and then reused. The next time any Northgate user opens Autodesk Construction Cloud, nobody is asked; the grant from when it was set up still applies. That is convenient, and it is why a grant made carelessly lasts: nothing about daily use prompts anyone to look at it again.

Consent also does not decide who may use the application. Microsoft's guidance is explicit that access can still be limited after tenant-wide consent, by requiring assignment. Consent is about what the application can do; assignment is about who can make it do it.

An enterprise application has a setting that decides whether everyone in the tenant can sign in to it, or only those assigned. Northgate's site reporting application requires assignment:

Assignment is made to a user or a group, and where the application defines roles, to a role. NGE Site Reporting defines two, Site Engineer and Site Manager, and the application reads which one a user has from the token it receives. Reading its assignments shows one group with the engineer role and one user with the manager role:

PS C:\> Connect-MgGraph -Scopes "Application.Read.All" -NoWelcome
PS C:\> $sr = Get-MgServicePrincipal -Filter "displayName eq 'NGE Site Reporting'"
PS C:\> $sr.AppRoleAssignmentRequired
PS C:\> Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $sr.Id |
    Format-Table PrincipalDisplayName, PrincipalType, CreatedDateTime

True

PrincipalDisplayName           PrincipalType CreatedDateTime
--------------------           ------------- ---------------
SG-App-SiteReporting-Engineers Group         2/11/2025 9:42:18 AM
Gareth Brown                   User          2/11/2025 9:44:03 AM

Two details in that output are worth reading. PrincipalType says whether the assignment is to a group or a user, which decides how it changes over time. CreatedDateTime says when the assignment was made, and in the audit log, by whom.

The group assignment is the normal pattern: membership of the group decides who can submit reports, so the application's owner manages a group rather than the application. Gareth Brown holds the manager role directly, which is the exception worth noticing. A direct assignment survives a change of job that a group membership based on department would not.

Each assignment row also has a date, and the dates here are the day the application was set up in February 2025. A row that old is not wrong, but it is a decision nobody has revisited, and the person who made it may have moved on. Knowing when and by whom an assignment was made is half of deciding whether it still belongs.

When assignment is not required, the application is open to every account in the tenant, including guests, which is often fine for a tool everyone uses and rarely fine for one holding finance or personnel data. The setting is a single switch, and turning it on for an application already in use locks out everyone not yet assigned, so the assignments go in first.

Assignment is also what most access reviews, joiner and leaver processes and group designs exist to maintain. The question "should this person still have this?" is nearly always a question about an assignment or the group membership behind it.

The three decisions above govern ordinary users. Administrators are governed by directory roles, which decide what each one may change in the tenant. Northgate has 9 active and 8 eligible role assignments across 10 accounts. Active means in force now; eligible means the person must activate the role, usually for a few hours and with a reason, before it applies.

A role can be scoped. Most are assigned across the whole tenant, but some can be limited to an administrative unit, a set of users or groups, so that a regional help desk can reset passwords only for its own region. Northgate's assignments are all tenant-wide, which is common and is one of the things this course examines.

Global Administrator can change anything, and three accounts hold it permanently: two named administrator accounts and the emergency access account. Most tasks need far less. Reading sign-in and audit logs needs Reports Reader; creating groups needs Groups Administrator; managing Conditional Access needs Conditional Access Administrator. Microsoft publishes the least privileged role for each task, and this course names it for every build.

Roles meet consent when an administrator uses a tool such as Graph PowerShell, because the tool is an application acting for the person. A delegated call succeeds only if the tool was granted the permission and the person holds a role that allows the action. Microsoft's documentation for listing sign-ins states both requirements:

The same intersection protects the tenant.

A colleague who copies your script cannot use it to read sign-ins unless they also hold a suitable role, however broad the tool's grant has become over the years. And an administrator who holds Global Administrator but connects with a narrow scope can only do what that scope allows in that session, which is why this course always connects with the smallest scope a task needs.

This is the reason a script run by one administrator works and the same script run by a colleague fails, even on the same machine. The tool's grant is shared; the role is personal. When Graph refuses a call, the first question is which of the two was missing.

Each decision leaves a record in a different place. Sign-ins are in the sign-in logs. Consent, assignments and role changes are in the audit logs, each under its own activity name:

Being able to read these records back is the practical core of the job. When access goes wrong, the first step is finding which decision refused it, and that is a matter of reading the right log. When access is too broad, the first step is finding when it was granted and by whom, and the audit log has the actor, the time and the target.

Reading a record well means reading all of it. An audit entry for a consent shows who consented, to which application, which permissions, and whether it was for everyone or for themselves. An entry for a role assignment shows who assigned it, to whom, and whether it was active or eligible. The summary line in the list rarely carries enough; the detail pane does.

The logs are not kept forever. Entra ID keeps them for seven days on the free tier and thirty days with a P1 or P2 license, and anything older is gone unless it was exported. That limit shapes how an identity team works: a question about a change made two months ago can only be answered if someone arranged, in advance, to keep the logs.

The two logs also answer different kinds of question. The sign-in log answers questions about people using access: who signed in, from where, and whether they were let in. The audit log answers questions about people changing access: who granted, assigned, removed or reconfigured something. An investigation almost always needs both, because a change in the audit log explains a pattern that appears in the sign-ins afterwards.

The logs also make the course's practice possible. Every build in this course ends by reading back what it changed, from the audit log or from Graph, so the result is proved by the record rather than assumed from the configuration screen. A setting that looks right and a setting that produced the expected sign-in are two different claims, and only the second is evidence.

This course is written for the person who will run an organization's Entra ID: an identity engineer, a Microsoft 365 administrator taking on identity, or a security engineer who needs to configure and troubleshoot it rather than only monitor it. The work is building and configuring, and every lesson ends with something to build.

The course covers workforce identity: the employees, contractors, partners and workloads of one organization. Customer identity, where an organization lets consumers or business customers sign in to its own applications, uses a different kind of tenant configured in a different way, and is left out on purpose. Partner and guest access, which most organizations need every week, is covered in full.

No prior Entra ID administration is assumed. The early lessons explain the objects and how they relate before anything is changed, and every build lists the role, the license and the cost it needs before its first step. What is assumed is willingness to read output carefully: most of the skill this course teaches is reading what Entra ID recorded and saying what it means.

Hybrid identity is covered because most organizations still have Active Directory and synchronize it to Entra ID, as Northgate does. If you have no Active Directory, the hybrid builds can be done as build plans, and everything else stands on its own.

The course runs in order. The first modules build the tenant's foundations: its structure, its administration and recovery, its users and groups, and how people sign in. The middle modules control access: Conditional Access, applications, workloads and partners. The later ones connect Active Directory, govern privilege and run the tenant day to day. Each module ends with an exercise where something has gone wrong and the evidence says what.

Each lesson teaches Entra ID first and uses Northgate's tenant as the worked example. The configuration, records and outputs shown come from that one tenant throughout, so a finding in one lesson can be checked against the evidence in another.

The build reads an application in your own tenant the way this lesson read Northgate's. It changes nothing.

PS C:\> Disconnect-MgGraph

Keep what you wrote down. It is the first entry in a record of your lab tenant that later builds add to.

Access in Entra ID is three decisions: how a person signs in, what an application was granted, and who is assigned to use it.

Administrators are governed by roles, and a delegated tool needs both its grant and the person's role. Each decision is recorded in its own log, and reading the right one is the first step in every fault. If you do one thing in your own tenant, list every delegated grant and read who consented to each.

Resources

Microsoft revises these pages; where a page and this lesson disagree, the page is newer.

• Microsoft Learn: Authentication vs. authorization
• Microsoft Learn: Overview of user and admin consent
• Microsoft Learn: Assign users and groups to an application
• Microsoft Learn: Least privileged roles by task