Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
Entra ID Detection and Operations: Course Orientation
Module 0
ENTRA ID IDENTITY DETECTION AND OPERATIONS · MODULE 00
The rule was enabled. It caught nothing. Nobody found out for nineteen days.
Every estate can show you its rules. Almost none can tell you what they caught, and the distance between those two is where identity attacks live now. This course teaches you to read an identity estate and answer the question a rule count cannot: is anything here actually catching anything. You write detections against the four tables identity signal lives in, govern the workload and external identities no interactive control reaches, and run the operations that decide whether any of it works. This module shows you what that involves and how the course gets you there.
Most identity security reporting counts things that exist. Rules enabled, policies deployed, coverage percentages, registration rates. Every one of those numbers can be accurate while an estate is exactly as exposed as it was before, because none of them measures whether anything was caught. An organization can run 214 analytics rules, block 41,200 password attempts in a quarter, report 94 per cent coverage, and lose nineteen days to a stolen session token that one of its own rules detected on day two.
That is not a story about negligence, and it is why this course exists. The rules were correct. The estate was maintained. What was missing was anybody able to say, of a control that was switched on, what it had actually caught and whether it could have. This course teaches that: reading the four tables identity signal lives in, writing detections against evidence that is ambiguous by nature, governing the workload and external identities no interactive control reaches, and running the operations that decide whether a rule can fire at all.
What you will be able to do
This course is built around the estate you can read at the end, not the features you can name. Every module ties a capability to a question somebody will ask you, and has you answer it with evidence rather than assurance.
Write detections that can actually fire
Against the right table, with a threshold you can defend, routed to somebody who will read the result.
Govern the identities nothing reaches
Workload identities, managed identities and guests: the population usually larger than the human one and watched by nothing.
Operate the estate the signal comes from
Log routing designed rather than defaulted, drift caught while it is cheap, and a recovery position tested rather than documented.
Report a number that can go down
Coverage with its denominator attached, and the honesty to say what an estate is not watching for.
The estate you will work in
Every example in this course uses Northgate Engineering, an 810-person firm running Microsoft 365 E5 with Entra ID, Sentinel and Defender XDR. The same estate appears across the platform, so its users, its applications and its bad decisions stay consistent from module to module, and by the end you know what normal looks like there. That matters more in this subject than in most: detection is accumulated context, and a course changing company every module would keep resetting the one thing a detection depends on.
The population section 0.6 counts, and the one module 1 opens on.
How the course is built
Nine modules across four phases. You start with the identities no interactive control reaches, move into governance and the detection engineering that is the longest module in the course, then into the operations deciding whether a detection can run at all, and finish by assembling the whole model and applying it to organizations you have not seen.
The nine modules4 phases
1Workload identityThe identities with no person attached, and the one policy type that reaches themphase 1
2External identitiesGuests, and the cross-tenant boundary in both directionsphase 1
3Identity governanceAccess granted once and never revisited, and reviews that can say nophase 2
4Detection engineeringRules, tuning and coverage. The longest module, and the lens for the restphase 2
5Monitoring and operationsLog routing, and the cadence that reads what it producesphase 3
6Backup and recoveryA recovery position tested rather than documentedphase 3
7Defender XDRIdentity signal correlated with the rest of the estate into one investigationphase 3
8Log routing and retentionWhat is collected, what it costs, and what a tier change quietly removesphase 4
9CapstoneOne identity intrusion, worked end to end in a tenant you did not configurephase 4
What you need and who this is for
There are no prerequisites and every concept is explained the first time it appears. Nothing here assumes you have taken another course, including the one covering the controls this course detects around. This is for anybody who has to answer for what an identity estate is catching: SOC and IR analysts closing identity incidents, detection engineers writing the rules, identity administrators moving from running Entra to defending it, and architects who need the operational half of a design they have already drawn.
A tenant you can read
Read-only access to a real estate is worth more than full control of an empty one, because history is the resource you cannot manufacture. Section 0.10 covers three routes.
No prior KQL
Queries ship as artifacts you run in your own tenant, with the operators they use explained where they appear.
Portal and PowerShell throughout
Entra is a portal and PowerShell product. Configuration questions are answered where configuration lives, not in a log.
Do I already know this material?
Six scenarios across the full range of this course, from which table an identity attack leaves a record in to designing a detection estate somebody else has to run. Answer them to find out where you sit, and whether this course fits or will sharpen judgment you already have.
An account is disabled the day a contractor leaves. Six weeks later it is found to have been reading a SharePoint site throughout. A query of SigninLogs for that account over ninety days returned nothing. What happened?
The account was re-enabled and disabled again without being logged.
SigninLogs retention was shorter than ninety days, so the records aged out.
An application the contractor consented to holds a refresh token, so the access is non-interactive and appears in a different table entirely.
Disabling an account stops the person signing in. It does not revoke a grant the person made, and offline_access gives the application a refresh token. Every one of those accesses was logged, in AADNonInteractiveUserSignInLogs.
Disabled accounts are excluded from sign-in logging by design.
A tenant reports 94 per cent identity coverage, up from 91 last quarter. The calculation is correct and the data is current. Why might that number still be misleading?
Percentages are inherently unreliable for security reporting.
Its denominator is users, which excludes the service principals and managed identities that no user-scoped policy reaches, and the rise can come from hiring rather than from any security work.
Most tenants hold more non-human identities than human ones. A coverage figure taken over users describes the smaller half, and both its numerator and denominator grow with headcount, so the ratio drifts upward on its own.
Coverage should always be reported as an absolute count rather than a ratio.
A three-point rise is within the margin of error for any estate measurement.
Two AuditLogs entries eleven days apart both read "Add service principal credentials", both by the same Application Administrator, both adding a two-year secret. One is a scheduled rotation and one is an attacker. Which field separates them?
The result code, which differs for programmatic and interactive changes.
The client application, which records whether the portal or Graph was used.
The correlation ID, which links the change back to its originating session.
None of them. The records are identical, and what separates them sits outside the audit log entirely.
The attack is the legitimate action performed by the wrong person, so the record is the same. What resolves it is a change ticket, the expiry of the credential being replaced, or the session that made it.
A Sentinel rule for token replay is enabled, correctly written, and has produced nothing in ninety days. What is the first thing to check?
Whether the table it queries is being ingested at all, since a query against an absent table returns an empty set rather than an error.
A rule executing successfully against nothing is not an error, so it shows healthy in every rule report. The check is to compare the tables your rules depend on against the categories your tenant actually emits, in Diagnostic settings.
Whether the rule's schedule overlaps its lookback window.
Whether the analytics rule has drifted from its template version.
Nothing. A rule that has not fired in ninety days is evidence the control is working.
You are designing a detection that fires when a privileged role is assigned outside PIM, and joins against your change management system to suppress documented changes. What is the strongest argument against relying on that join?
Change systems rarely expose an API, so the join has to be manual.
An attacker with access to the change system can create the record that clears their own change, so an unauthenticated write path makes the suppression a liability rather than a control.
The join has to be against a source the attacker cannot write to. Queryable and trustworthy are separate properties, and a detection that suppresses on an unverified record is worse than one with no join at all.
Timing skew between the two systems makes correlation unreliable.
Change records do not carry enough detail to match a specific role assignment.
A Conditional Access rollout plan targets eight directory roles and states that 38 of 41 holders are already registered for a phishing-resistant method, so the blast radius is three. The estate also holds eleven accounts eligible for those roles through PIM and four service accounts with Exchange Administrator. What is wrong with the plan?
Nothing. Eligible accounts are out of scope until they hold the role.
The plan should have targeted groups rather than roles, which would have caught the service accounts.
The blast radius is understated: eligible users enter scope at the moment of activation, and the service accounts cannot present a phishing-resistant method at all because there is nobody to present one.
Counting current role holders misses everyone who can become one, and it misses the population for which the control is impossible rather than merely unregistered. Both land at the worst moment, which is during an activation somebody needed urgently.
Report-only for fourteen days is too short a window to establish impact.
This course is for you.
You will go from the four tables identity signal lives in, through writing detections for the attacks that defeat a tenant with MFA enabled, to governing the workload identities nothing reaches and running the estate that produces the signal.
You have the fundamentals. The value here is the harder half.
You know where identity signal lives and why a rule can be correct and inert, so the payoff is the back half: detection engineering against ambiguous evidence, workload and external identity governance, log routing designed rather than defaulted, a recovery position that has been tested, and correlating identity across the Defender estate.
You are reading identity evidence the way somebody does who has been burned by it. What this course adds is the parts that are nobody's job: the workload population no control reaches, the ingestion decision that quietly kills a detection, and a coverage figure you can defend to somebody who will act on it.
You are a student of this course now, so start by deciding what you want from it. Are you here to close identity incidents faster, to build a detection estate that can be shown to work, or to take responsibility for an identity estate somebody has handed you? Name that outcome, then turn it into a plan: which modules matter most to your environment, how much time you will give it each week, and what you want to be able to say about your own tenant by the end.
The rest of Module 0 sets you up to do that. Work through it to see where identity signal actually comes from, what a detection consists of once you look past the query, which attacks reach a tenant where every control is working, and why the evidence for them is ambiguous by nature. Then section 0.10 gets you an environment, and module 1 starts on the population this module counted and nothing in a tenant reaches.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
