Read the log and sessions

Who changed what? Who accessed what, and when? Who's signed in right now? The Protokoll (Log) area answers all three questions.

The area has three tabs: Änderungsprotokoll (Change log), which records every administrative change permanently; Audit, which shows the requests for as long as the service keeps them (the header names how long and since when); and Sitzungen (Sessions), which lists the second-factor sessions that have been started. The change log and the audit are grouped by day and person: the newest days at the top, the people within a day from Z to A, and their entries newest first. Sessions are listed by when they were started, newest at the top.

Trace a change

1. Open Protokoll and go to the Änderungsprotokoll tab.
2. Expand the day, and then the person under it.
3. Each row shows the Aktion (Action: insert, update, delete, command), Menge (Entity set), Zeile (Row), Zeitpunkt (Time), and the Vorher (Before) and Nachher (After) values.

Trace an access

1. Go to the Audit tab and expand the day and the caller.
2. Each row shows the Ressource (Resource), Datensatz oder Abfrage (Record or query: the path and query of the request, for example …/Vertraege(17)), Erlaubt durch (Allowed by: the access rule with its version, for example vertrieb@3f2a…), Methode (Method), Datenquelle (Data source), Ergebnis (Result), and Status (for example, 200, 401, or 403), plus the Anweisung (Statement) for custom SQL statements. If a sign-in rule refused the request, Abweisende Anmelderegel (Refusing sign-in rule) names it with its number and version (7@…).

Show who read a record

1. Open Protokoll (Log), tab Audit.
2. Right-click the column header Datensatz oder Abfrage, choose Filterzeile anzeigen (Show filter row), and enter the key below it, for example *(17)*. What remains are the requests for this record, with the day and caller above them.
3. Erlaubt durch names the rule and its version at the time. If Regeln (Rules) shows a different version for the rule, the rule has changed since; the Änderungsprotokoll (Change log) shows what changed.

End a session

1. Go to the Sitzungen tab. Zustand (State) shows “offen” (open), “abgelaufen” (expired), or “beendet” (ended). Sitzungs-Kennung (Session ID, t…) identifies the session, and Schlüssel-Kennung (Key ID, k…) identifies the key it was started with (empty for a Windows or SQL sign-in). Both IDs are random and reveal nothing about the key or the code.
2. Select the session's Beendet (Ended) check box. The person's next request asks for a new code. You can do the same under Personen und Schlüssel (People and keys): select the person, open the Sitzungen (Sessions) tab below the list (Weitere (More) > Darunter zeigen (Show below) > Sitzungen der Person (Person's sessions)), select the session, choose Zweiter Faktor und Sitzung (Second factor and session) > Sitzung beenden (End session), and confirm.

Result: You can see who did what and when, and you can end a suspicious session right away.

• How far back the audit goes: as far as the service keeps it in its log file (365 days by default; if the file grows too large, the service removes the oldest entries earlier). You set both under Anmelderichtlinie (Sign-in policy), Einstellungen (Settings) tab: Aufbewahrung der Zugriffe (Retention of requests) and Größe der Protokolldatei (Log file size); an empty field means the service's configuration applies. Restarting the service doesn't clear the audit. Requests from before the service version that records the record and the rule have these two columns empty.
• Access secrets never appear. A changed connection string shows up in the change log only as “neu gesetzt” (newly set), and keys appear only with their ID (k…). What does appear: the text of custom SQL statements in the audit, and the before and after values of every change to a person (name, accounts, email address). So if a SQL statement contains a value someone wants to keep secret (such as a password in a procedure), it shows up in the audit too.
• anonym … 401 right before a Windows sign-in is the first step of the sign-in handshake, not an attack.
• Exporting: Choose Exportieren … (Export …) in the command bar or on the shortcut menu (Excel, XML, or JSON). The file contains personal data (who accessed or changed what, when, and from where), and once exported, it's outside the app. Store it only where the log itself belongs, and delete it once it has served its purpose (see Security and privacy).
• Retention: The audit is kept as described above; in an additional log target of the service (Event Log, journal), the retention is whatever the operator has set there. The change log stays in the administration store indefinitely. The service never trims it and offers no way to delete or pseudonymize entries (see Security and privacy).
• Filtering and searching: Use the filter list in the column header, or search with Ctrl+F.

• Create evidence reports
• Revoke a key or lock a person
• Reference: HTTP: administration (reference), entity set AuditEntries (data service documentation)