When an employee cannot open an application, the reported symptom is often “Entra rejected me.” That statement might describe a failed password, a Conditional Access block, an app-specific authorization decision, or a provisioning failure that left no account at the vendor. The fastest investigator first identifies which service actually made the unsuccessful decision, then builds a timeline across the relevant identity records.
SC-300 includes reviewing sign-in, audit and provisioning logs, configuring diagnostic settings, analyzing data through workbooks and Kusto Query Language (KQL), and monitoring identity security posture. This is an operational skill: the purpose of logs is to support a clear finding and corrective action, not to display a large number of charts.
Know what each Entra log answers
Sign-in logs describe authentication attempts and related context such as principal, application, outcome, device signals and Conditional Access evaluations where recorded. Audit logs describe directory configuration and object changes, including user, group, application and policy updates. Provisioning logs describe identity lifecycle operations performed by provisioning services. The official Microsoft Entra activity-log reference explains how these reports are accessed and notes that permissions and licenses affect availability.
A provisioning log saying an account was created does not prove the user has a valid current session. A successful sign-in does not prove the target application has correctly mapped the user to a local role. An audit event that a group was changed does not prove when a downstream vendor synchronized that change. Treat each log as evidence for its own component.
Record a stable correlation key before searching: user object ID or service principal ID, application ID, request/correlation ID if present, tenant, time window and the event type. Display names and human-readable emails can change, so do not rely only on those strings when reconciling a complicated history.
Build the timeline from a concrete user complaint
Suppose a newly hired analyst sees “not authorized” after an apparently successful SSO login to a case-management SaaS app. First check sign-in logs to establish which enterprise app received a successful authentication and whether Conditional Access applied as expected. Then inspect group memberships and audit events to determine whether the analyst was assigned the intended app entitlement.
Next inspect the provisioning job for the target app. Was the new user in scope, did the connector match an existing vendor account, did an attribute mapping fail, or did the target return an error? If the provisioning job succeeded, the remaining issue may be the vendor’s own authorization rather than Entra. The existing joiner–mover–leaver coverage addresses lifecycle triggers; logs help prove whether those triggers produced the intended downstream state.
Ask for the exact event time and application URL. A screenshot taken hours later may show a different state after eventual consistency or a background sync. Preserve time zone and correlation details, especially when several admins are changing settings during troubleshooting.
Use KQL to answer narrow investigative questions
Kusto Query Language lets an analyst filter, project, summarize and join log data in an appropriate Log Analytics workspace. Start with a small, explicit time window and the actual table available in that workspace. The following is an illustrative sign-in summary for an environment using the common SigninLogs table; adapt the schema and filtering to the tenant’s diagnostic configuration.
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize Failures=count() by AppDisplayName, ResultDescription
| top 20 by Failures descThis query identifies concentration of failures, not proof of an attack. A deployment that intentionally rejects many legacy-client attempts can rank highly, while a single compromised privileged account may not. Always review a representative source event and the actual user/app context before deciding whether the pattern is malicious.
For a more focused investigation, filter by an exact UserId or application ID, project TimeGenerated, ResultType, IPAddress and correlation fields supported by the table, and compare events before and after a documented policy change. KQL for Microsoft security investigations adds useful examples of building queries around questions rather than dashboards.
Separate an audit trail from a causal explanation
If a Conditional Access policy changed just before users lost access, the audit record establishes that a change occurred and who performed it, while sign-in logs show the evaluated result for impacted users. Correlate both with the actual policy version and applied assignments. It is possible for a change to be temporally adjacent to the incident but not the cause.
Similarly, a service principal may receive a new credential and then show unusual sign-in behavior. The timeline suggests a hypothesis; it still needs context from the app owner, deployment pipeline and resource logs. Avoid publishing “compromise confirmed” in an incident ticket merely because two events happened near each other.
For access reviews and entitlement management, preserve reviewer decisions and application of results in addition to directory change events. A reviewer decision that was never applied does not demonstrate that effective access was removed.
Configure exports and retention before the incident
Interactive log retention inside a service may not meet the organization’s investigation, compliance or historical comparison needs. Diagnostic settings can route supported activity logs to Log Analytics, storage accounts or Event Hubs, subject to current capability and licensing. Define the purpose, access control, retention and expected volume before enabling indiscriminate long-term export.
Security logs can contain IP addresses, user identifiers, application information and details about organizational behavior. Restrict who can read them, maintain appropriate regional and privacy controls, and protect service identities that write or query the destination. Longer retention has cost and privacy implications; “save everything forever” is neither a security architecture nor a defensible data policy.
Document which log categories have been configured for export and test an end-to-end event. A dashboard may be empty because diagnostic settings were never enabled, the query uses a table not present in that workspace, or the chosen filters exclude the relevant events. Do not interpret lack of rows as proof that nothing happened.
Make workbooks useful to operators
Workbooks can combine queries and visualizations for sign-in failures, risky accounts, privileged changes, app usage and synchronization health. The best workbook answers operational questions: which users are newly blocked, which app’s failure rate changed after a release, or which privileged assignments changed without an approved ticket?
Build drill-downs from aggregate counts to source events. A graph of failed logins by application is useful, but responders also need timestamps, principal IDs, failure reasons and links to relevant investigations. Avoid publishing sensitive identity details in dashboards accessible to teams that have no operational need to see them.
Set a review owner and a change trigger for each workbook. A query written against a retired table or old property can return misleading data without obvious errors. Validate after major product updates and policy changes, and keep sample test events to demonstrate the dashboard still captures expected activity.
Verify that the event data is actually complete
Suppose a SOC dashboard shows no privileged-role changes over a month. Before concluding that all administration was stable, check whether the diagnostic setting existed for the entire period, whether the log category was enabled, and whether the workspace retention covers the requested window. A beautifully written KQL query cannot compensate for events that were never collected or were already expired.
Test with a controlled and reversible audit-generating action, such as an approved group-description change in a sandbox, then confirm the event appears with an expected timestamp, actor and object. Record the ingestion delay and exact table or data source. Repeat the check after platform or diagnostic configuration changes. Such a test is preferable to relying on a graph that silently stays at zero.
For sign-in data, differentiate interactive user sign-ins, noninteractive activity and workload authentication where the platform exposes them. A query against only the common interactive SigninLogs table may miss a service principal that is the actual subject of an incident. Start from the investigated identity type and the available table inventory, then build the query.
Consider ingestion costs and schema changes when joining sign-in and audit events. Large unbounded queries over months of data can be slow and expensive; filter early on time, principal and app IDs, then project only required fields. Record source fields and normalization decisions in saved query comments so another analyst can interpret a report later without guessing what “Failures” counted.
Where logs cross team boundaries, use role-based access to workspaces and sanitized dashboards. An application owner might need a count of provisioning failures for their service without access to every person’s sign-in history. Good monitoring design gives each role the evidence needed for its task without exposing unrelated tenant behavior.
Turn findings into safe corrective actions
When a problem is identified, the fix might be an app assignment, an attribute mapping, a missing license, a Conditional Access rule, or a compromised credential. Match the remediation to the evidence, then confirm in the source log and the downstream service that the result changed. A user who no longer receives an Entra error may still be missing the vendor role required to complete their work.
Store incident notes with evidence references and a clear result: affected identities, cause supported by logs, correction, verification timestamp and remaining risks. Security event correlation concepts are useful here because strong conclusions combine independent evidence rather than overinterpreting one event source.
Identity logging is successful when it shortens the path from symptom to verified explanation. The value lies in trustworthy timelines, appropriate retention, and an operator who knows which record can—and cannot—answer the question being investigated.