What Identity Operations Actually Involves

Introduction

Configuring an identity estate is a project with a completion date. Operating one is a cadence with none. You will finish this section able to say what operations consists of in Entra ID specifically, why an estate drifts even when nobody changes anything, and which of the four operational questions your organization can currently answer.

The scenario is not a story about negligence. Every one of those four states was produced by somebody doing something reasonable, and in three of the four the person doing it was not on the identity team.

It is worth separating drift from decay, because they need different answers. Decay is a thing degrading on its own: a certificate expiring, a secret ageing, a guest account outliving the relationship that created it. Drift is somebody moving the configuration, correctly, for a reason that made sense in their context.

Decay can be automated against, because the expiry date is a fact in the directory and a script can find it. Drift cannot, because there is no field recording what the configuration was supposed to be. That is why id06 builds a baseline: without one, drift is only visible to somebody who remembers.

Policies stay in report-only because report-only is where they are supposed to start, and the step that promotes them is a decision somebody has to make rather than a task a system schedules. A policy left in report-only is indistinguishable from a policy correctly under evaluation, and there is no expiry on the evaluation.

Credentials get replaced with longer ones because an expiry caused an outage and the person fixing it at eleven at night set the next one to the maximum the interface offered. That is the rational local decision and it happens once per outage.

Diagnostic settings get switched off during cost reviews, by somebody who can see the bill and cannot see the four rules that depended on the table, which section 0.1 walked through.

And things stop being tested because testing has no forcing function. A break-glass account nobody signs into produces no alert, no error, and no evidence that anything is wrong, right up until the moment it is needed.

A fifth mechanism is the least obvious: the platform itself changes. Blades get renamed, features retired, defaults changed for new tenants. A configuration correct when documented becomes wrong without anybody touching it, and the announcement was a message center post somebody may or may not have read.

Which means the useful question is not how to prevent drift but how quickly it becomes visible. That is a cadence question rather than a control question, and it is the reason this half of the course looks like a schedule rather than a set of policies.

Stripped of the process language, identity operations is four questions asked repeatedly, and the useful frame is how often each one needs asking rather than what it is called.

Is anything firing is the daily question and it is the one every SOC already asks. It covers the queue, the alerts in it and whether anybody worked them.

Is the signal still arriving is weekly, and it is the question section 0.1's estate never asked. It is not about alerts, it is about whether the tables the alerts depend on are still receiving rows, which per section 0.2 is a different check with a different answer.

Has the estate drifted is monthly. What changed in Conditional Access, which credentials are approaching expiry, which service principals appeared, which policies are still in report-only.

Can we still recover is quarterly and it is the break-glass test, the policy backup and the question of whether anybody has ever restored one.

The asymmetry in that figure is the whole point. Daily has a queue, so it happens: alerts arrive, somebody works them, and the absence of that work is visible within hours. Quarterly has nothing, so the break-glass test that was scheduled after handover was never rescheduled when the project team left, and its absence produced no signal for fourteen months.

It is worth noticing that all four questions can be answered by one person in under an hour, and that the difficulty is never the answering. The difficulty is that three of the four have no trigger: nothing arrives to prompt them, nobody notices when they do not happen, and the work competes with everything that does have a trigger.

id05 and id06 between them build the two right-hand questions into something with a forcing function, which is most of what operational design means here.

Section 0.1 argued that detection and operations are one course because a rule nobody routes is not a detection and a log nobody reads is not telemetry. The place those two meet is log routing, and it is worth being concrete about what that means.

A tenant decides which log categories to emit, where to send them, and how long to keep them. Those three decisions determine what every detection in the estate can see, and all three are made in a blade that belongs to operations rather than to detection.

Each of the three has a failure mode that looks like success. A category not emitted produces an empty table rather than an error. A destination that is a storage account rather than a workspace produces data nobody can query with a detection rule. And retention shorter than the investigation window produces a query that runs correctly and finds nothing, because the evidence aged out before anybody asked.

All three are configuration rather than detection, which is why an organization that separates the two functions ends up with detections designed against assumptions about data that nobody on the detection side can verify.

union withsource=TableName
    SigninLogs, AADNonInteractiveUserSignInLogs,
    AADServicePrincipalSignInLogs, AuditLogs
| where TimeGenerated > ago(14d)
| summarize rows = count(), lastRow = max(TimeGenerated) by TableName
| extend hoursQuiet = datetime_diff("hour", now(), lastRow)
| sort by hoursQuiet desc

// A table missing from these results entirely is the finding.
// It cannot appear as a row saying zero, because a union skips what does not exist.

That last comment is the trap and it is worth reading twice. A table receiving nothing does not return a zero, it returns no row at all, so the check has to compare the results against a list of tables you expect rather than reading what comes back.

Retention is the decision people underestimate. A ninety-day retention means an investigation into something that started four months ago has no evidence, and per section 0.6 the identities that sit unexamined for years are exactly the ones whose history you eventually want. id05 treats retention as a detection design constraint rather than as a storage setting, because it decides how far back any question can reach and it is set by whoever manages the workspace budget.

