Sign-in Logs

Every earlier chapter ended with "then check the logs". This chapter is that step. Entra records what it decided, and why, every time an application or user asks for a token. If you can find the right entry, the log usually names the cause directly, and that is far better evidence for a ticket (and for a client) than a guess. The skill is not reading every field. It is knowing which log, which filter, and which five or six fields to copy down.

Four Logs, Not One

Entra keeps several activity logs. Choosing the right one is half the job. They are all under Entra ID > Monitoring & health in the admin center, and all entries are system generated and can't be changed or deleted.

The four kinds of sign-in

The sign-in logs page has four tabs, one per sign-in type. The most common mistake is looking at the first tab (interactive) and concluding "no failure was recorded".

Getting to the Logs

1. Sign in to the Microsoft Entra admin center as at least a Reports Reader, which Microsoft names as the least privileged role for accessing the activity logs.
2. Go to Entra ID > Monitoring & health > Sign-in logs (or Audit logs, or Provisioning logs).
3. Better for one application: open Enterprise apps > <app> and use its own Sign-in logs, Audit logs and Provisioning logs pages. The filter is already set to that app.

Microsoft lists licensing for each log: audit and sign-in logs are available on the Free edition, while provisioning logs need Entra ID P1 or P2 (or the Suite). If a client's Provisioning logs page is missing, licensing is a likely reason. Also, any user can see their own recent sign-ins at mysignins.microsoft.com, which is a handy, permission-free way for an affected user to confirm a time and error without involving an administrator.

Retention: How Far Back Can You Look?

This matters more than anything else in the chapter, because "it started failing last Tuesday" is only useful if Tuesday's data still exists. From Microsoft's data-retention page:

• The retention page does not give a separate figure for provisioning logs in this table; confirm provisioning-log retention in the client's tenant before relying on it.
• Changes aren't retroactive: when a tenant upgrades from Free to a premium edition, only data still within the 7-day free period is available. Expired data can't be recovered unless it was archived.
• Longer retention comes from exporting: archive to an Azure storage account, send to a Log Analytics workspace (Azure Monitor), stream to an event hub or SIEM. Configuring that needs at least Security Administrator. Microsoft 365 E5 or similar licences can use Microsoft Purview Audit (Premium) for audit logs; the Microsoft 365 Unified Audit Log is a separate system.

Finding the Entry

Filter the sign-in logs

Use Add filters. Microsoft's commonly used filters:

The best route: use the ID from the error

Chapter 3 told you to record the trace ID and correlation ID from the error. Now they pay off: paste the Correlation ID into the filter and you get exactly the attempt the user saw. Microsoft adds a caution: the correlation ID value is based on parameters passed by a client, so Entra can't guarantee its accuracy. If a correlation ID finds nothing, search by user, application and time instead.

Reading One Entry

Select a row to open the activity details. Microsoft frames every sign-in as who (the user), how (the client application) and what (the resource being accessed). Work through these tabs, and copy the fields in the table that follows.

The fields to copy into the ticket

The AADSTS Codes You Will Meet

Chapter 6 listed the consent, assignment and Conditional Access codes. These are the ones connected with credentials, tokens and the wrong tenant or application, in Microsoft's current wording (error name before the dash, shortened). Use them as a starting point, then confirm with the log's Failure reason.

Not every error number means the integration is broken

Microsoft lists some codes that appear in healthy tenants: 50058 (user authenticated but not yet signed in, which appears when a user didn't finish signing in, so the User field may even show a GUID); 90025 (an internal service hit its retry allowance, usually resolved automatically); 500121 (the user didn't complete the MFA prompt); 70046 (session expired or reauthentication check failed). A handful of these in a busy tenant are normal. The question to ask is whether the failures are constant and all users or sudden and specific.

The Audit Log: What Changed and Who Did It

Where the sign-in log says "what happened", the audit log answers "what was changed". It records changes to applications, groups, users and licences. You can filter by Service, Category, Activity, Status, Target (the object changed), Initiated by and a date range. Open an entry to see the Correlation ID, the actor, the target, and, where applicable, the old and new values of changed properties. Category ApplicationManagement is where integrations live. Activity names from Microsoft's current reference that matter here:

The model is a timeline. Find the first failed sign-in in the sign-in log, then look at the audit log for the minutes, hours and days before it. A secret deleted at 17:02 and the first failure at 17:05 is a story. Cross-tenant access changes appear under the category CrossTenantAccessSettings (Chapter 6).

The Provisioning Log (SCIM)

For SCIM provisioning (Chapter 2), the sign-in log is the wrong place. The provisioning log (Entra ID > Monitoring & health > Provisioning logs, or the enterprise application's own Provisioning logs page) shows each identity processed: the Identity, the Action (Create, Update, Delete, Disable, StagedDelete, Other), the source and target systems, and a Status of Success, Failure, Skipped or Warning. Opening an entry gives four tabs:

• Steps: the sequence for that object: import, match, scope check, evaluate, provision.
• Troubleshooting & Recommendations: the error code and reason, often with guidance.
• Modified Properties: old and new values.
• Summary: an overview with identifiers for the object in both systems.

Extra filters worth knowing: Job ID, Cycle ID and Change ID; Microsoft says the cycle and change IDs can be shared with product support to find the exact event. A "Skipped" status has several causes (for example, an object out of scope) and isn't necessarily a failure.

Exporting Evidence for a Ticket

1. Select the entry, copy the fields from the table above into the ticket (text, not just a screenshot, so it can be searched later).
2. Download the filtered list from the log page as JSON or CSV, which Microsoft describes as the manual, cheapest option for a long-term backup.
3. Screenshots must hide anything sensitive. The logs contain user names and IP addresses, so treat them as personal data and share only what the ticket needs.
4. For repeatable or longer-term needs, the client's administrator can send logs to Log Analytics, a storage account or an event hub (diagnostic settings, which needs Security Administrator).

A Worked Reading

A fictional entry from a nightly sync job, copied the way you would copy it into a ticket:

Reading it: who is the application itself (service principal); how is a client secret; what is Microsoft Graph. The error says the secret presented has expired, and the audit log shows credentials were changed two days earlier. That doesn't yet tell you whether the new secret was installed on your side; the evidence supports the Chapter 4 "two-sided" hypothesis, which Chapter 8 will test and fix.

Hands-On Exercises

All three use fictional organisations and values. Never put real secrets, tokens or tenant details into practice notes.