Read one event end to end and follow its request ID

Setup

1. Press Start on this page.

2. In Administrators, confirm your role grants both Audit and Logs read access (tenant.audit.read and tenant.logs.read). They are separate permissions.

Walkthrough

1. Open Audit, choose the source Protocol activity, and find Cora's account.security event with reason method_enrolled from the previous lab. Open its details and read each field: message, time, operation, outcome, reason, actor, subject, service, HTTP status and request ID.

Why it matters: these answer the lesson's first questions: who did what to whom, when, and how it ended. When Cora changes her own account, the actor and subject are both Cora's account.

2. Look for anything secret in the record: the authenticator's shared secret, the code Cora typed, her session cookie. None is there.

Why it matters: records travel and are kept for weeks. A record holding a code or cookie would be a credential store with weaker protection than the real one.

3. Filter the outcome to rejected and open an account.sign_in event with reason invalid_credentials from the guessing lab. It has no actor and no subject.

Why it matters: a typed address is a claim anyone can make, so it must never be recorded as the actor. The lesson goes further and names the account the address matched as the subject of the attempt; your tenant does not yet, which is one of the gaps below.

4. Switch the source to User directory and open the tenant.users.methods.reset event for Cora. Here the actor is you and the subject is Cora. Press Find related events to search by its request ID.

Why it matters: when a help desk agent acts on someone else, the actor and subject differ, and a record that kept only one would hide either who acted or who was affected. The request ID joins everything written while handling that one request.

5. Open Logs, source Protocol summaries. Each row summarizes one day of requests with the same operation, outcome and reason, with a count and the first and latest request IDs. Open Collection and retention at the bottom of the page and read the retention period and whether any records were dropped.

Why it matters: the lesson separates audit history (who did what) from operational logs (how requests were handled). A visible coverage gap tells an investigator that missing records are not the same as nothing happening.

6. Go back to Audit, source User directory, and find your own reads: tenant.protocol.audit.detail and tenant.protocol.logs.list, with you as the actor.

Why it matters: every search of the history is itself recorded, so a curious or compromised reviewer leaves a trail too.

Break it

1. In a private window, sign in as Ben, who holds lab-support without Audit access. Open $ISSUER/manage/audit and choose the source Protocol activity. The tenant refuses to return the records. Nothing was changed, so there is nothing to restore.

Why it matters: reading needs control as well as writing. Audit and Logs are granted separately, so a help desk role does not see the tenant's history by default.

Check your work

• Check my progress confirms the event detail you opened, the directory history read, the Logs read and Ben's refusal.

• Your notes list every field of Cora's record, the fields it lacks compared with the lesson's example (session, network, device, method), and the retention period.

• In Audit, source User directory, Ben's refused tenant.protocol.audit.list names him as the actor with reason access_denied.

Cleanup

• None. Nobody, including you, can edit or delete an individual record.

Missing infrastructure

• G37: records hold no session ID, source network, device or sign-in method, and a refused sign-in does not name the account the typed address matched. Once it exists, the lab will compare Cora's record field by field with the lesson's example.

• G41: there is no export or legal hold, so records leave after the retention period even during an investigation.