I6.7 Identity Logs and Access Monitoring
Learn how defenders correlate fictional sign-ins, MFA events, account changes, roles, sessions, application actions, recovery, privileged access, lifecycle events, and owner context without overstating what any single log or alert proves.
Lesson Progress
Identity Logs and Access Monitoring
High School Intermediate • I6: Identity and Access Management • Lesson 7 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
An Alert Is a Starting Question, Not a Final Verdict
A fictional monitoring platform may alert when a dormant account becomes active, an MFA challenge is denied, a role changes, or an export is attempted. The alert identifies a pattern worth review. Defenders still need the raw events, account state, session, device, application, approval, owner, lifecycle, and business context before reaching a conclusion.
Weak response
“The alert is high severity, so the account is definitely compromised.”
Strong response
“Preserve the source events, build the correlated timeline, compare approved context, classify confidence, and validate the current state.”
Objective 1
Explain how fictional identity-provider, directory, application, device, session, privileged-access, recovery, and lifecycle logs support access monitoring.
Objective 2
Interpret timestamps, event IDs, account states, authentication results, role changes, session actions, policy decisions, and owner context.
Objective 3
Separate expected activity, policy enforcement, suspicious patterns, tool interpretation, and missing evidence.
Objective 4
Build a fictional identity timeline by correlating account, device, application, session, role, approval, and business evidence.
Objective 5
Create a professional fictional Identity Monitoring Case Report with confirmed facts, findings, owners, validation, monitoring, and residual risk.
Why This Matters
Identity Activity Is Distributed Across Many Systems
The identity provider may show the sign-in, the directory may show the role change, the application may show the resource action, the device system may show managed state, the lifecycle record may show an approved reactivation, and the resource owner may explain the business need. Monitoring becomes reliable when those records are connected rather than reviewed in isolation.
Identity Log Sources
Eight Sources That Build an Identity Timeline
Identity-provider sign-in logs
Typical records
Fictional account, application, device, source, factor, MFA, policy, result, reason, risk, session, and time.
Defensive use
Review successful and failed sign-ins, MFA, device context, policy challenges, session creation, and unusual sequences.
Limitation
A successful sign-in does not prove the physical person, safe intent, or approval for later actions.
Directory and account logs
Typical records
Fictional account creation, disablement, lockout, expiration, owner, manager, group, role, attribute, and password-reset events.
Defensive use
Trace lifecycle changes, privilege assignments, ownership changes, and account-state transitions.
Limitation
Application-local roles, active sessions, and external resource shares may not appear.
Application access logs
Typical records
Fictional account, session, resource, action, allow or deny result, request ID, local role, owner, and time.
Defensive use
Confirm what the authenticated session attempted and whether the application enforced the expected authorization.
Limitation
The application may not explain every central role, nested group, or external policy input.
Device and endpoint logs
Typical records
Fictional device identity, managed state, user association, compliance, sign-in, session, application, and security posture.
Defensive use
Correlate account activity with a known or unknown device and evaluate changes in device trust.
Limitation
A managed device does not prove the expected person is using it at that moment.
Privileged-access logs
Typical records
Fictional request, approval, elevation, role, administrative account, device, session, target, action, result, and expiration.
Defensive use
Trace privileged authority from request through de-elevation and post-use review.
Limitation
Some local tools may not forward complete action evidence.
Recovery and factor logs
Typical records
Fictional password reset, factor registration, factor removal, recovery approval, device replacement, and backup-method use.
Defensive use
Identify authentication-lifecycle changes and connect them to sign-ins and session cleanup.
Limitation
A completed recovery event does not prove the physical initiator without owner and verification evidence.
Lifecycle and access-review logs
Typical records
Fictional joiner, mover, leaver, temporary expiration, suspension, recertification, owner decision, and deprovisioning actions.
Defensive use
Compare approved identity state with current technical state.
Limitation
A closed ticket does not prove every application, session, resource, and owner relationship was updated.
Security and case-management logs
Typical records
Fictional alert, severity, source, linked events, analyst notes, owner, status, action, validation, and closure.
Defensive use
Preserve the investigation trail and document why an alert was escalated, downgraded, or closed.
Limitation
Analyst notes and severity are interpretations that must remain tied to source evidence.
Event Fields
Eight Fields to Read Before Interpreting an Alert
Timestamp
When did the fictional event occur, which timezone is used, and is the source clock reliable?
Interpretation risk
Timezone differences, delayed ingestion, clock drift, and rounding can distort event order.
Account or subject
Which fictional user, service, application, device, or session is associated with the event?
Interpretation risk
Display names can be duplicated, renamed, stale, or mapped to the wrong identity.
Application or system
Which fictional identity provider, directory, application, device, service, or enforcement point recorded the event?
Interpretation risk
Similar event labels can mean different things in different systems.
Action
Was the fictional event a sign-in, challenge, reset, role change, group update, session action, view, edit, export, or administrative change?
Interpretation risk
Broad labels can hide the exact resource or permission involved.
Result and reason
Was the fictional action allowed, denied, failed, challenged, expired, revoked, or partially completed, and why?
Interpretation risk
A final result can be misread without the policy, session, account state, and resource context.
Device and source
Which fictional device, network, workload, browser, application, or source context is recorded?
Interpretation risk
Network location can be approximate, and a trusted device can be shared or left unlocked.
Session and correlation
Which fictional session ID, request ID, challenge ID, case ID, or correlation value connects related events?
Interpretation risk
Events can be grouped incorrectly when IDs are missing, reused, or not preserved.
Owner and business context
Which fictional owner, manager, resource, purpose, approval, duration, and expected workflow explain the activity?
Interpretation risk
Technical activity can be normal or inappropriate depending on current business need.
Monitoring Patterns
Eight Patterns That Require Correlation
Repeated failures followed by success
Direct meaning
A fictional account records several failed authentication events before a successful sign-in.
Possible explanations
Typing mistakes, stale saved credentials, password reset, user confusion, automated retries, or unauthorized attempts.
Next evidence
Device, source, application, user report, MFA, session, password-reset history, and later actions.
Successful sign-in from a new device
Direct meaning
A fictional account authenticates from a device not previously recorded in the current baseline.
Possible explanations
Approved replacement, new school device, shared lab device, travel, enrollment change, or unauthorized use.
Next evidence
Device registration, asset owner, managed state, user confirmation, application, session, and lifecycle records.
MFA denied after password accepted
Direct meaning
The fictional knowledge factor succeeds, but the required possession-factor challenge is rejected.
Possible explanations
Unexpected sign-in, wrong session, user caution, unavailable device, application error, or unauthorized attempt.
Next evidence
Challenge ID, session, device, user report, source, surrounding attempts, and recovery activity.
Role assignment followed by sensitive action
Direct meaning
A fictional role is granted and a protected action occurs soon afterward.
Possible explanations
Approved maintenance, scheduled onboarding, emergency recovery, excessive access, or unauthorized privilege.
Next evidence
Request, approval, owner, duration, device, session, target, action, validation, and role expiration.
Temporary role expires but session continues
Direct meaning
A fictional role ends while an older session still accesses the protected resource.
Possible explanations
Expected short refresh delay, application cache, incomplete session revocation, or policy-enforcement gap.
Next evidence
Role state, session issue time, application claims, revocation, later access tests, and owner confirmation.
Dormant account becomes active
Direct meaning
A fictional account with little expected activity records a new sign-in or resource action.
Possible explanations
Approved reactivation, delayed project work, automated task, ownership change, stale account, or unauthorized use.
Next evidence
Owner, sponsor, account state, application, device, session, business request, and recent lifecycle review.
New factor registration and recovery
Direct meaning
A fictional account completes recovery and adds or replaces an authentication factor.
Possible explanations
Approved device replacement, lost factor, support-assisted recovery, or unauthorized account takeover attempt.
Next evidence
Recovery verification, owner approval, device, source, prior factor removal, session cleanup, and post-recovery sign-in.
Group change outside expected workflow
Direct meaning
A fictional group or role membership changes without a matching normal provisioning or access-review event.
Possible explanations
Emergency change, administrative mistake, delayed ticket ingestion, automation, or unauthorized assignment.
Next evidence
Requester, approver, administrator, change record, owner, role purpose, session, and effective-access validation.
Core Concept
Build the Timeline Before You Explain the Pattern
Identity
Which fictional user, service, application, device, or session is represented, and who owns it?
Time
Which timezone, source clock, ingestion delay, and event order apply?
Connection
Which session, request, challenge, event, device, or correlation values connect the records?
Context
Which application, resource, role, policy, lifecycle event, approval, and business purpose explain the activity?
Conclusion
Which facts are confirmed, what remains possible, what evidence is missing, and what should happen next?
Evidence Matrix
What Monitoring Evidence Can and Cannot Prove
Evidence source
Raw identity event
Can support
The fictional source recorded a specific account, action, result, reason, context, and time.
Limitation
One event rarely proves the complete sequence, physical identity, business purpose, or impact.
Evidence source
Correlated timeline
Can support
Multiple fictional events share account, session, request, device, application, or correlation relationships.
Limitation
Incorrect grouping or missing events can produce a misleading narrative.
Evidence source
Baseline comparison
Can support
The fictional activity differs from or matches expected device, application, timing, role, and workflow patterns.
Limitation
Baselines can be incomplete, outdated, too broad, or based on limited history.
Evidence source
User or owner report
Can support
The fictional account or resource owner confirms whether an activity was expected, approved, or understood.
Limitation
Human memory can be incomplete, and confirmation does not replace technical evidence.
Evidence source
Access request and approval
Can support
The fictional purpose, resource, action, duration, requester, owner, approver, and expected outcome.
Limitation
The implemented access or actual activity can differ from the approved request.
Evidence source
Application and resource activity
Can support
The fictional authenticated session attempted or completed specific actions on named resources.
Limitation
The event may not show the full identity, role, or device context.
Evidence source
Session and lifecycle evidence
Can support
The fictional session creation, expiration, revocation, account state, role state, and lifecycle timing.
Limitation
Different applications can refresh or revoke sessions at different times.
Evidence source
Case notes and alert status
Can support
The fictional analyst’s interpretation, questions, owner, actions, validation, and closure decision.
Limitation
Case conclusions must remain traceable to source evidence and clearly labeled confidence.
Case Classification
Six Outcomes with Different Evidence Requirements
Expected activity
The fictional activity matches the approved owner, device, application, role, timing, resource, and workflow.
Required documentation
Preserve the matching evidence and explain why the event is normal.
Expected policy enforcement
The fictional system correctly denies, challenges, expires, or restricts an action under the approved policy.
Required documentation
Document the policy, decision reason, resource, action, and owner expectation.
False positive
A fictional alert is explained by authorized activity, tool limitations, baseline gaps, or harmless system behavior.
Required documentation
Preserve the explanation, supporting evidence, tuning recommendation, and coverage impact.
Suspicious pattern
The fictional evidence differs from the baseline or approved workflow but does not yet prove a confirmed issue.
Required documentation
Collect more evidence, assign an owner, use safe temporary controls, and avoid unsupported attribution.
Confirmed control issue
The fictional evidence proves an access, lifecycle, session, policy, monitoring, or ownership control failed.
Required documentation
Correct narrowly, validate the new state, review related systems, and document residual risk.
Evidence incomplete
The fictional evidence is too limited, delayed, inconsistent, or unavailable for a reliable conclusion.
Required documentation
State the gap, confidence, investigation owner, due date, temporary risk control, and decision criteria.
Monitoring Use Cases
Eight Identity Questions Worth Monitoring
Authentication monitoring
Are fictional sign-in failures, successes, MFA results, devices, sources, applications, and sessions consistent with the expected workflow?
Useful evidence
Password result, factor result, device, source, session, account state, user report, and application access.
Privilege-change monitoring
Do fictional role, group, direct-permission, local-role, and elevation changes match approved requests and owners?
Useful evidence
Change event, requester, approver, administrator, role, resource, duration, session, and validation.
Lifecycle monitoring
Do fictional joiner, mover, leaver, suspension, reactivation, and expiration events produce the expected technical state?
Useful evidence
Lifecycle event, account state, roles, groups, local access, sessions, devices, resources, and owner confirmation.
Recovery monitoring
Do fictional resets, factor registrations, device replacements, and recovery events match approved ownership and session cleanup?
Useful evidence
Recovery verification, factor changes, device, source, owner, active sessions, and post-recovery sign-in.
Dormant-account monitoring
Does fictional activity from an inactive or rarely used account have a current approved owner and purpose?
Useful evidence
Last expected use, owner, sponsor, reactivation request, application, device, session, and resource actions.
Privileged-session monitoring
Do fictional administrative activations, actions, targets, expirations, and session endings match the approved change?
Useful evidence
Request, approval, role, device, MFA, session, action, target, result, expiration, and post-use review.
Application authorization monitoring
Are fictional sensitive views, edits, exports, approvals, and administrative actions allowed or denied as expected?
Useful evidence
Application event, resource, action, session, effective role, policy reason, owner, and business purpose.
Monitoring-health review
Are fictional identity events complete, timely, correctly parsed, correlated, retained, and routed to accountable owners?
Useful evidence
Source health, ingestion time, parsing status, event count, missing fields, alert route, case status, and validation test.
Defensive Workflow
Review an Identity Alert in Six Steps
Define the alert or question
Identify the fictional account, application, event type, time range, resource, severity, and reason for review.
Preserve source evidence
Collect the fictional raw events, IDs, timestamps, sessions, devices, policy decisions, role changes, approvals, and owners.
Build the timeline
Normalize time and correlate sign-in, MFA, session, directory, application, privileged, recovery, and lifecycle events.
Compare context and baseline
Check expected devices, applications, roles, timing, workflow, resource ownership, and recent changes.
Classify and respond
Separate normal activity, expected policy enforcement, false positive, suspicious pattern, confirmed issue, and evidence gap.
Validate and close
Confirm technical state, owner outcome, monitoring, related accounts, session cleanup, residual risk, and closure criteria.
Correlated Identity Timeline
Follow a Dormant-Account Reactivation from Approval to Closure
14:00:00
Directory
Fictional dormant account training-dnguyen is reactivated after an approved project assignment.
Establishes the account-state change and approved reason for renewed use.
14:02:00
Access request
The project owner approves report-view access for fourteen days.
Defines the resource, action, duration, and accountable owner.
14:05:00
Directory
training-dnguyen is added to project-report-viewers with automatic expiration.
Implements the approved role path.
14:10:11
Identity provider
The account signs in from managed-laptop-61 using password and approved MFA.
Supports successful authentication under the recorded device and policy context.
14:10:14
Session
Session session-8812 is created for the reporting application.
Connects the sign-in with later resource actions.
14:10:20
Application
The report-view request is allowed through project-report-viewers.
Matches the approved role and resource action.
14:11:02
Application
An export request is denied because the role provides view only.
Shows correct least-privilege policy enforcement.
14:15:00
Monitoring alert
The monitoring platform creates an alert because a dormant account became active and attempted export.
The alert combines a real baseline change with a correctly denied action.
14:20:00
Owner confirmation
The project owner confirms the account reactivation and report-view need but confirms export is unnecessary.
Adds business context that supports expected use and correct denial.
14:25:00
Analyst review
The analyst correlates the lifecycle approval, role, sign-in, session, view allow, export deny, and owner confirmation.
Builds a complete evidence-based timeline.
14:30:00
Case classification
The case is classified as expected reactivation with correct policy enforcement and a baseline-tuning opportunity.
Separates the account activation from a confirmed access-control failure.
Day 14 17:00
Role lifecycle
The temporary project-report-viewers membership expires automatically.
Ends the approved access duration.
Day 14 17:02
Session control
The reporting session is revoked and a new access decision is required.
Aligns the session with the expired role.
Day 14 17:05
Validation
The account is denied report access after expiration.
Confirms technical closure.
Day 15
Owner review
The owner confirms the project task is complete and the case records no remaining access.
Completes business validation and closure.
Key Vocabulary
Identity Monitoring and Evidence Terms
Identity log
A fictional record describing an authentication, account, role, group, session, factor, policy, recovery, or lifecycle event.
Event ID
A fictional identifier used to distinguish one recorded event type or event instance from another.
Correlation ID
A fictional value used to connect related sign-in, challenge, session, application, and access-decision records.
Authentication event
A fictional record showing a sign-in attempt, factor result, device context, policy result, or session creation.
Authorization event
A fictional record showing whether a subject was allowed, denied, challenged, or restricted for a specific resource action.
Directory event
A fictional record showing account, group, role, owner, attribute, status, or lifecycle changes.
Session event
A fictional record showing session creation, refresh, expiration, revocation, step-up, or continued use.
Baseline
A fictional description of expected activity used to compare timing, device, application, location, role, and workflow patterns.
Anomaly
A fictional activity pattern that differs from the current baseline and requires context before interpretation.
False positive
A fictional alert that appears concerning but is explained by approved, expected, or harmless activity after review.
Confirmed fact
A conclusion directly supported by the available fictional evidence.
Evidence gap
Important fictional information that is missing, delayed, inconsistent, unavailable, or not preserved.
Fake Dashboard
Fake Identity Monitoring Dashboard
Training dashboard for the fictional Northstar Learning Services identity environment.
Identity events
1,284
Sign-ins, MFA, sessions, role changes, application decisions, recovery, privileged activity, and lifecycle records.
Alerts reviewed
19
Seven expected activities, four correct policy denials, three false positives, three suspicious patterns, one confirmed session issue, and one evidence-incomplete case.
Monitoring gaps
5
Two delayed application sources, one missing correlation field, one stale baseline, and one unowned alert route.
Fake SOC Alert
Dormant Account Reactivated and Export Attempt Denied
Source: Fake Identity Monitoring Console • Time: 02:15 PM
Fake Log Panel
Fake Identity Monitoring Timeline
14:00:00 DIRECTORY user='training-dnguyen' account_state='reactivated' reason='approved_project' 14:02:00 ACCESS_REQUEST role='project-report-viewers' duration='14d' owner_approved='true' 14:05:00 DIRECTORY role='project-report-viewers' assigned='true' expires='day14_17:00' 14:10:11 AUTH user='training-dnguyen' device='managed-laptop-61' password='accepted' mfa='approved' 14:10:14 SESSION id='session-8812' app='reporting-app' issued='true' 14:10:20 AUTHZ action='view_report' result='allow' 14:11:02 AUTHZ action='export_report' result='deny' reason='view_only_role' 14:15:00 ALERT pattern='dormant_reactivation_plus_sensitive_denial' severity='high' 14:20:00 OWNER_CONFIRMATION reactivation='expected' export_needed='false' 14:25:00 REVIEW correlation='complete' 14:30:00 CASE classification='expected_activity_and_policy_enforcement' DAY14 17:00 ROLE state='expired' DAY14 17:02 SESSION id='session-8812' action='revoked' DAY14 17:05 TEST report_access='deny' DAY15 OWNER_REVIEW closure='approved'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Identity-Monitoring Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Identity Monitoring
Safe Practice Lab
Build a Fictional Identity Monitoring Case
Fictional Environment
Meadowbrook Identity Monitoring Review
Review thirty-six supplied fictional records involving sign-in failures, MFA, new devices, sessions, account reactivation, group changes, role expiration, application allows and denials, privileged activity, recovery, owner approvals, monitoring health, and closure evidence.
Required Analysis
- Identify every fictional account, device, application, session, event ID, correlation value, resource, owner, and time.
- Normalize timestamps and build one evidence-linked timeline.
- Separate raw events, tool interpretations, owner statements, confirmed facts, reasonable conclusions, and evidence gaps.
- Compare device, timing, application, role, lifecycle, and business activity with the baseline.
- Classify expected activity, policy enforcement, false positive, suspicious pattern, confirmed issue, or evidence incomplete.
- Recommend narrow owner-approved actions with preserved evidence, rollback, validation, and monitoring.
- Document confidence, related-account review, session cleanup, residual risk, and closure criteria.
Scenario Decision Lab
A Dormant Account Becomes Active After an Approved Project Assignment
A fictional dormant account is reactivated through a current owner-approved request. It signs in from a managed device, opens the approved report, and receives a denial when it attempts export.
Scenario Decision Lab
A High-Severity Identity Alert Has Missing Application Logs
A fictional monitoring platform reports a role change followed by a sensitive application action. The directory and sign-in records are available, but the application source stopped sending events during the time window.
Defender Habits
Identity Logs and Access Monitoring Checklist
Check Your Understanding
I6.7 Mini Quiz: Identity Logs and Access Monitoring
Choose your answers first. Explanations appear only after submission.
1. What does a correlation ID help defenders do?
2. What is a baseline?
3. A dormant fictional account is reactivated through an approved project request and later attempts an unauthorized export that is denied. What is the strongest conclusion?
4. Why should defenders normalize timestamps?
5. What makes an alert a false positive?
6. What should happen when identity logs are incomplete?
7. Which monitoring review is strongest?
Portfolio Prompt
Portfolio Prompt
Create a fictional Identity Monitoring Case Report containing at least thirty-six identity-provider, directory, application, device, MFA, session, role, permission, privileged-access, recovery, lifecycle, owner, alert, source-health, validation, and closure records. Include normalized timestamps, event and correlation IDs, a complete timeline, baseline comparison, confirmed facts, alternative explanations, evidence gaps, confidence, case classification, narrow recommendations, session and role validation, monitoring-health review, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation