Inhalte: Wochen 13 bis 16

- Woche 13 Linux-Grundlagen (B3, A6, LF9)
- Woche 14 Betrieb und Ueberwachung (A8, A5, LF11)
- Woche 15 Serviceanfragen bearbeiten (A1, A2, A5, LF6)
- Woche 16 Vorbereitung auf Teil 1 (C3, C4, A10, LF2, LF5)

12 Handouts, 36 Merkkarten, 4 Praxisaufgaben, 3 Checklisten,
2 Lernzielkontrollen und eine Probepruefung Teil 1 (90 Minuten,
100 Punkte, eine durchgehende Fallsituation). Alle Rechenbeispiele
nachgerechnet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

content/handouts/S10-protokolle-und-zeit.md

@@ -0,0 +1,64 @@
+---
+id: S10
+titel: Protokolle lesen – und warum die Uhrzeit stimmen muss
+block: system
+woche: 14
+worum: Protokolle sagen, was passiert ist. Aber nur, wenn man weiß, wo man suchen muss, und wenn die Uhren aller Systeme übereinstimmen.
+rahmenplan: [A8, A6, B3]
+lernfeld: LF11
+merksatz: Zeitpunkt eingrenzen, dann suchen. Alle Uhren per NTP gleich. Protokolle enthalten personenbezogene Daten.
+karten:
+  - frage: Welche drei Protokolle der Windows-Ereignisanzeige sind für die Fehlersuche am wichtigsten?
+    antwort: System (Treiber, Dienste, Neustarts), Anwendung (Meldungen der Programme) und Sicherheit (Anmeldungen, Zugriffe, Änderungen an Konten).
+  - frage: Warum muss die Uhrzeit auf allen Systemen übereinstimmen?
+    antwort: Damit sich Ereignisse aus verschiedenen Protokollen einander zuordnen lassen, und weil Kerberos-Anmeldungen im Active Directory scheitern, wenn die Uhren um mehr als fünf Minuten abweichen.
+  - frage: Was bedeuten die Ereignis-IDs 4624 und 4625 im Sicherheitsprotokoll von Windows?
+    antwort: 4624 ist eine erfolgreiche Anmeldung, 4625 eine fehlgeschlagene. Viele 4625 in kurzer Zeit für dasselbe Konto deuten auf Passwortraten hin.
+---
+
+## Das Wesentliche
+
+- **Erst den Zeitpunkt eingrenzen, dann suchen.** „Seit wann?" ist die wichtigste Frage bei
+  jeder Störung. Wer den Zeitraum kennt, findet die Ursache im Protokoll in Minuten statt
+  Stunden.
+- **Windows – Ereignisanzeige:** Protokoll *System* für Dienste, Treiber und Neustarts,
+  *Anwendung* für Programme, *Sicherheit* für Anmeldungen und Zugriffe. Filtern nach Zeitraum,
+  Ebene (Fehler, Warnung) und Ereignis-ID.
+- **Linux – Journal:** `journalctl --since "2026-10-05 08:00" --until "09:00"`, `-u dienst`
+  für einen Dienst, `-p err` für Fehler. Klassische Textdateien unter `/var/log`.
+- **Bekannte Ereignis-IDs sparen Zeit:** 4624 Anmeldung erfolgreich, 4625 fehlgeschlagen,
+  4740 Konto gesperrt, 6008 unerwartetes Herunterfahren, 41 (Kernel-Power) Neustart ohne
+  sauberes Herunterfahren.
+- **Zeitsynchronisation:** Alle Systeme beziehen ihre Zeit per **NTP** aus derselben Quelle –
+  in einer Domäne vom Domänencontroller, dieser von einer verlässlichen externen Quelle.
+  Weichen Uhren um mehr als fünf Minuten ab, scheitert die Anmeldung über Kerberos.
+- **Zentral sammeln:** Bei mehr als einer Handvoll Systeme gehören die Protokolle an einen
+  zentralen Ort. Dann lässt sich eine Anmeldung über mehrere Systeme verfolgen – und ein
+  Angreifer kann seine Spuren nicht auf dem befallenen System löschen.
+- **Protokolle sind personenbezogen.** Sie zeigen, wer sich wann wo angemeldet hat. Deshalb:
+  Aufbewahrung begrenzen, Zugriff beschränken, nur für den vereinbarten Zweck auswerten.
+
+## Übersicht
+
+| Frage | Windows | Linux |
+|---|---|---|
+| Warum ist der Server neu gestartet? | System, Ereignis 6008 bzw. 41 und 1074 | `journalctl --list-boots`, `last -x reboot` |
+| Wer hat sich angemeldet? | Sicherheit, Ereignis 4624 | `last`, `journalctl -u ssh` |
+| Warum startet der Dienst nicht? | System, Quelle „Service Control Manager" | `systemctl status`, `journalctl -u dienst` |
+| Stimmt die Uhrzeit? | `w32tm /query /status` | `timedatectl` |
+
+## Prüfungsfrage
+
+**Frage:** Mehrere Benutzer können sich seit heute Morgen nicht mehr an der Domäne anmelden,
+andere schon. Die Fehlermeldung nennt einen Zeitunterschied. Erklären Sie die Ursache und Ihr
+Vorgehen.
+
+**Antwort:** Die Anmeldung im Active Directory erfolgt über Kerberos, das nur eine geringe
+Abweichung der Uhrzeiten zwischen Client und Domänencontroller zulässt (standardmäßig fünf
+Minuten). Bei den betroffenen Rechnern geht die Uhr vermutlich falsch, etwa weil die
+Zeitsynchronisation nicht läuft oder eine leere CMOS-Batterie die Uhr nach einem Neustart
+zurückgesetzt hat. Vorgehen: (1) Auf einem betroffenen Client mit `w32tm /query /status`
+Zeitquelle und Abweichung prüfen. (2) Prüfen, ob der Domänencontroller selbst die richtige
+Zeit hat und von einer verlässlichen Quelle bezieht. (3) Die Zeit mit `w32tm /resync`
+synchronisieren und die Anmeldung testen. (4) Die Ursache beheben – Zeitdienst, Gruppenrichtlinie
+für die Zeitquelle oder Batterie – und die Zeitabweichung in die Überwachung aufnehmen.