The break-glass account in the scenario existed, was created correctly, and had a password in a safe. What it did not have was evidence that any of that was still true.

Break-glass accounts exist because every other path into the tenant can fail. A Conditional Access policy misconfiguration can lock out every administrator, a federated identity provider outage can prevent anybody authenticating, and an MFA service disruption can do the same. The break-glass account is the account excluded from all of that, holding Global Administrator, with a long password nobody uses.

The design is well understood and most tenants have one. The part that fails is not the design, it is that the account sits untouched for years while everything around it changes: policies are added, exclusions are edited, the safe moves office, and the person who set it up leaves.

An untested recovery control is a belief. Nobody knows whether the password in the envelope matches the one on the account, whether the account is still enabled, whether a Conditional Access exclusion added since still holds, or whether the person who knows the safe combination still works there. Each of those has failed somewhere.

Connect-MgGraph -Scopes "AuditLog.Read.All","RoleManagement.Read.Directory"

$upn = "admin.break1@northgateeng.com"

Get-MgAuditLogSignIn -Filter "userPrincipalName eq '$upn'" -Top 1 |
  Select-Object CreatedDateTime, Status

Get-MgDirectoryRole -All |
  Where-Object { (Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id).AdditionalProperties.userPrincipalName -contains $upn } |
  Select-Object DisplayName

# CreatedDateTime  Status
# ---------------  ------
# (no results)             <-- never signed in, so nothing has ever been proved
#
# DisplayName
# -----------
# Global Administrator

Two things about that check are worth knowing. It uses read-only Graph permissions, so establishing the position costs nothing and requires no privileged access. And it deliberately asks two separate questions: whether the account has ever authenticated, and whether it still holds the role it is supposed to hold. Either can be wrong independently, and an account that holds the role and cannot sign in is the more dangerous of the two because it looks correct in every report.

No results in the first query is the finding. The account holds Global Administrator and has never authenticated, so every property it depends on is unverified, and the first test will be the incident.

id06 builds the test into something with an artifact, because a break-glass test leaving no record has the same problem as the account it was testing. The artifact is the point: a dated file saying who signed in, what worked and what did not, is the only thing that distinguishes a tested control from an assumed one twelve months later.

The four findings from the scenario are below with what changed, who changed it and what it affected, which are three different people in three of the four cases.

Work down the changed column first and notice how ordinary each entry is. A cost review that switched off a log category. An out-of-hours fix that replaced an expiring credential with a longer one. A policy left where policies are supposed to start. A password in a safe that nobody had reason to open.

Read the initiator column against the affected column. In three of the four the person who made the change had no way of knowing what it touched, and in the fourth nobody made a change at all: the policies stayed in report-only because promoting them required an action that was never anybody's task after the project closed.

The diagnostic setting row is the one with the longest reach. Switching off a category is one action, it takes seconds, and its effect is that every rule depending on that table stops being able to return anything, silently and indefinitely. Nothing else in this list disables four detections at once.

The credential row is the one worth dwelling on. Thirty-one credentials expired and were replaced, which is the system working: expiry is the forcing function that made somebody look. What the system did not do was make the replacement any shorter than the maximum, so the same forcing function will not fire again for five years, and the thirty-one identities that were reviewed in a crisis are now unreviewable until 2031.

That distribution is why operations is a design problem rather than a diligence problem. Asking people to be more careful does not help when the careful person cannot see the consequence of the thing they are being careful about, and the fix in every one of these four rows is to make the consequence visible at the moment of the change rather than fourteen months later.

A monthly check that exists in a runbook and does not happen is worse than no check, because the runbook makes somebody believe it is happening. Three properties separate a cadence that survives from one that quietly stops.

It has to produce an artifact. A check that ends in somebody being satisfied leaves nothing behind, so its absence next month is invisible. A check that ends in a file, a ticket or a row in a table makes the gap visible without anybody watching for it.

It has to be cheap enough to do badly. A quarterly review requiring a two-hour meeting with four people is a review that gets postponed once and then never rescheduled. A twenty-minute script somebody runs survives staff changes.

And it has to have an owner who is not a team. Ownership assigned to a group is ownership assigned to nobody, which is the same finding section 0.6 made about service principals and the same mechanism.

There is a fourth property that is really a consequence of the first three: the cadence has to survive the person who designed it leaving. The scenario's estate failed on exactly that. Everything worked while the project team was there, because they remembered, and remembering is not a control.

Of those three the artifact matters most, because it converts an absence into evidence. The scenario's estate had no artifact from any quarterly check, so fourteen months of not doing it looked exactly like fourteen months of doing it. That equivalence is the thing to design against, and it is the same equivalence section 0.3 found in a rule that fires into a filtered queue and section 0.2 found in a query against a table nobody populates.

Twenty minutes, and the answer is usually one of four rather than four of four.

The next section turns to the three surfaces this course keeps reaching for, and which of them answers which kind of question.