15.1 Sign-in, Audit & Provisioning Logs
Key Takeaways
- Microsoft Entra sign-in logs record authentication attempts and outcomes, including interactive and non-interactive (and service principal) categories, Conditional Access results, failure reasons, device, location, and application context.
- Audit logs capture directory and configuration changes—who changed what, when, and with which activity—supporting governance, troubleshooting, and incident investigation.
- Provisioning logs track HR-driven inbound provisioning and outbound application provisioning so you can diagnose skip, fail, and success cycles for users and groups.
- SC-300 investigation scenarios almost always start in the Microsoft Entra admin center Monitoring blades: filter the right log type, correlate user/app/time, then pivot to CA, risk, or resource configuration.
- Choose the correct log for the symptom: cannot sign in → sign-in logs; group membership or role changed → audit logs; user missing from SaaS app → provisioning logs.
Why monitoring closes Domain 4
Earlier governance chapters (entitlement management, access reviews, PIM, break-glass) define how access should be granted and removed. Monitoring proves what actually happened. Domain 4—Plan and automate identity governance—explicitly expects you to review and analyze logs in the Microsoft Entra admin center, export diagnostics when needed, and improve posture with Identity Secure Score. Section 15.1 is the day-to-day investigation toolkit every SC-300 identity admin must master.
The three primary Entra log families
| Log type | Answers the question | Typical SC-300 use |
|---|---|---|
| Sign-in logs | Did authentication succeed? Why failed? Which CA policies applied? | MFA failures, blocked CA, risky locations, app access issues |
| Audit logs | Who changed the directory or configuration? | Role assignments, group membership, CA policy edits, app consent |
| Provisioning logs | Did HR/app provisioning create, update, disable, or skip objects? | Workday/SuccessFactors → Entra; Entra → Salesforce/ServiceNow |
These logs are complementary. A user “cannot open the app” story often requires sign-in logs first; if they never appear in the SaaS directory, pivot to provisioning logs; if an admin removed them from a group yesterday, use audit logs.
Default retention in the portal is limited (commonly on the order of 30 days for interactive sign-ins depending on license and product defaults—treat exam answers as “use diagnostic settings for long-term retention,” not as a memorized free-forever archive). For months of history, SIEM export, or custom alerting, configure diagnostic settings (section 15.2).
Sign-in logs deep dive
Open Microsoft Entra admin center → Identity → Monitoring & health → Sign-in logs (navigation labels evolve; the exam cares about the capability).
Categories you must distinguish
| Category | Who authenticates | Examples |
|---|---|---|
| Interactive user sign-ins | Human presents credentials / MFA challenge | Browser to Microsoft 365, interactive OAuth consent, password + Authenticator |
| Non-interactive user sign-ins | User context without full interactive challenge at that moment | Refresh token / continuous access patterns, some background client activity on behalf of a user |
| Service principal / managed identity sign-ins (app sign-ins) | Workload identity | Daemon app client credentials, managed identity token requests |
Exam trap: troubleshooting a daemon app secret failure in interactive user filters only—you will miss the event. Filter the correct sign-in category (or use dedicated app sign-in views) when the principal is a service principal.
Fields identity admins actually use
When a stem describes a failed login, know which columns answer it:
| Field / detail | Investigation value |
|---|---|
| Status (Success / Failure) | First triage |
| Failure reason / error code | Root cause language (invalid credentials, MFA denied, CA blocked, etc.) |
| Application / Resource | Which cloud app or API was targeted |
| Client app | Modern browser vs legacy auth / older protocols |
| IP address / Location | Impossible travel, anonymous egress, named locations |
| Device info | Compliant, hybrid joined, managed browser signals |
| Conditional Access tab | Which policies matched, not applied, success, failure |
| Authentication details | Methods used (password, Authenticator, FIDO2), MFA claims |
| Risk (when ID Protection is licensed) | Sign-in risk / related detections |
Interactive vs non-interactive—operational meaning
- Interactive failures are the classic helpdesk queue: wrong password, MFA timeout, user canceled Authenticator, Conditional Access requiring compliant device when the laptop is not enrolled.
- Non-interactive failures often surface as “Outlook keeps asking for password” or silent token refresh issues—still user-scoped, but the UI path is different.
- Service principal failures are credential, permission, or CA-for-workloads issues—not “send an MFA registration campaign to the app.”
Conditional Access results inside sign-in logs
SC-300 loves CA troubleshooting via sign-in logs, not via guessing policy names:
- Open the failed (or successful but unexpected) sign-in.
- Open the Conditional Access detail pane.
- For each policy, note result: Success, Failure, Not applied, Report-only: Success/Failure.
- Expand why a policy was Not applied (user excluded, cloud app not in scope, conditions not met).
- Confirm grant controls required (MFA, compliant device, auth strength) versus what the authentication methods detail shows the user completed.
| Sign-in symptom | Likely CA reading |
|---|---|
| Blocked with CA message | A matching policy Failure with Block grant |
| MFA prompt loop / incomplete | Policy Success required MFA but methods missing or interrupted |
| Policy “does nothing” | Not applied—scope or condition mismatch |
| Pilot impact without block | Report-only result rows |
Pair this with the Conditional Access chapter: report-only mode writes evaluation results into sign-in logs so you can pilot safely.
Failure reasons—map symptom to log, not to random fixes
| Failure theme | Where you see it | First response direction |
|---|---|---|
| Invalid username or password | Sign-in status + failure reason | Credential reset / PHS-PTA hybrid path / lockout |
| MFA required / denied / interrupted | Auth details + CA | Registration, method health, Authenticator number matching |
| Device not compliant / not hybrid joined | CA + device detail | Intune compliance, device join state |
| Legacy authentication blocked | Client app = legacy; CA block legacy | Modern auth client; exception only if justified |
| User disabled / blocked sign-in | Sign-in + user properties | Unblock only after investigation |
| Consent / app assignment missing | App sign-in / enterprise app assignment | Assign user/group or fix consent |
Audit logs deep dive
Audit logs record change events in the directory and related configuration planes: create/update/delete on users, groups, applications, roles, policies, and many governance objects.
| Audit focus | Example activities |
|---|---|
| User management | Add user, update user, delete user, restore user |
| Group management | Add member to group, update group |
| Directory roles / PIM | Add member to role, role assignment eligibility |
| Application | Consent to application, update application, add service principal credentials |
| Policy | Add Conditional Access policy, update named location |
| Governance | Access package assignment, access review decisions (as logged) |
How to investigate with audit logs
- Filter by date/time window of the change.
- Filter Activity or Category (for example UserManagement, RoleManagement, Policy).
- Filter Initiated by (actor) when you know the admin UPN—or search Target when you know the user/app that was changed.
- Open the event for modified properties (old vs new values where available).
- Correlate with sign-in logs if the change caused authentication impact (for example CA policy update time vs first blocks).
Exam cue: “Who added Contoso User to Global Administrator last night?” → audit logs (role assignment activity), not sign-in logs alone. Sign-in logs show when that admin later authenticated; audit shows the privilege grant.
Exam cue: “When was the Conditional Access MFA policy modified?” → audit logs with Policy category / CA update activity.
Provisioning logs deep dive
Provisioning logs track the synchronization cycle between Entra ID and connected systems:
| Direction | Pattern | Example |
|---|---|---|
| Inbound HR-driven | HR system → Entra | Workday / SuccessFactors provisioning creates or updates users |
| Outbound app provisioning | Entra → SaaS | User assigned to enterprise app → account created in ServiceNow |
| Governance-related delivery | Package/group-driven membership feeding provisioned apps | User joins group via access package; provisioning picks up scope |
Statuses and actions you will reason about
| Concept | Meaning |
|---|---|
| Success | Create/update/disable/delete applied as designed |
| Failure | Error (permissions, schema, uniqueness, API throttle)—read detail |
| Skipped | Object out of scope, already current, or filter excluded |
| Action (Create, Update, Delete, Disable, etc.) | What the engine attempted |
| Source / Target identity | Which system and which external ID |
Investigation pattern for “user not in Salesforce”:
- Confirm enterprise app assignment / group scope includes the user.
- Open provisioning logs for that app and user.
- If Skipped, fix scoping filters or assignment.
- If Failure, fix attribute mapping, required fields, or target API permissions.
- Use audit logs only if someone removed assignment or changed provisioning config.
- Use sign-in logs only after the account exists and the user tries to authenticate.
HR inbound failures often show as “new hire has no Entra account”: check HR provisioning job health, attribute uniqueness (UPN/mail), and manager references—not Conditional Access first.
Investigation scenarios SC-300 loves
Use this decision table under timed exam pressure:
| Scenario stem | Start here | Then |
|---|---|---|
| User blocked from Teams with CA message | Sign-in logs → CA tab | Fix policy scope, device compliance, or grant |
| MFA prompt never completes | Sign-in logs → Authentication details | Methods policy, registration, Authenticator |
| Guest cannot redeem / access SharePoint | Sign-in + guest user state; collaboration settings | Cross-tenant / external settings from earlier chapters |
| Unexpected Global Admin | Audit logs role assignment | PIM history if eligibility/activation; revoke |
| Group membership vanished | Audit logs group member remove | Entitlement package expiry vs manual remove |
| HR hire missing in Entra | Provisioning logs (inbound) | Job errors, mapping, scoping |
| User assigned to app but missing in SaaS | Provisioning logs (outbound) | Skip/fail detail, attribute mapping |
| Service principal auth failing | App / service principal sign-ins | Credential expiry, secret rotation, permissions |
| Break-glass used | Sign-in logs for that account + audit for role use | Incident process; alert on break-glass |
End-to-end investigation checklist
- Clarify identity type — member, guest, service principal.
- Clarify symptom plane — auth, directory change, or provisioning.
- Time-box the search window tightly, then expand.
- Filter user/app/IP/correlation IDs when available.
- Read CA and auth details before redesigning the whole tenant.
- Document actor, target, activity, and outcome for SOC handoff.
- Remediate with least privilege (fix CA, re-register method, re-run provisioning, revoke role)—not “Global Admin for everyone.”
Portal vs Graph vs long-term storage
| Need | Tool |
|---|---|
| Interactive triage for one user this week | Entra admin center log blades |
| Automation / bulk export queries | Microsoft Graph sign-in/audit APIs (permissions required) |
| 90+ day retention, joins, alerts, workbooks | Diagnostic settings → Log Analytics / SIEM (next section) |
| Executive posture trends | Identity Secure Score + workbooks (15.2–15.3) |
Common exam traps
- Using audit logs to explain a failed MFA challenge (use sign-in logs).
- Using sign-in logs alone to find who elevated a role (use audit logs).
- Expecting interactive filters to show client credential app failures.
- Ignoring report-only CA rows when analyzing pilot impact.
- Assuming provisioning “failure” when the log shows Skipped due to scoping.
- Believing portal logs replace a SIEM retention strategy for regulated tenants.
Summary of section 15.1
A user reports that Conditional Access blocked access to Exchange Online after a policy change. Which log should you open first to see matching policies and grant results for that authentication attempt?
Security asks who granted a user the Privileged Role Administrator directory role yesterday. Which Entra log family is the primary source?
An employee is assigned to an enterprise application that uses Entra app provisioning, but no account appears in the SaaS admin console. Where should you look next?
A daemon application authenticates with a client secret and suddenly fails. Which sign-in category should you prioritize when filtering logs?