# 8. Betriebssystem- und Serveranalyse # 8.1 Windows-Prozesse und Dienste gezielt untersuchen **Kurzbeschreibung** Wenn ein Windows-System langsam reagiert, eine Anwendung nicht startet, ein Dienst ausfällt oder ein Prozess ungewöhnliche Ressourcen verbraucht, muss der verursachende Prozess einschließlich seiner Abhängigkeiten untersucht werden. Windows-Bordmittel und die Microsoft-Sysinternals-Werkzeuge ermöglichen unter anderem die Analyse von: - Prozessen und untergeordneten Prozessen, - Diensten, - Threads, - CPU- und Arbeitsspeichernutzung, - geöffneten Dateien und Handles, - geladenen DLLs, - Registry-Zugriffen, - Dateisystemzugriffen, - Netzwerkverbindungen, - Autostarteinträgen, - Programmabstürzen, - nicht mehr reagierenden Anwendungen. Ein auffälliger Prozess ist nicht automatisch die eigentliche Ursache. Er kann selbst auf eine Datei, eine Sperre, einen Treiber, eine Datenbank, das Netzwerk oder einen anderen Dienst warten. --- **1. Typische Symptome** - Anwendung startet nicht. - Anwendung reagiert nicht mehr. - Dienst beendet sich unerwartet. - Dienst bleibt im Zustand „Wird gestartet“ oder „Wird beendet“. - CPU-Auslastung ist dauerhaft hoch. - Arbeitsspeicherverbrauch wächst kontinuierlich. - Datenträger wird durch einen Prozess stark ausgelastet. - Datei kann nicht gelöscht, verschoben oder überschrieben werden. - Anwendung meldet „Zugriff verweigert“. - Prozess öffnet ungewöhnlich viele Dateien oder Registry-Schlüssel. - Netzwerkverbindung wird von einem unbekannten Prozess hergestellt. - Programm funktioniert nur mit Administratorrechten. - Fehler tritt nur nach der Anmeldung oder nach einem Neustart auf. - Systemstart oder Benutzeranmeldung dauert ungewöhnlich lange. - Anwendung stürzt ohne eindeutige Fehlermeldung ab. - Ereignisanzeige enthält Anwendungs-, Dienst- oder Treiberfehler. - Prozesse werden mehrfach oder unerwartet gestartet. - Anwendung funktioniert nach einem Prozessneustart nur vorübergehend. --- **2. Mögliche Auswirkungen** - einzelne Anwendung nicht verfügbar, - Hintergrunddienst ausgefallen, - mehrere Benutzer betroffen, - Serverdienst nicht erreichbar, - Leistungsprobleme des gesamten Systems, - blockierte Dateien oder Verzeichnisse, - Datenverlust durch einen Programmabsturz, - fehlgeschlagene Sicherung oder Synchronisation, - fehlerhafte Anmeldung oder Benutzerprofilinitialisierung, - Sicherheitsrisiko durch unbekannten Prozess, - Produktionsausfall bei geschäftskritischen Diensten. --- **3. Sicherheits- und Betriebswarnung** Sysinternals-Werkzeuge können tiefgehende Informationen über Prozesse, Benutzer, Dateien und Netzwerkverbindungen anzeigen. Diagnoseergebnisse können enthalten: - Benutzernamen, - interne Pfade, - Servernamen, - IP-Adressen, - Befehlszeilenargumente, - Zugriffstoken, - geladene Module, - Registry-Inhalte, - personenbezogene Daten. Besondere Vorsicht gilt bei: - Beenden eines Prozesses, - Stoppen oder Neustarten eines Dienstes, - Schließen eines Handles, - Deaktivieren eines Autostarteintrags, - Erstellen eines vollständigen Speicherabbilds, - länger laufender Process-Monitor-Aufzeichnung, - Aktivieren zusätzlicher Debugprotokollierung. Ein vollständiges Speicherabbild kann sensible Daten wie Kennwörter, Tokens, Schlüssel oder Anwendungsdaten enthalten. Dump-, ETL- und PML-Dateien müssen deshalb geschützt gespeichert und nach Abschluss der Analyse kontrolliert gelöscht werden. Werkzeuge sollten nur aus der offiziellen Microsoft-Quelle bezogen werden. Vor dem Einsatz auf einem Produktivsystem sind Auswirkung, benötigter Speicherplatz und mögliche Leistungseinflüsse zu prüfen. --- **4. Werkzeugauswahl** | Fragestellung | Geeignetes Werkzeug | |---|---| | Welcher Prozess benötigt CPU oder RAM? | Task-Manager, Ressourcenmonitor, PowerShell, Process Explorer | | Welcher Dienst gehört zu einem Prozess? | Task-Manager, `tasklist /svc`, Process Explorer | | Welcher Prozess hat eine Datei geöffnet? | Ressourcenmonitor, Handle, Process Explorer | | Welche DLLs hat ein Prozess geladen? | Process Explorer, ListDLLs | | Warum erhält eine Anwendung „Zugriff verweigert“? | Process Monitor, AccessChk | | Welcher Prozess stellt eine Netzwerkverbindung her? | TCPView, `Get-NetTCPConnection` | | Was wird beim Systemstart automatisch geladen? | Autoruns | | Warum stürzt eine Anwendung ab? | Ereignisanzeige, Zuverlässigkeitsverlauf, ProcDump, WinDbg | | Warum reagiert ein Prozess nicht mehr? | Process Explorer, ProcDump, Wait-Chain-Analyse | | Welcher Prozess erzeugt Registry- oder Dateisystemzugriffe? | Process Monitor | | Warum ist das System zeitweise langsam? | Leistungsüberwachung, WPR und WPA | | Wie hängen Prozesse zusammen? | Process Explorer | | Welche Prozesse sind signiert? | Process Explorer, Sigcheck | | Welche Berechtigung besitzt ein Benutzer oder Dienst? | AccessChk, `whoami` | --- **5. Benötigte Informationen** Vor der Diagnose sollten mindestens folgende Informationen vorliegen: ```text Computer: Betriebssystem und Build: betroffene Anwendung: betroffener Dienst: Prozessname: Prozess-ID: Benutzerkonto des Prozesses: Beginn des Problems: exakte Fehlermeldung: Fehlercode oder Event-ID: reproduzierbar: letzter funktionierender Zeitpunkt: letzte Änderung: betroffene Benutzer: Auswirkung: bereits durchgeführte Maßnahmen: ``` Zusätzlich hilfreich: - Installations- oder Updatezeitpunkt, - Anwendungsversion, - Dienstkonto, - erwartete Netzwerkziele, - erwartete Dateien und Registry-Pfade, - funktionierendes Vergleichssystem, - Baseline der normalen Ressourcennutzung. --- **6. Ausgangszustand sichern** Vor einem Neustart oder dem Beenden eines Prozesses sollten flüchtige Informationen dokumentiert werden. ```powershell Get-Date Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, OsLastBootUpTime ``` Laufende Prozesse sichern: ```powershell Get-Process | Sort-Object ProcessName | Select-Object ProcessName, Id, CPU, WorkingSet64, Handles, Threads ``` Laufende Dienste sichern: ```powershell Get-Service | Where-Object Status -eq 'Running' | Sort-Object Name ``` Aktive TCP-Verbindungen sichern: ```powershell Get-NetTCPConnection | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Ereignisse der letzten zwei Stunden: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System', 'Application' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, LogName, Id, LevelDisplayName, ProviderName, Message ``` Die Ausgabe kann bei Bedarf kontrolliert in Dateien exportiert werden. Dabei sind Datenschutz und Speicherort zu beachten. --- **7. Sichere Schnellprüfung** 1. Exakte Fehlermeldung und Uhrzeit dokumentieren. 2. Prozess- und Dienststatus prüfen. 3. CPU, Arbeitsspeicher, Handles und Threads vergleichen. 4. System- und Anwendungsereignisse zum Fehlerzeitpunkt untersuchen. 5. Mit Process Explorer Prozessbaum und Eigenschaften prüfen. 6. Mit Process Monitor nur den betroffenen Prozess aufzeichnen. 7. Netzwerkverbindungen mit TCPView oder PowerShell prüfen. 8. Erst nach gesicherter Diagnose eine kontrollierte Maßnahme durchführen. --- **8. Prozesse mit PowerShell untersuchen** Alle Prozesse anzeigen: ```powershell Get-Process ``` Prozesse nach CPU-Gesamtzeit sortieren: ```powershell Get-Process | Sort-Object CPU -Descending | Select-Object -First 15 ProcessName, Id, CPU, WorkingSet64, Handles, Threads ``` Prozesse nach Arbeitsspeicher sortieren: ```powershell Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 15 ProcessName, Id, WorkingSet64, PagedMemorySize64, VirtualMemorySize64 ``` Prozesse mit vielen Handles: ```powershell Get-Process | Sort-Object Handles -Descending | Select-Object -First 15 ProcessName, Id, Handles ``` Bestimmten Prozess untersuchen: ```powershell Get-Process -Id | Format-List * ``` Prozess mit CIM einschließlich Befehlszeile und Elternprozess: ```powershell Get-CimInstance Win32_Process | Where-Object ProcessId -eq | Select-Object Name, ProcessId, ParentProcessId, ExecutablePath, CommandLine, CreationDate ``` Der Wert `CPU` bei `Get-Process` ist die seit dem Prozessstart verbrauchte Prozessorzeit und keine momentane prozentuale CPU-Auslastung. --- **9. Prozess-ID und Dienst zuordnen** Eine Prozess-ID kann sich nach jedem Neustart des Prozesses ändern. Bei der Dokumentation müssen deshalb PID, Zeitpunkt und Prozessstart zusammen betrachtet werden. Windows-Befehl: ```cmd tasklist /svc ``` Bestimmte PID suchen: ```cmd tasklist /svc /fi "PID eq " ``` Dienste einschließlich Prozess-ID: ```powershell Get-CimInstance Win32_Service | Select-Object Name, DisplayName, State, StartMode, ProcessId, StartName ``` Dienst zu einer PID suchen: ```powershell Get-CimInstance Win32_Service | Where-Object ProcessId -eq | Select-Object Name, DisplayName, State, StartMode, StartName ``` Mehrere Windows-Dienste können innerhalb desselben `svchost.exe`-Prozesses ausgeführt werden. Der Prozessname allein reicht deshalb nicht zur eindeutigen Zuordnung. --- **10. Dienste untersuchen** Alle Dienste: ```powershell Get-Service | Sort-Object Status, Name ``` Automatisch startende, aber nicht laufende Dienste: ```powershell Get-CimInstance Win32_Service | Where-Object { $_.StartMode -eq 'Auto' -and $_.State -ne 'Running' } | Select-Object Name, DisplayName, State, StartMode, StartName, ExitCode ``` Bestimmten Dienst prüfen: ```powershell Get-Service -Name ``` Ausführliche Dienstkonfiguration: ```cmd sc.exe qc ``` Aktuellen Dienststatus: ```cmd sc.exe queryex ``` Abhängigkeiten anzeigen: ```powershell Get-Service -Name -DependentServices Get-Service -Name -RequiredServices ``` Zu prüfen sind: - Starttyp, - aktueller Status, - Dienstkonto, - ausführbare Datei, - Abhängigkeiten, - Rücksetzungs- und Wiederherstellungsoptionen, - Exit-Code, - wiederholte Neustarts, - Zeitüberschreitungen beim Start, - benötigte Dateien und Netzwerkziele. Ein Dienst darf nicht allein deshalb gestartet werden, weil sein Starttyp auf „Automatisch“ steht. Verzögert gestartete Dienste, Triggerstart, Clustersteuerung oder bewusst deaktivierte Komponenten müssen berücksichtigt werden. --- **11. Ereignisanzeige untersuchen** Wichtige Protokollbereiche: - Windows-Protokolle → Anwendung - Windows-Protokolle → System - Windows-Protokolle → Sicherheit - Anwendungs- und Dienstprotokolle - Microsoft → Windows → Windows Error Reporting - Microsoft → Windows → Diagnostics-Performance - herstellerspezifische Anwendungsprotokolle Fehler und Warnungen der letzten zwei Stunden: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System', 'Application' Level = 2, 3 StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, LogName, Id, ProviderName, LevelDisplayName, Message ``` Ereignisse eines bestimmten Anbieters: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Application' ProviderName = '' StartTime = (Get-Date).AddHours(-2) } ``` Ereignisse eines bestimmten Zeitraums: ```powershell $Start = Get-Date '2026-08-02 09:00:00' $Ende = Get-Date '2026-08-02 10:00:00' Get-WinEvent -FilterHashtable @{ LogName = 'System', 'Application' StartTime = $Start EndTime = $Ende } ``` Wichtige Grundregel: > Zuerst nach Zeitpunkt, betroffener Komponente und technischer Wirkung filtern. Nicht jeder Fehler oder jede Warnung in der Ereignisanzeige gehört zur untersuchten Störung. --- **12. Dienstfehler im Systemprotokoll** Der Service Control Manager protokolliert Start-, Stopp- und Dienstfehler im Systemprotokoll. Beispielhafte Abfrage: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'System' ProviderName = 'Service Control Manager' StartTime = (Get-Date).AddHours(-4) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Häufig relevante Ereignisarten betreffen: - unerwartet beendete Dienste, - fehlgeschlagene Dienststarts, - Zeitüberschreitungen, - ungültige Dienstkonten, - fehlende Dateien, - fehlerhafte Abhängigkeiten. Event-IDs dürfen nicht ohne Prüfung von Provider, Windows-Version und vollständigem Ereignistext interpretiert werden. --- **13. Process Explorer verwenden** Process Explorer zeigt Prozesse hierarchisch in einem Prozessbaum an. Wichtige Informationen: - Eltern- und Kindprozesse, - Benutzerkonto, - Integritätsstufe, - Befehlszeile, - ausführbare Datei, - digitale Signatur, - Prozessstart, - CPU-Auslastung, - private Bytes, - Working Set, - Threads, - Handles, - geladene DLLs, - TCP/IP-Aktivität, - Sicherheits-Token. Empfohlene Vorgehensweise: 1. Process Explorer als Administrator starten, wenn erhöhte Prozesse untersucht werden müssen. 2. `View → Show Process Tree` verwenden. 3. Unter `View → Select Columns` benötigte Spalten aktivieren. 4. Betroffenen Prozess markieren. 5. Eigenschaften des Prozesses öffnen. 6. Image, Performance, Threads, TCP/IP und Security prüfen. 7. Prozesspfad und digitale Signatur kontrollieren. 8. Eltern- und Kindprozesse dokumentieren. 9. Auffällige Threads oder Handles untersuchen. 10. Prozess erst nach Sicherung der Ergebnisse verändern. Hilfreiche Markierungen im Prozessbaum können auf unterschiedliche Prozessarten oder Lebenszyklen hinweisen. Die Farbdarstellung ist konfigurierbar und darf nicht ohne Prüfung der eingestellten Farblegende interpretiert werden. --- **14. Threads untersuchen** Ein Prozess kann insgesamt unauffällig erscheinen, obwohl ein einzelner Thread dauerhaft einen CPU-Kern beansprucht. In Process Explorer: 1. Prozess öffnen. 2. Registerkarte `Threads` auswählen. 3. Threads nach CPU-Auslastung sortieren. 4. Thread-ID und Startadresse dokumentieren. 5. bei verfügbaren Symbolen den Stack untersuchen. 6. geladenes Modul oder zugehörige DLL bestimmen. Mögliche Befunde: | Befund | Mögliche Bedeutung | |---|---| | ein Thread dauerhaft stark ausgelastet | Endlosschleife oder Single-Thread-Engpass | | viele Threads entstehen fortlaufend | Thread-Leak oder fehlerhafte Parallelisierung | | Thread wartet lange | Datei, Netzwerk, Lock oder externe Komponente | | Startadresse gehört zu Drittanbieter-DLL | Anwendung oder Erweiterung untersuchen | | Startadresse gehört zu Sicherheitssoftware | Scan oder Filtertreiber als mögliche Beteiligung prüfen | | Prozess hat ungewöhnlich viele Threads | Worker-Konfiguration, Deadlock oder fehlerhafte Anwendung | Das Beenden eines einzelnen Threads kann den Prozess beschädigen und ist keine sichere Standardmaßnahme. --- **15. Nicht reagierende Anwendungen und Wait Chains** Eine Anwendung kann als „Keine Rückmeldung“ erscheinen, wenn ihr Oberflächenthread nicht rechtzeitig auf Windows-Nachrichten reagiert. Mögliche Ursachen: - lang laufende Berechnung, - blockierte Dateioperation, - Netzwerk-Timeout, - Datenbankabfrage, - gegenseitige Sperre, - blockierter untergeordneter Prozess, - nicht reagierende Erweiterung, - Treiberproblem. Im Ressourcenmonitor kann über die CPU-Ansicht bei einem Prozess die Warteschlange beziehungsweise Wait Chain analysiert werden. Ein möglicher Deadlock liegt vor, wenn mehrere Threads oder Prozesse gegenseitig auf Ressourcen warten. Die Wait-Chain-Analyse liefert einen Hinweis, aber nicht immer einen vollständigen Ursachennachweis. Vor dem Beenden eines wartenden Prozesses sollten Dump, Ereignisse und Anwendungslogs gesichert werden. --- **16. Geöffnete Dateien und Handles untersuchen** Eine Datei kann nicht gelöscht oder umbenannt werden, wenn ein Prozess ein passendes Handle geöffnet hält. Process Explorer: 1. `Find → Find Handle or DLL` öffnen. 2. Teil des Datei- oder Verzeichnisnamens eingeben. 3. gefundenen Prozess und Handle-Typ prüfen. 4. Anwendung möglichst regulär schließen. 5. erst danach einen kontrollierten Prozess- oder Dienstneustart erwägen. Handle als Kommandozeilenwerkzeug: ```cmd handle.exe "" ``` Nach PID filtern: ```cmd handle.exe -p ``` Das direkte Schließen eines Handles kann: - Datenverlust verursachen, - eine Anwendung zum Absturz bringen, - einen inkonsistenten Zustand erzeugen, - eine Transaktion oder Sperrlogik beschädigen. Ein Handle sollte deshalb nicht als erste Maßnahme erzwungen geschlossen werden. --- **17. Geladene DLLs untersuchen** Process Explorer kann im unteren Fensterbereich Handles oder geladene DLLs anzeigen. Umschalten: ```text View → Lower Pane View → DLLs ``` Zu prüfen sind: - vollständiger DLL-Pfad, - Hersteller, - digitale Signatur, - Version, - Ladezeitpunkt, - unerwartete Verzeichnisse, - unterschiedliche Versionen derselben Bibliothek, - nicht signierte Erweiterungen. ListDLLs: ```cmd listdlls.exe ``` Nach einer bestimmten DLL suchen: ```cmd listdlls.exe -d ``` Eine unbekannte oder nicht signierte DLL ist nicht automatisch Schadsoftware. Sie muss anhand von Pfad, Hersteller, Signatur, Hash, Installationszusammenhang und Sicherheitsprüfung bewertet werden. --- **18. Process Monitor verwenden** Process Monitor zeichnet in Echtzeit unter anderem folgende Ereignisse auf: - Dateisystemzugriffe, - Registry-Zugriffe, - Prozess- und Threadaktivität, - Laden von DLLs, - bestimmte Profilierungsereignisse. Da sehr viele Ereignisse entstehen können, muss die Aufzeichnung gefiltert und zeitlich begrenzt werden. Empfohlener Ablauf: 1. Process Monitor starten. 2. Aufzeichnung zunächst anhalten. 3. vorhandene Ereignisse leeren. 4. Filter für den betroffenen Prozess setzen. 5. nur benötigte Ereignisklassen aktivieren. 6. Aufzeichnung starten. 7. Fehler genau einmal reproduzieren. 8. Aufzeichnung sofort anhalten. 9. Ereignisse rund um den Fehlerzeitpunkt untersuchen. 10. Aufzeichnung geschützt speichern oder nach Abschluss löschen. Beispielhafte Filter: ```text Process Name is then Include ``` oder: ```text PID is then Include ``` Zusätzliche Filter können beispielsweise betreffen: ```text Result is ACCESS DENIED Result is NAME NOT FOUND Result is PATH NOT FOUND Operation is CreateFile Operation is RegOpenKey ``` --- **19. Process-Monitor-Ergebnisse bewerten** Häufige Ergebnisse: | Ergebnis | Bedeutung | |---|---| | `SUCCESS` | Operation wurde erfolgreich ausgeführt | | `NAME NOT FOUND` | Objekt mit diesem Namen wurde nicht gefunden | | `PATH NOT FOUND` | Teil des Pfades wurde nicht gefunden | | `ACCESS DENIED` | Zugriff wurde durch Berechtigung oder Sicherheitsmechanismus verweigert | | `SHARING VIOLATION` | Objekt wird in nicht kompatibler Weise verwendet | | `BUFFER OVERFLOW` | häufig normaler Teil einer Größenabfrage | | `NO MORE FILES` | Verzeichnisaufzählung ist beendet | | `REPARSE` | Pfad wurde über einen Reparse Point weitergeleitet | Nicht jeder rote oder fehlgeschlagene Eintrag ist ein Fehler. Anwendungen prüfen häufig mehrere mögliche Pfade, Registry-Schlüssel oder Dateinamen, bevor sie den tatsächlich vorhandenen Eintrag verwenden. Ein relevanter Befund entsteht erst, wenn: - der Zeitpunkt mit dem Symptom übereinstimmt, - das Objekt für die Funktion benötigt wird, - keine erfolgreiche Ausweichoperation folgt, - das Ergebnis technisch zum Fehler passt, - der Fehler reproduzierbar ist. --- **20. „Zugriff verweigert“ untersuchen** Mögliche Ursachen: - fehlende NTFS-Berechtigung, - fehlende Freigabeberechtigung, - fehlendes Benutzerrecht, - niedrige Integritätsstufe, - UAC, - Dienstkonto ohne erforderliche Rechte, - Datei durch Sicherheitssoftware blockiert, - Controlled Folder Access, - Zugriff auf geschützten Registry-Bereich, - Netzwerkzugriff unter einem anderen Konto, - Anwendung verwendet einen falschen Pfad. Aktuelle Identität: ```cmd whoami ``` Gruppen und Sicherheitskennungen: ```cmd whoami /groups ``` Privilegien: ```cmd whoami /priv ``` Effektive NTFS-Berechtigungen sollten mit den Windows-Sicherheitseinstellungen oder einem kontrollierten Werkzeug geprüft werden. AccessChk-Beispiel: ```cmd accesschk.exe -nobanner -v "" "" ``` Die genaue Syntax ist vor dem produktiven Einsatz anhand der aktuellen Microsoft-Dokumentation zu prüfen. Die dauerhafte Ausführung einer Anwendung als Administrator ist keine fachgerechte Standardlösung. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden. --- **21. Netzwerkverbindungen einem Prozess zuordnen** PowerShell: ```powershell Get-NetTCPConnection | Sort-Object State, RemoteAddress | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` Verbindungen eines bestimmten Prozesses: ```powershell Get-NetTCPConnection | Where-Object OwningProcess -eq ``` Prozess zuordnen: ```powershell Get-Process -Id ``` TCPView zeigt: - lokale Adresse, - lokalen Port, - entfernte Adresse, - entfernten Port, - Verbindungsstatus, - zugehörigen Prozess, - Prozess-ID. Zu prüfen sind: - erwartetes Ziel, - erwarteter Port, - wiederholte Verbindungsversuche, - viele Verbindungen im selben Zustand, - Verbindung zu nicht erwarteten Systemen, - Verbindung nur über IPv4 oder IPv6, - kurzzeitig entstehende Verbindungen, - Portkonflikte. Eine unbekannte Verbindung ist nicht automatisch bösartig. DNS, CDN, Update-, Telemetrie-, Lizenz- und Cloud-Dienste können externe Ziele verwenden. Der Zusammenhang muss geprüft werden. --- **22. Listener und Portkonflikte untersuchen** Lauschende TCP-Ports: ```powershell Get-NetTCPConnection -State Listen | Sort-Object LocalPort | Select-Object LocalAddress, LocalPort, OwningProcess ``` Prozess zu einem Port suchen: ```powershell Get-NetTCPConnection -LocalPort | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Mit klassischem Windows-Befehl: ```cmd netstat -ano ``` Mögliche Befunde: | Befund | Mögliche Bedeutung | |---|---| | erwarteter Port fehlt | Dienst läuft nicht oder bindet nicht | | Port nur an `127.0.0.1` gebunden | nur lokaler Zugriff möglich | | Port an unerwartete Adresse gebunden | Konfiguration prüfen | | andere PID verwendet den Port | Portkonflikt | | viele Verbindungen in `SYN_SENT` | Ziel oder Netzwerk antwortet nicht | | viele Verbindungen in `TIME_WAIT` | hohe Verbindungsrate oder fehlendes Connection-Reuse | | viele Verbindungen in `CLOSE_WAIT` | Anwendung schließt empfangene Verbindungen nicht korrekt | | Listener vorhanden, Zugriff scheitert | Firewall, TLS, Anwendung oder Rückweg prüfen | --- **23. Autostarts mit Autoruns untersuchen** Autoruns zeigt deutlich mehr Autostartorte als der Task-Manager. Zu den möglichen Kategorien gehören: - Benutzeranmeldung, - Dienste, - Treiber, - geplante Aufgaben, - Explorer-Erweiterungen, - Browserkomponenten, - Winlogon-Komponenten, - AppInit- und Image-Hijack-Einträge, - Codecs, - Office-Erweiterungen. Empfohlene Vorgehensweise: 1. Autoruns als Administrator starten. 2. vollständige Erfassung abwarten. 3. Microsoft-Einträge bei Bedarf ausblenden, ohne sie zu löschen. 4. nach nicht vorhandenen Dateien suchen. 5. Publisher und Signatur prüfen. 6. Eintrag, Pfad und Kategorie dokumentieren. 7. verdächtigen Eintrag zunächst deaktivieren statt löschen. 8. Neustart- oder Anmeldetest kontrolliert durchführen. 9. bei ausbleibender Wirkung Eintrag wieder aktivieren. Ein nicht signierter Autostarteintrag ist nicht automatisch Schadsoftware. Herkunft, Pfad, Hash, Installationszeitpunkt und Sicherheitsmeldungen müssen gemeinsam bewertet werden. --- **24. Digitale Signaturen mit Sigcheck prüfen** Beispiel: ```cmd sigcheck.exe -nobanner -a -h "" ``` Mögliche Prüfpunkte: - digitale Signatur vorhanden, - Signatur gültig, - Herausgeber erwartet, - Zeitstempel vorhanden, - Dateiversion, - Produktname, - kryptografischer Hash, - Pfad der Datei. Eine gültige Signatur beweist, dass die Datei seit der Signierung nicht unbemerkt verändert wurde und zu welchem Zertifikat sie gehört. Sie beweist nicht automatisch, dass die Software erwünscht, fehlerfrei oder für den konkreten Einsatzzweck sicher ist. Online-Prüfungen oder Uploads zu externen Diensten dürfen nur unter Beachtung von Datenschutz, Geheimhaltung und Unternehmensrichtlinien durchgeführt werden. --- **25. Abstürze und Hänger mit ProcDump erfassen** ProcDump kann Speicherabbilder unter bestimmten Bedingungen erzeugen, beispielsweise bei: - Prozessabsturz, - unbehandelter Ausnahme, - hoher CPU-Auslastung, - nicht reagierendem Fenster, - bestimmten Leistungsindikatoren. Manuelles vollständiges Speicherabbild: ```cmd procdump.exe -accepteula -ma "" ``` Dump bei unbehandelter Ausnahme: ```cmd procdump.exe -accepteula -e -ma "" ``` Dump bei nicht reagierendem Fenster: ```cmd procdump.exe -accepteula -h -ma "" ``` Vor dem Einsatz muss geprüft werden: - ausreichend freier Speicherplatz, - geschütztes Zielverzeichnis, - mögliche Größe des Dumps, - Datenschutz, - Auswirkung auf den Prozess, - erforderliche Freigabe, - geeignetes Analysewerkzeug, - sichere Übermittlung an Hersteller oder Entwicklung. Ein Dump ist noch keine Fehlerdiagnose. Er muss mit Symbolen und geeigneten Debugwerkzeugen analysiert werden. --- **26. Windows Performance Recorder und Analyzer** Für komplexe oder nur zeitweise auftretende Leistungsprobleme können Windows Performance Recorder und Windows Performance Analyzer eingesetzt werden. WPR erfasst ETW-Ereignisse. WPA stellt die erfassten Daten als Tabellen und Diagramme dar. Typische Analysebereiche: - CPU-Nutzung, - CPU-Nutzung nach Prozess und Thread, - Datenträger-I/O, - Datei-I/O, - DPC und ISR, - Kontextwechsel, - Prozesslebenszyklus, - Start- und Anmeldeleistung, - Netzwerkaktivität, - Arbeitsspeicherverhalten. Grundsätzlicher Ablauf: 1. geeignetes WPR-Profil auswählen. 2. Speicherplatz und Aufzeichnungsmodus prüfen. 3. Aufzeichnung starten. 4. Problem reproduzieren. 5. Aufzeichnung unmittelbar danach stoppen. 6. ETL-Datei geschützt speichern. 7. Datei mit WPA öffnen. 8. Zeitraum des Fehlers markieren. 9. Prozess, Thread und Ressource korrelieren. 10. Aufzeichnung nach Abschluss kontrolliert archivieren oder löschen. Eine ETW-Aufzeichnung kann groß werden und das System zusätzlich belasten. Profil, Dauer und Detailgrad müssen deshalb begrenzt werden. --- **27. Prozesse sicher beenden oder neu starten** Ein Prozess darf erst beendet werden, wenn geklärt wurde: - welche Anwendung oder welcher Dienst betroffen ist, - ob Daten gespeichert wurden, - ob Transaktionen laufen, - ob andere Dienste den Prozess verwenden, - ob der Prozess automatisch neu startet, - ob ein Cluster oder Watchdog zuständig ist, - ob ein Dump benötigt wird, - welche Benutzer betroffen sind, - wie der Rückweg aussieht. Kontrolliertes Beenden ohne Erzwingen: ```powershell Stop-Process -Id -WhatIf ``` `-WhatIf` zeigt nur die geplante Aktion. Erst nach Prüfung: ```powershell Stop-Process -Id ``` Erzwungenes Beenden: ```powershell Stop-Process -Id -Force ``` `-Force` erhöht das Risiko von Datenverlust oder inkonsistenten Zuständen und sollte nur bei begründetem Bedarf verwendet werden. Bei Diensten ist ein kontrollierter Dienstneustart in der Regel besser als das direkte Beenden des zugehörigen Prozesses: ```powershell Restart-Service -Name -WhatIf ``` Danach: ```powershell Restart-Service -Name ``` --- **28. Befundmatrix** | Befund | Bedeutung | Nächster Test | |---|---|---| | Prozess beansprucht dauerhaft einen Kern | einzelner Thread möglicherweise ausgelastet | Threads und Stack in Process Explorer prüfen | | Working Set hoch, aber stabil | möglicherweise normaler Cache | Private Bytes und zeitliche Entwicklung prüfen | | Private Bytes wachsen dauerhaft | mögliches Speicherleck | Verlauf erfassen und Dump erstellen | | Handle-Anzahl wächst dauerhaft | mögliches Handle-Leak | Handle-Typen und geöffnete Objekte prüfen | | Thread-Anzahl wächst dauerhaft | mögliches Thread-Leak | Threaderzeugung und Anwendung untersuchen | | viele `ACCESS DENIED` unmittelbar vor Fehler | Berechtigungsproblem möglich | Identität und effektive Rechte prüfen | | `NAME NOT FOUND`, danach `SUCCESS` | normale Suchlogik möglich | erfolgreichen Zielpfad bestimmen | | `PATH NOT FOUND` ohne erfolgreichen Ersatz | fehlender Pfad oder fehlerhafte Konfiguration | Anwendungskonfiguration prüfen | | Datei ist gesperrt | Prozess hält Handle offen | Handle-Suche durchführen | | Dienst beendet sich wiederholt | Anwendung, Abhängigkeit oder Dienstkonto | Ereignisse und Anwendungslog prüfen | | Dienst bleibt bei „Wird gestartet“ | Initialisierung oder Abhängigkeit hängt | Wait Chain, Netzwerk und Logs prüfen | | Port wird von anderer PID verwendet | Portkonflikt | Prozess und Konfiguration identifizieren | | viele Verbindungen in `CLOSE_WAIT` | Anwendung schließt Verbindungen nicht | Anwendung und Verbindungspool prüfen | | unbekannte DLL geladen | Erweiterung oder mögliche Manipulation | Pfad, Signatur, Hash und Herkunft prüfen | | Fehler nur nach Anmeldung | Autostart oder Benutzerkonfiguration | Autoruns und Benutzerprofil prüfen | | Fehler nur nach Update | Versions- oder Kompatibilitätsproblem | Änderungsverlauf und Herstellerhinweise | | Prozess stürzt ohne sichtbare Meldung ab | Ausnahme oder externe Beendigung | Ereignisse, WER und ProcDump | | Problem nur unter Dienstkonto | Berechtigung oder Benutzerumgebung | Identität, Rechte und Pfade vergleichen | | Anwendung funktioniert nur erhöht | fehlende Berechtigung oder falscher Speicherort | Process Monitor und AccessChk | | mehrere Prozesse gleichzeitig auffällig | gemeinsame Abhängigkeit | Storage, Netzwerk, Sicherheitssoftware | | nach Neustart vorübergehend behoben | Zustand zurückgesetzt, Ursache unbekannt | Langzeitmessung und Dump-Trigger | --- **29. Typische Ursachen und passende Maßnahmen** **Ursache: fehlerhafter oder blockierter Prozess** Nachweis: - Prozess reagiert nicht, - Wait Chain zeigt Blockierung, - Dump oder Log bestätigt den Fehler. Mögliche Maßnahme: - Diagnosezustand sichern, - Anwendung kontrolliert schließen, - betroffenen Dienst oder Prozess neu starten, - Herstelleranalyse durchführen. Rollback: - nicht anwendbar, wenn nur der Prozess neu gestartet wurde; - gegebenenfalls auf vorherige Anwendungsversion zurückwechseln. Verifikation: - ursprüngliche Funktion testen, - Ressourcen und Logs kontrollieren, - Wiederauftreten überwachen. --- **Ursache: fehlende Berechtigung** Nachweis: - Process Monitor zeigt relevanten Zugriff mit `ACCESS DENIED`, - Benutzer- oder Dienstkonto besitzt das benötigte Recht nicht. Mögliche Maßnahme: - genau erforderliche Berechtigung nach dem Minimalprinzip ergänzen, - Dienstkonto oder Pfadkonfiguration korrigieren. Rollback: - hinzugefügte Berechtigung dokumentiert entfernen. Verifikation: - Anwendung unter dem vorgesehenen Konto testen, - keine unnötigen Rechte vergeben. --- **Ursache: fehlende Datei oder fehlerhafter Pfad** Nachweis: - Process Monitor zeigt relevanten Zugriff mit `NAME NOT FOUND` oder `PATH NOT FOUND`, - kein erfolgreicher alternativer Zugriff folgt. Mögliche Maßnahme: - Anwendung reparieren, - Konfigurationspfad korrigieren, - Datei aus vertrauenswürdiger Quelle wiederherstellen. Rollback: - ursprüngliche Konfiguration sichern und wiederherstellen können. Verifikation: - Datei wird erfolgreich geöffnet, - Anwendung funktioniert, - keine neuen Fehler entstehen. --- **Ursache: fehlerhafte Erweiterung oder DLL** Nachweis: - Problem tritt nur mit bestimmter Erweiterung auf, - Process Explorer oder Dump verweist auf das Modul, - Deaktivierung im Test beseitigt den Fehler. Mögliche Maßnahme: - Erweiterung aktualisieren, - kompatible Version installieren, - Erweiterung kontrolliert deaktivieren. Rollback: - vorherige Version oder Konfiguration wiederherstellen. Verifikation: - Anwendung mehrfach starten und Funktion testen. --- **Ursache: fehlerhafter Autostarteintrag** Nachweis: - Problem beginnt bei Anmeldung oder Systemstart, - Autoruns zeigt zugehörigen Eintrag, - kontrollierte Deaktivierung beseitigt das Symptom. Mögliche Maßnahme: - fehlerhafte Software reparieren oder aktualisieren, - nicht benötigten Eintrag deaktivieren. Rollback: - Eintrag in Autoruns wieder aktivieren. Verifikation: - Neustart und erneute Anmeldung testen. --- **Ursache: Portkonflikt** Nachweis: - erwarteter Port gehört einer anderen PID, - Dienstprotokoll meldet fehlgeschlagene Bindung. Mögliche Maßnahme: - doppelte Anwendung beenden, - Portkonfiguration kontrolliert ändern, - Startreihenfolge korrigieren. Rollback: - vorherige Portkonfiguration wiederherstellen. Verifikation: - Listener prüfen, - tatsächlichen Anwendungsport testen. --- **Ursache: Ressourcen- oder Handle-Leak** Nachweis: - Speicher-, Handle- oder Threadanzahl wächst über längere Zeit, - Wachstum korreliert mit dem Symptom, - Dump oder Herstelleranalyse bestätigt die Ursache. Mögliche Maßnahme: - Anwendung aktualisieren, - Konfiguration korrigieren, - bis zur dauerhaften Fehlerbehebung kontrolliertes Wartungsfenster planen. Rollback: - vorherige Anwendungsversion wiederherstellen, sofern freigegeben. Verifikation: - Langzeitmessung wiederholen, - Baseline mit neuem Verlauf vergleichen. --- **30. Nachkontrolle** Nach einer Maßnahme sind dieselben Kriterien erneut zu prüfen: - Prozess läuft erwartungsgemäß. - Dienststatus ist korrekt. - Anwendung reagiert. - CPU-Auslastung ist plausibel. - Arbeitsspeicher wächst nicht unkontrolliert. - Handles und Threads bleiben stabil. - benötigte Dateien können geöffnet werden. - erforderliche Ports sind gebunden. - Netzwerkverbindungen erreichen die vorgesehenen Ziele. - keine neuen Fehler erscheinen in den Protokollen. - Benutzerfunktion wurde praktisch getestet. - abhängige Dienste funktionieren. - temporäre Filter, Traces und Debugfunktionen wurden beendet. - Dump-, PML- und ETL-Dateien wurden geschützt gespeichert oder gelöscht. - deaktivierte Autostarts wurden abschließend bewertet. - Monitoring zeigt wieder den Normalzustand. --- **31. Dokumentation** Beispiel: ```text Symptom: Der Dienst „Beispieldienst“ wurde nach dem Start innerhalb weniger Sekunden wieder beendet. Zeitpunkt: 02.08.2026, 09:42 Uhr MESZ Nachweis: Das Anwendungsprotokoll zeigte den Fehler zum gleichen Zeitpunkt. Process Monitor zeigte unmittelbar davor einen relevanten Zugriff auf C:\ProgramData\Beispiel\config.json mit ACCESS DENIED. Ursache: Das verwendete Dienstkonto besaß nach einer Änderung keine Leseberechtigung mehr für die Konfigurationsdatei. Maßnahme: Die erforderliche Leseberechtigung wurde ausschließlich für das vorgesehene Dienstkonto wiederhergestellt. Rollback: Dokumentierte Berechtigungsänderung kann entfernt werden. Verifikation: Dienst startet erfolgreich. Anwendungsport ist erreichbar. Keine neuen Fehler im Ereignisprotokoll. Funktionstest erfolgreich. Prävention: Berechtigungen des Anwendungsverzeichnisses werden künftig vor und nach Änderungen automatisiert verglichen. ``` --- **32. Entscheidungsbaum** ```text Windows-Anwendung oder Dienst funktioniert nicht ↓ Läuft der erwartete Prozess? ├── Nein │ ↓ │ Dienststatus, Ereignisse, Autostart, │ Datei, Dienstkonto und Abhängigkeiten prüfen │ └── Ja ↓ Reagiert der Prozess? ├── Nein │ ↓ │ Wait Chain, Threads, Dump und Abhängigkeiten prüfen │ └── Ja ↓ Sind Ressourcen auffällig? ├── Ja │ ↓ │ CPU, RAM, Handles, Threads und I/O untersuchen │ └── Nein ↓ Fehler bei Datei oder Registry? ├── Ja │ ↓ │ Process Monitor, Pfade und Berechtigungen prüfen │ └── Nein ↓ Netzwerk oder externer Dienst beteiligt? ├── Ja │ ↓ │ TCPView, Port, DNS und Zielsystem prüfen │ └── Nein ↓ Anwendungslog, Erweiterungen, DLLs und Dump untersuchen ``` --- **33. Typische Prüfungsfragen** **Warum ist ein Prozess mit hoher CPU-Auslastung nicht automatisch die Fehlerursache?**
Antwort anzeigen Die CPU-Auslastung kann für die ausgeführte Aufgabe normal sein oder als Folge eines anderen Problems entstehen. Zeitpunkt, Threadaktivität, Anwendungssymptom und weitere Abhängigkeiten müssen gemeinsam untersucht werden.
**Worin unterscheiden sich Task-Manager und Process Explorer?**
Antwort anzeigen Der Task-Manager bietet eine grundlegende Übersicht über Prozesse, Leistung, Benutzer und Autostarts. Process Explorer zeigt zusätzlich unter anderem Prozesshierarchie, Befehlszeilen, Signaturen, Handles, DLLs, Threads, Sicherheitsinformationen und detaillierte Prozesseigenschaften.
**Wofür wird Process Monitor verwendet?**
Antwort anzeigen Process Monitor zeichnet Datei-, Registry-, Prozess-, Thread- und DLL-Aktivitäten auf. Damit können beispielsweise fehlende Dateien, fehlerhafte Pfade und verweigerte Zugriffe untersucht werden.
**Warum ist `NAME NOT FOUND` in Process Monitor nicht automatisch ein Fehler?**
Antwort anzeigen Anwendungen prüfen häufig mehrere mögliche Namen oder Pfade. Wenn anschließend ein alternativer Zugriff erfolgreich ist, kann der fehlgeschlagene Versuch zum normalen Programmablauf gehören.
**Warum sollte ein blockierendes Handle nicht sofort geschlossen werden?**
Antwort anzeigen Das erzwungene Schließen kann Datenverlust, Programmabstürze oder inkonsistente Anwendungszustände verursachen. Zuerst muss die zugehörige Anwendung identifiziert und möglichst regulär beendet werden.
**Warum kann ein vollständiges Speicherabbild sicherheitsrelevant sein?**
Antwort anzeigen Der Prozessspeicher kann Kennwörter, Tokens, Schlüssel, personenbezogene Daten und vertrauliche Anwendungsinhalte enthalten. Dumps müssen daher wie sensible Daten behandelt werden.
**Warum darf ein Programm nicht dauerhaft nur als Administrator ausgeführt werden, um „Zugriff verweigert“ zu umgehen?**
Antwort anzeigen Dadurch erhält das Programm weitreichendere Rechte als erforderlich. Stattdessen muss die konkret fehlende Berechtigung identifiziert und nach dem Minimalprinzip vergeben werden.
**Wofür wird Autoruns eingesetzt?**
Antwort anzeigen Autoruns zeigt zahlreiche automatische Startpunkte von Windows, beispielsweise Anmeldeeinträge, Dienste, Treiber, geplante Aufgaben und Erweiterungen. Es hilft bei Problemen, die nach dem Start oder der Anmeldung auftreten.
**Was ist der Unterschied zwischen WPR und WPA?**
Antwort anzeigen Windows Performance Recorder zeichnet ETW-Ereignisse auf. Windows Performance Analyzer öffnet und analysiert die erzeugten ETL-Dateien mithilfe von Tabellen und Diagrammen.
**Warum sollte vor dem Neustart eines Prozesses ein Dump erstellt werden?**
Antwort anzeigen Der Neustart beseitigt den aktuellen Prozesszustand. Ein Dump kann Informationen über Threads, Aufrufstapel, Speicher und Sperren erhalten, die für die Ursachenanalyse benötigt werden.
--- **34. Prüfungsfallen** - hohe CPU-Auslastung sofort als Ursache bewerten. - Prozessname mit Dienstname gleichsetzen. - PID ohne Zeitpunkt dokumentieren. - gesamte CPU-Zeit mit momentaner CPU-Auslastung verwechseln. - nur den Task-Manager verwenden. - Prozesshierarchie nicht beachten. - unbekannten Prozess sofort als Schadsoftware einstufen. - nicht signierte Datei automatisch als schädlich bewerten. - digitale Signatur als vollständigen Sicherheitsnachweis ansehen. - Process Monitor ohne Filter lange laufen lassen. - jeden roten Process-Monitor-Eintrag als Fehler interpretieren. - `NAME NOT FOUND` automatisch als Ursache bewerten. - ein Handle ohne Risikoprüfung schließen. - einen Prozess ohne Dump oder Protokollsicherung beenden. - Dienstprozess direkt beenden, obwohl ein kontrollierter Dienstneustart möglich ist. - Anwendung dauerhaft als Administrator starten. - Autostarteintrag sofort löschen statt kontrolliert deaktivieren. - Dump-Dateien ungeschützt speichern. - unbekannte interne Dateien ungeprüft zu einem externen Dienst hochladen. - Port prüfen, aber zugehörige PID nicht ermitteln. - Listener mit tatsächlicher Anwendungsfunktion verwechseln. - Prozess untersuchen, aber externe Abhängigkeiten übersehen. - mehrere Änderungen gleichzeitig durchführen. - nach einer Maßnahme keine Vergleichsmessung durchführen. - temporäre Traces oder Debugfunktionen aktiv lassen. --- **35. Checkliste** - [ ] exakte Fehlermeldung wurde dokumentiert. - [ ] Fehlerzeitpunkt und Zeitzone wurden erfasst. - [ ] betroffene Anwendung wurde bestimmt. - [ ] Prozessname und PID wurden bestimmt. - [ ] Prozessstartzeit wurde berücksichtigt. - [ ] Eltern- und Kindprozesse wurden geprüft. - [ ] Benutzer- oder Dienstkonto wurde bestimmt. - [ ] Prozess- und Dienststatus wurden geprüft. - [ ] Dienstabhängigkeiten wurden geprüft. - [ ] CPU-Auslastung wurde geprüft. - [ ] einzelne Threads wurden berücksichtigt. - [ ] Arbeitsspeicher wurde geprüft. - [ ] Private Bytes und Working Set wurden unterschieden. - [ ] Handle-Anzahl wurde geprüft. - [ ] Thread-Anzahl wurde geprüft. - [ ] Datenträgeraktivität wurde geprüft. - [ ] Ereignisanzeige wurde zeitlich gefiltert. - [ ] Anwendungsprotokoll wurde geprüft. - [ ] Systemprotokoll wurde geprüft. - [ ] vollständiger Ereignistext wurde gelesen. - [ ] Prozesspfad wurde geprüft. - [ ] Befehlszeile wurde geprüft. - [ ] digitale Signatur wurde geprüft. - [ ] geladene DLLs wurden bei Bedarf geprüft. - [ ] offene Handles wurden bei Bedarf geprüft. - [ ] Process Monitor wurde gefiltert eingesetzt. - [ ] fehlgeschlagene Zugriffe wurden technisch bewertet. - [ ] Benutzer- und Dienstberechtigungen wurden geprüft. - [ ] Netzwerkverbindungen wurden der PID zugeordnet. - [ ] Listener und Portkonflikte wurden geprüft. - [ ] Autostarts wurden bei passendem Fehlerbild geprüft. - [ ] letzte Änderungen wurden berücksichtigt. - [ ] funktionierendes Vergleichssystem wurde genutzt. - [ ] vor einem Neustart wurden flüchtige Daten gesichert. - [ ] Dump-Erstellung wurde bei Absturz oder Hänger geprüft. - [ ] Schutzbedarf von Dump-, PML- und ETL-Dateien wurde beachtet. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] Benutzerfunktion wurde nach der Maßnahme getestet. - [ ] Prozesse, Dienste und Protokolle wurden erneut geprüft. - [ ] temporäre Diagnosefunktionen wurden beendet. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. - [ ] vorbeugende Maßnahme wurde festgelegt. --- **36. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Prozess verbraucht viel CPU | Process Explorer, Leistungsüberwachung | | nur ein Kern ausgelastet | Process Explorer → Threads | | Arbeitsspeicher wächst | PowerShell, Process Explorer, ProcDump | | Handles wachsen | Process Explorer, Handle | | Datei ist gesperrt | Process Explorer oder Handle | | DLL-Konflikt vermutet | Process Explorer oder ListDLLs | | Zugriff verweigert | Process Monitor, AccessChk | | Datei oder Pfad fehlt | Process Monitor | | Dienst startet nicht | Ereignisanzeige, `sc.exe`, PowerShell | | Dienst hängt beim Start | Ereignisanzeige, Wait Chain, ProcDump | | Prozess reagiert nicht | Ressourcenmonitor, Process Explorer, ProcDump | | Anwendung stürzt ab | Ereignisanzeige, WER, ProcDump | | unbekannte Netzwerkverbindung | TCPView | | erwarteter Port fehlt | `Get-NetTCPConnection`, TCPView | | Port ist bereits belegt | `Get-NetTCPConnection`, `netstat -ano` | | Fehler nach Anmeldung | Autoruns | | langsamer Systemstart | Autoruns, WPR und WPA | | unbekannte Datei | Sigcheck | | zeitweises Leistungsproblem | WPR und WPA | | Problem nur unter Dienstkonto | `whoami`, AccessChk, Process Monitor | | Anwendung funktioniert nur erhöht | Process Monitor und Berechtigungsprüfung | --- **Merksatz** > Windows-Prozesse und Dienste werden nicht allein anhand ihres Namens oder eines einzelnen Messwerts bewertet. Entscheidend sind Prozesshierarchie, Benutzerkonto, Threads, Speicher, Handles, Dateien, Registry-Zugriffe, Netzwerkverbindungen, Ereignisse und externe Abhängigkeiten. Vor dem Beenden oder Neustarten wird der flüchtige Zustand gesichert. Anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut geprüft. --- **Quellen und weiterführende Dokumentation** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – Sysinternals](https://learn.microsoft.com/en-us/sysinternals/) - [Microsoft Learn – Sysinternals Utilities](https://learn.microsoft.com/en-us/sysinternals/downloads/) - [Microsoft Learn – Sysinternals Suite](https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite) - [Microsoft Learn – Process Explorer](https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer) - [Microsoft Learn – Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) - [Microsoft Learn – Autoruns](https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns) - [Microsoft Learn – TCPView](https://learn.microsoft.com/en-us/sysinternals/downloads/tcpview) - [Microsoft Learn – Handle](https://learn.microsoft.com/en-us/sysinternals/downloads/handle) - [Microsoft Learn – ListDLLs](https://learn.microsoft.com/en-us/sysinternals/downloads/listdlls) - [Microsoft Learn – AccessChk](https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk) - [Microsoft Learn – Sigcheck](https://learn.microsoft.com/en-us/sysinternals/downloads/sigcheck) - [Microsoft Learn – ProcDump](https://learn.microsoft.com/en-us/sysinternals/downloads/procdump) - [Microsoft Learn – Get-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-process) - [Microsoft Learn – Get-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-service) - [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – Stop-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/stop-process) - [Microsoft Learn – Restart-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/restart-service) - [Microsoft Learn – Windows Performance Recorder](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-recorder) - [Microsoft Learn – Windows Performance Analyzer](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-analyzer) - [Microsoft Learn – Prozesse und Threads mit WPR und WPA untersuchen](https://learn.microsoft.com/en-us/troubleshoot/windows-server/support-tools/support-tools-xperf-wpa-wpr) # 8.2 Active Directory, Gruppenrichtlinien und Kerberos analysieren Active Directory Domain Services bilden in vielen Windows-Netzwerken die Grundlage für: - Benutzer- und Computeranmeldung, - zentrale Authentifizierung, - Gruppen und Berechtigungen, - Gruppenrichtlinien, - DNS-basierte Diensterkennung, - Kerberos-Tickets, - Vertrauensstellungen, - Zertifikatdienste, - Datei-, Druck- und Anwendungszugriffe. Eine scheinbar einfache Meldung wie „Anmeldung nicht möglich“, „Zugriff verweigert“ oder „Gruppenrichtlinie wird nicht angewendet“ kann deshalb unterschiedliche Ursachen haben: - falsche DNS-Konfiguration, - nicht erreichbarer Domänencontroller, - fehlerhafte Zeitsynchronisation, - gestörter Secure Channel, - Replikationsfehler, - falsche Gruppenmitgliedschaft, - fehlerhafte GPO-Verknüpfung, - Sicherheitsfilterung, - WMI-Filter, - Kerberos- oder SPN-Fehler, - nicht repliziertes Kennwort, - gesperrtes oder deaktiviertes Konto, - beschädigtes Computer- oder Benutzerprofil, - fehlende Netzwerkports, - fehlerhafte Vertrauensstellung. Die Komponenten müssen gemeinsam und in einer festen Reihenfolge untersucht werden. --- **1. Lernziele** Nach dieser Seite kannst du: - Active-Directory-Fehler systematisch eingrenzen, - Client-, Server- und Domänencontrollerprobleme unterscheiden, - den verwendeten Domänencontroller bestimmen, - DNS- und SRV-Einträge prüfen, - Zeitsynchronisation untersuchen, - den Secure Channel eines Clients bewerten, - AD-Replikationsfehler erkennen, - Gruppenrichtlinienergebnisse auswerten, - Kerberos-Tickets und SPNs prüfen, - typische Ereignisprotokolle zuordnen, - zwischen Symptom, Ursache und Nebenbefund unterscheiden, - Änderungen kontrolliert und mit Rückweg durchführen. --- **2. Vereinfachte Abhängigkeitskette** ```text Benutzer oder Computer ↓ IP-Konnektivität ↓ DNS-Auflösung und SRV-Einträge ↓ Erreichbarer Domänencontroller ↓ Zeitsynchronisation ↓ Secure Channel und Computerkonto ↓ Kerberos oder NTLM ↓ Active-Directory-Replikation ↓ Gruppenmitgliedschaften und Berechtigungen ↓ Gruppenrichtlinien und Anwendungszugriff ``` Ein Fehler weiter oben kann zahlreiche Folgefehler auslösen. Beispiele: - Falsches DNS kann verhindern, dass ein Domänencontroller gefunden wird. - Eine zu große Zeitabweichung kann Kerberos-Authentifizierung verhindern. - Eine fehlerhafte AD-Replikation kann dazu führen, dass ein neues Kennwort nur an einem Domänencontroller bekannt ist. - Eine fehlerhafte SYSVOL-Replikation kann dazu führen, dass eine GPO zwar im Verzeichnis vorhanden ist, ihre Dateien aber nicht überall verfügbar sind. - Ein doppelter SPN kann verhindern, dass für einen Dienst ein gültiges Kerberos-Ticket ausgestellt wird. --- **3. Sicherheits- und Betriebsregeln** Vor Änderungen müssen mindestens folgende Informationen gesichert werden: - genauer Fehlertext, - Fehlercode, - Zeitpunkt und Zeitzone, - betroffener Benutzer, - betroffener Computer, - verwendeter Domänencontroller, - betroffener Dienst oder Server, - letzte Änderungen, - aktuelle DNS-Konfiguration, - Zeitquelle und Zeitabweichung, - Gruppenrichtlinienergebnis, - Replikationsstatus, - relevante Ereignisse. Nicht als erste Maßnahme durchführen: - Computer aus der Domäne entfernen und wieder aufnehmen, - Computerkonto löschen, - Benutzerkonto neu erstellen, - GPO löschen oder vollständig deaktivieren, - AD-Replikation ungeprüft erzwingen, - Kerberos-Konfiguration in der Registry ändern, - Domänencontroller neu starten, - DNS-Einträge wahllos löschen, - SPNs ohne vorherige Prüfung verändern, - große Berechtigungsgruppen hinzufügen, - alle Gruppenrichtlinien gleichzeitig zurücksetzen. Solche Maßnahmen verändern oder vernichten den Zustand, der für die Ursachenanalyse benötigt wird. --- **4. Fehlerbild exakt erfassen** Wichtige Fragen: - Scheitert die lokale oder die Domänenanmeldung? - Ist nur ein Benutzer betroffen? - Ist nur ein Computer betroffen? - Sind mehrere Computer einer OU oder eines Standorts betroffen? - Funktioniert der Zugriff über IP-Adresse, aber nicht über Namen? - Funktioniert die Anmeldung mit zwischengespeicherten Anmeldedaten? - Tritt der Fehler nur bei einem bestimmten Domänencontroller auf? - Betrifft das Problem Benutzer- oder Computerrichtlinien? - Ist nur ein bestimmter Dienst betroffen? - Funktioniert NTLM, während Kerberos scheitert? - Trat der Fehler nach Kennwortänderung, Wiederherstellung, Snapshot, Migration oder GPO-Änderung auf? - Ist der Fehler dauerhaft oder nur zeitweise vorhanden? - Funktioniert ein vergleichbarer Benutzer oder Computer? Ein Client, ein Benutzer und eine konkrete Zielressource sollten als kontrollierter Testfall verwendet werden. --- **5. Grundinformationen auf dem Client erfassen** Identität: ```cmd whoami ``` Benutzer-Domäne: ```cmd echo %USERDOMAIN% ``` Anmeldeserver: ```cmd echo %LOGONSERVER% ``` Vollständige Benutzerinformationen: ```cmd whoami /all ``` Computername: ```cmd hostname ``` Domänenzugehörigkeit: ```powershell Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain, UserName ``` IP-Konfiguration: ```cmd ipconfig /all ``` Dabei sind besonders zu prüfen: - IPv4- und IPv6-Adresse, - Subnetzmaske beziehungsweise Präfix, - Standardgateway, - DNS-Server, - DNS-Suffix, - DHCP-Status, - Verbindungssuffix, - mehrere aktive Netzwerkadapter, - VPN-, virtuelle oder alte Adapter. Domänenmitglieder sollten grundsätzlich die für die AD-Domäne zuständigen internen DNS-Server verwenden. Ein öffentlicher DNS-Server kennt die internen AD-SRV-Einträge normalerweise nicht. --- **6. Verwendeten Domänencontroller bestimmen** Anmeldeserver: ```cmd echo %LOGONSERVER% ``` Domänencontroller für die Domäne suchen: ```cmd nltest /dsgetdc: ``` Beispiel: ```cmd nltest /dsgetdc:ad.example.local ``` Domänencontroller auflisten: ```cmd nltest /dclist: ``` Aktuellen DC über PowerShell bestimmen: ```powershell Get-ADDomainController -Discover ``` Alle bekannten Domänencontroller: ```powershell Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, IsGlobalCatalog, OperationMasterRoles ``` Die PowerShell-Befehle des Active-Directory-Moduls erfordern die entsprechenden RSAT-Komponenten oder die Ausführung auf einem geeigneten Verwaltungsserver. Zu dokumentieren sind: - Name des verwendeten Domänencontrollers, - Standort beziehungsweise AD-Site, - IP-Adresse, - Global-Catalog-Status, - Erreichbarkeit, - Zeitpunkt des Tests. --- **7. DNS als erste technische Abhängigkeit prüfen** Hostauflösung: ```cmd nslookup ``` Vollqualifizierten Namen prüfen: ```cmd nslookup . ``` Domänencontroller über LDAP-SRV-Einträge suchen: ```cmd nslookup -type=SRV _ldap._tcp.dc._msdcs. ``` Kerberos-Dienste suchen: ```cmd nslookup -type=SRV _kerberos._tcp. ``` Global Catalog suchen: ```cmd nslookup -type=SRV _gc._tcp. ``` Standortspezifische Domänencontroller: ```cmd nslookup -type=SRV _ldap._tcp.._sites.dc._msdcs. ``` PowerShell: ```powershell Resolve-DnsName -Type SRV ` _ldap._tcp.dc._msdcs. ``` Zu prüfen sind: - existieren die erwarteten SRV-Einträge, - zeigen die Einträge auf vorhandene Domänencontroller, - lassen sich deren Hostnamen auflösen, - stimmen die IP-Adressen, - antwortet der vorgesehene interne DNS-Server, - werden alte oder stillgelegte Domänencontroller zurückgegeben, - liefert ein anderer DNS-Server abweichende Ergebnisse, - ist das DNS-Suffix korrekt, - bestehen doppelte A- oder AAAA-Einträge. Ein erfolgreicher Ping auf eine IP-Adresse beweist keine funktionierende AD-DNS-Struktur. --- **8. Erreichbarkeit benötigter Dienste prüfen** Grundlegende Verbindung: ```powershell Test-NetConnection ``` DNS: ```powershell Test-NetConnection -Port 53 ``` Kerberos: ```powershell Test-NetConnection -Port 88 ``` LDAP: ```powershell Test-NetConnection -Port 389 ``` SMB für SYSVOL und NETLOGON: ```powershell Test-NetConnection -Port 445 ``` RPC Endpoint Mapper: ```powershell Test-NetConnection -Port 135 ``` Global Catalog: ```powershell Test-NetConnection -Port 3268 ``` LDAPS, sofern verwendet: ```powershell Test-NetConnection -Port 636 ``` Global Catalog über TLS, sofern verwendet: ```powershell Test-NetConnection -Port 3269 ``` Wichtige Dienste und Ports können unter anderem sein: | Funktion | Typischer Port | |---|---:| | DNS | TCP/UDP 53 | | Kerberos | TCP/UDP 88 | | RPC Endpoint Mapper | TCP 135 | | LDAP | TCP/UDP 389 | | SMB | TCP 445 | | Kerberos-Kennwortänderung | TCP/UDP 464 | | LDAPS | TCP 636 | | Global Catalog | TCP 3268 | | Global Catalog über TLS | TCP 3269 | | dynamisches RPC | konfigurationsabhängiger TCP-Portbereich | Ein erfolgreich getesteter TCP-Port beweist nur, dass eine Verbindung zu diesem Port hergestellt werden konnte. Er beweist nicht, dass Authentifizierung, LDAP-Abfrage, Replikation oder Gruppenrichtlinienverarbeitung funktionieren. --- **9. SYSVOL und NETLOGON prüfen** Freigaben des Domänencontrollers: ```cmd net view \\ ``` SYSVOL öffnen: ```cmd dir \\\SYSVOL ``` NETLOGON öffnen: ```cmd dir \\\NETLOGON ``` Direkter Domänenpfad: ```cmd dir \\\SYSVOL ``` Zu prüfen sind: - Freigaben vorhanden, - Namensauflösung funktioniert, - Zugriff unter dem vorgesehenen Benutzer möglich, - benötigte GPO-Verzeichnisse vorhanden, - Skripte und Vorlagen erreichbar, - unterschiedliche Domänencontroller liefern denselben erwarteten Inhalt. Eine GPO besteht aus zwei zusammengehörigen Teilen: | Bestandteil | Speicherort | |---|---| | Group Policy Container | Active Directory | | Group Policy Template | SYSVOL | Sind die beiden Teile oder ihre Versionsstände nicht konsistent, kann die Gruppenrichtlinienverarbeitung fehlschlagen. --- **10. Zeitsynchronisation prüfen** Aktueller Status: ```cmd w32tm /query /status ``` Zeitquelle: ```cmd w32tm /query /source ``` Konfiguration: ```cmd w32tm /query /configuration ``` Domänenhierarchie überwachen: ```cmd w32tm /monitor ``` Vergleich mit einem bestimmten Domänencontroller: ```cmd w32tm /stripchart /computer: /samples:10 /dataonly ``` Windows-Zeitdienst: ```powershell Get-Service W32Time ``` Zu prüfen sind: - aktuelle Zeit, - Zeitzone, - Zeitquelle, - Zeitabweichung, - Dienststatus, - Domänenhierarchie, - Erreichbarkeit der Zeitquelle, - Virtualisierung und Host-Zeitsynchronisation, - PDC-Emulator als maßgebliche Domänenzeitquelle. Kerberos reagiert empfindlich auf Zeitabweichungen. Der konkrete Fehler muss jedoch anhand von Ereignissen, Ticketstatus und Zeitmessung nachgewiesen werden. Eine manuelle Änderung der Uhrzeit beseitigt nicht automatisch die Ursache einer falschen Zeitquelle. --- **11. Secure Channel des Computers prüfen** Der Secure Channel ist die geschützte Beziehung zwischen einem Domänenmitglied und der Domäne. Prüfung mit PowerShell: ```powershell Test-ComputerSecureChannel -Verbose ``` Prüfung mit NLTEST: ```cmd nltest /sc_verify: ``` Verwendeten sicheren Kanal anzeigen: ```cmd nltest /sc_query: ``` Mögliche Symptome eines gestörten Secure Channels: - „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne ist fehlgeschlagen“, - Anmeldung funktioniert nur mit zwischengespeicherten Daten, - Gruppenrichtlinien schlagen fehl, - Zugriff auf Domänenressourcen scheitert, - Computerkonto-Kennwort stimmt zwischen Client und AD nicht überein. Mögliche Ursachen: - Rücksetzen auf einen alten VM-Snapshot, - geklontes System mit fehlerhafter Identität, - wiederhergestelltes Computerkonto, - Replikationsfehler, - doppelt verwendeter Computername, - beschädigtes Computerkonto, - lange getrenntes oder falsch wiederhergestelltes System. Eine Reparatur des Secure Channels ist eine Änderung und darf erst nach Sicherung der Diagnoseergebnisse erfolgen. Mögliche kontrollierte Reparatur auf einem Domänenmitglied: ```powershell Test-ComputerSecureChannel -Repair ` -Credential \ ``` Vorher müssen geprüft werden: - DNS funktioniert, - Domänencontroller ist erreichbar, - Zeit stimmt, - Computerkonto ist vorhanden und eindeutig, - keine Replikationsstörung liegt vor, - Berechtigung zur Reparatur ist vorhanden, - Rückweg und Wartungsfenster sind festgelegt. `Test-ComputerSecureChannel` ist vor allem für Domänenmitglieder vorgesehen. Bei Domänencontrollern müssen DC-spezifische Diagnose- und Reparaturverfahren verwendet werden. --- **12. Benutzer- und Computerkonto prüfen** Benutzerkonto: ```powershell Get-ADUser -Identity -Properties * | Select-Object SamAccountName, UserPrincipalName, Enabled, LockedOut, PasswordExpired, PasswordLastSet, LastBadPasswordAttempt, BadLogonCount, AccountExpirationDate ``` Computerkonto: ```powershell Get-ADComputer -Identity -Properties * | Select-Object Name, Enabled, DNSHostName, PasswordLastSet, LastLogonDate, DistinguishedName ``` Gruppenmitgliedschaften: ```powershell Get-ADPrincipalGroupMembership | Select-Object Name, GroupScope, GroupCategory ``` Aktuelles Benutzer-Token: ```cmd whoami /groups ``` Zu unterscheiden sind: - im Active Directory gespeicherte Gruppenmitgliedschaften, - Gruppen im aktuellen Anmeldetoken, - verschachtelte Gruppen, - lokale Gruppen, - universelle, globale und domänenlokale Gruppen, - Änderungen nach der letzten Anmeldung. Eine neu hinzugefügte Gruppenmitgliedschaft ist nicht automatisch im bereits bestehenden Benutzer-Token enthalten. Ab- und erneute Anmeldung kann erforderlich sein. Bei bestimmten Dienstkonten kann ein Dienstneustart notwendig sein. --- **13. Kontosperrung untersuchen** Zu prüfen sind: - ist das Konto tatsächlich gesperrt, - auf welchem Domänencontroller wurde die Sperrung registriert, - welcher Client oder Dienst sendet falsche Anmeldedaten, - existieren gespeicherte Anmeldedaten, - läuft ein Dienst oder eine geplante Aufgabe mit altem Kennwort, - verwendet ein Smartphone, VPN oder Netzlaufwerk alte Zugangsdaten, - tritt die Sperrung unmittelbar nach dem Entsperren erneut auf. Benutzerstatus: ```powershell Get-ADUser ` -Properties LockedOut, LastBadPasswordAttempt, BadLogonCount, PasswordLastSet ``` Gesperrte Konten suchen: ```powershell Search-ADAccount -LockedOut -UsersOnly ``` Relevante Sicherheitsereignisse können unter anderem betreffen: - fehlgeschlagene Anmeldung, - Kontosperrung, - Kerberos-Vorauthentifizierungsfehler, - Ticketanforderungen, - Anmeldungen mit expliziten Anmeldedaten. Ein Konto lediglich wiederholt zu entsperren beseitigt die Quelle der falschen Anmeldedaten nicht. --- **14. Domänencontroller grundsätzlich prüfen** Ausführliche Diagnose: ```cmd dcdiag /v ``` Ausgabe in Datei: ```cmd dcdiag /v /c /d /e > C:\Temp\dcdiag.txt ``` DNS-Test: ```cmd dcdiag /test:dns /v ``` Replikationstest: ```cmd dcdiag /test:replications /v ``` SYSVOL-Test: ```cmd dcdiag /test:sysvolcheck /v ``` Werbungsstatus des Domänencontrollers: ```cmd dcdiag /test:advertising /v ``` NETLOGON-Freigabe: ```cmd dcdiag /test:netlogons /v ``` Zu prüfen sind: - welcher Test fehlschlägt, - welcher Domänencontroller betroffen ist, - genauer Fehlercode, - Zeitpunkt, - DNS-Abhängigkeit, - Replikationspartner, - Verzeichnispartition, - Warnung oder tatsächlicher Fehler. Nicht jede Warnung in einer umfangreichen `dcdiag`-Ausgabe erklärt das untersuchte Symptom. Der Befund muss zeitlich und technisch zum Fehler passen. --- **15. AD-Replikation prüfen** Gesamtübersicht: ```cmd repadmin /replsummary ``` Eingehende Replikation eines DCs: ```cmd repadmin /showrepl ``` Gesamtstrukturweite Anzeige: ```cmd repadmin /showrepl * /csv ``` PowerShell-Auswertung: ```powershell repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView ``` Replikationsfehler über PowerShell: ```powershell Get-ADReplicationFailure ` -Target * ` -Scope Forest ``` Status der Replikationspartner: ```powershell Get-ADReplicationPartnerMetadata ` -Target * ` -Scope Forest | Select-Object Server, Partner, Partition, LastReplicationAttempt, LastReplicationSuccess, LastReplicationResult ``` Replikationswarteschlange: ```cmd repadmin /queue ``` Zu dokumentieren sind: - Quell- und Ziel-DC, - Verzeichnispartition, - letzte erfolgreiche Replikation, - letzter Replikationsversuch, - Anzahl aufeinanderfolgender Fehler, - Fehlercode, - Fehlertext, - betroffene Standorte, - Richtung des Fehlers. --- **16. Replikationsfehler richtig bewerten** AD-Replikation hängt unter anderem ab von: - DNS, - Netzwerkverbindungen, - RPC, - Authentifizierung, - Autorisierung, - Zeit, - Replikationstopologie, - Verzeichnisdatenbank, - Zustand der Domänencontroller. | Befund | Mögliche Ursache | |---|---| | Fehler 1722 | RPC-Server nicht verfügbar, DNS, Firewall oder Dienstproblem | | Fehler 5 | Zugriff verweigert, Authentifizierung oder Berechtigung | | Zielprinzipalname ist falsch | Kerberos-, SPN- oder Computerkonto-Problem | | letzter Erfolg lange her | dauerhafte oder standortbezogene Störung | | nur eine Partition betroffen | partitions- oder DNS-bezogenes Problem | | nur ein Partner betroffen | Verbindung, DNS oder Zustand dieses Partners | | Änderungen fehlen nur auf einem DC | eingehende Replikation dieses DCs prüfen | | verschiedene Kennwörter funktionieren je nach DC | Kennwortreplikation oder allgemeine Replikation prüfen | | GPO fehlt nur auf einem DC | AD- und SYSVOL-Replikation gemeinsam prüfen | Eine erzwungene Synchronisation ist keine erste Diagnosemaßnahme. Sie kann zusätzliche Last erzeugen und verdeckt möglicherweise die Richtung oder den ursprünglichen Zustand des Fehlers. --- **17. FSMO-Rollen prüfen** ```cmd netdom query fsmo ``` PowerShell: ```powershell Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster ``` Die Rollen sind: | Rolle | Ebene | Wichtige Funktion | |---|---|---| | Schema-Master | Gesamtstruktur | Schemaänderungen | | Domänennamen-Master | Gesamtstruktur | Domänen und Partitionen | | RID-Master | Domäne | RID-Pools für Sicherheitskennungen | | PDC-Emulator | Domäne | Zeit, Kennwortpriorität und weitere Funktionen | | Infrastruktur-Master | Domäne | domänenübergreifende Objektbezüge | Der Ausfall eines FSMO-Rolleninhabers erklärt nicht automatisch jede Anmeldestörung. Die betroffene Funktion und die Ausfalldauer müssen berücksichtigt werden. --- **18. Gruppenrichtlinien-Grundlagen** Die normale Verarbeitungsreihenfolge lautet: ```text Lokal → Site → Domäne → OU → untergeordnete OU ``` Diese Reihenfolge wird häufig mit `LSDOU` bezeichnet. Grundsätzlich gilt: - Gruppenrichtlinien werden kumulativ verarbeitet. - Näher am Benutzer- oder Computerobjekt verknüpfte Einstellungen können frühere Einstellungen überschreiben. - Die genaue Wirkung hängt von Verknüpfungsreihenfolge, Vererbung, Erzwingen, Sicherheitsfilterung und Richtlinientyp ab. - Computer- und Benutzerkonfiguration werden getrennt verarbeitet. - Nicht jede Erweiterung wird bei jeder Hintergrundaktualisierung vollständig verarbeitet. - Loopbackverarbeitung kann die Benutzerkonfiguration abhängig vom Computerstandort verändern. Mögliche Ursachen für eine nicht angewendete GPO: - GPO nicht an der richtigen Site, Domäne oder OU verknüpft, - Link deaktiviert, - GPO vollständig oder teilweise deaktiviert, - Objekt befindet sich in der falschen OU, - Sicherheitsfilterung schließt Benutzer oder Computer aus, - fehlende Leseberechtigung, - WMI-Filter liefert `False`, - Vererbung blockiert, - andere GPO besitzt höhere Priorität, - Einstellung gilt nur für Benutzer oder nur für Computer, - langsame Netzwerkverbindung, - erforderliche synchrone Verarbeitung noch nicht erfolgt, - Neustart oder erneute Anmeldung fehlt, - SYSVOL nicht erreichbar, - AD- oder SYSVOL-Replikation gestört, - Client Side Extension schlägt fehl. --- **19. Gruppenrichtlinienergebnis erfassen** Kurzübersicht: ```cmd gpresult /r ``` Computerrichtlinien mit erhöhten Rechten: ```cmd gpresult /scope computer /r ``` Benutzerrichtlinien: ```cmd gpresult /scope user /r ``` Ausführlicher HTML-Bericht: ```cmd gpresult /h C:\Temp\gpresult.html ``` Bericht für einen bestimmten Benutzer: ```cmd gpresult /user \ /h C:\Temp\gpresult-benutzer.html ``` Ausführliche Textausgabe: ```cmd gpresult /z ``` Resultant Set of Policy: ```cmd rsop.msc ``` Im Bericht sind besonders zu prüfen: - angewendete GPOs, - abgelehnte GPOs, - Ablehnungsgrund, - Sicherheitsgruppen, - verwendeter Domänencontroller, - WMI-Filter, - Benutzer- und Computerbereich, - Loopbackmodus, - langsame Verbindung, - Verarbeitungszeit, - Fehler einzelner Erweiterungen. `gpresult` muss im passenden Benutzer- und Berechtigungskontext ausgeführt werden. Ein Bericht aus einem anderen Konto kann ein anderes Ergebnis zeigen. --- **20. Gruppenrichtlinien kontrolliert aktualisieren** Standardaktualisierung: ```cmd gpupdate ``` Erneute Verarbeitung aller Einstellungen: ```cmd gpupdate /force ``` Nur Computerrichtlinien: ```cmd gpupdate /target:computer /force ``` Nur Benutzerrichtlinien: ```cmd gpupdate /target:user /force ``` Eine erzwungene Aktualisierung kann: - zusätzliche Netz- und Serverlast verursachen, - erneut alle Richtlinienerweiterungen anstoßen, - Ab- oder Anmeldung verlangen, - einen Neustart verlangen, - laufende Benutzersitzungen beeinflussen. `gpupdate /force` ist ein Test beziehungsweise Auslöser, aber noch keine Ursachenanalyse. Danach müssen Ergebnisbericht und Ereignisprotokolle geprüft werden. --- **21. Gruppenrichtlinien-Ereignisse prüfen** Wichtiger Protokollpfad: ```text Ereignisanzeige → Anwendungs- und Dienstprotokolle → Microsoft → Windows → GroupPolicy → Operational ``` PowerShell: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-GroupPolicy/Operational' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Zusätzlich prüfen: - Systemprotokoll, - Anwendungsprotokoll, - DNS Client Events, - NETLOGON, - Kerberos, - Benutzerprofildienst, - einzelne Client Side Extensions. Nicht nur die Event-ID verwenden. Provider, vollständiger Text, Zeitpunkt, Benutzer, Computer und Verarbeitungsschritt müssen gemeinsam bewertet werden. --- **22. GPO-Verknüpfung und Filterung prüfen** In der Gruppenrichtlinienverwaltung sind zu kontrollieren: - richtige GPO, - richtige Verknüpfung, - richtige OU, - Link aktiviert, - GPO-Status, - Verknüpfungsreihenfolge, - Vererbung, - erzwungene Links, - Sicherheitsfilterung, - Delegierung, - WMI-Filter, - Benutzer- oder Computerteil, - GPO-Version, - Replikationsstatus. Sicherheitsfilterung benötigt grundsätzlich die passenden Berechtigungen zum Lesen und Anwenden der Gruppenrichtlinie. Typische Fehlinterpretation: > Ein Benutzer ist Mitglied einer Gruppe, die „Gruppenrichtlinie übernehmen“ besitzt. Im aktuellen Anmeldetoken fehlt diese neue Gruppenmitgliedschaft jedoch noch. Deshalb müssen AD-Mitgliedschaft und aktuelles Token getrennt geprüft werden. --- **23. Loopbackverarbeitung verstehen** Loopbackverarbeitung wird für Computer verwendet, bei denen die Benutzerumgebung vom verwendeten Computer abhängen soll, beispielsweise: - Schulungsräume, - Kiosksysteme, - Terminalserver, - gemeinsam verwendete Arbeitsplätze. Modi: | Modus | Wirkung | |---|---| | Zusammenführen | Benutzerrichtlinien des Benutzerobjekts werden verarbeitet, danach kommen die für den Computer ermittelten Benutzerrichtlinien hinzu | | Ersetzen | Benutzerrichtlinien des Benutzerobjekts werden durch die für den Computer ermittelten Benutzerrichtlinien ersetzt | Wenn Benutzereinstellungen nur auf bestimmten Computern unerwartet sind, muss Loopback geprüft werden. --- **24. Kerberos-Grundprinzip** Vereinfacht: ```text Benutzeranmeldung ↓ Authentication Service Request ↓ Ticket Granting Ticket ↓ Ticket Granting Service Request ↓ Dienstticket für einen SPN ↓ Zugriff auf den Zieldienst ``` Wichtige Begriffe: | Begriff | Bedeutung | |---|---| | KDC | Key Distribution Center auf einem Domänencontroller | | TGT | Ticket Granting Ticket | | Dienstticket | Ticket für einen konkreten Dienst | | SPN | eindeutiger Dienstbezeichner eines Kontos | | Realm | Kerberos-Sicherheitsbereich, in AD meist zur Domäne zugeordnet | | PAC | enthält unter anderem Autorisierungsinformationen | | Delegierung | Weitergabe von Anmeldeinformationen unter definierten Bedingungen | Kerberos benötigt insbesondere: - funktionierende DNS-Auflösung, - erreichbaren KDC, - korrekte Zeit, - gültige Konten, - korrekte Kennwörter, - eindeutige SPNs, - einen zum Zielnamen passenden Dienstprinzipal. --- **25. Kerberos-Tickets prüfen** Tickets des aktuellen Anmeldekontexts: ```cmd klist ``` TGT anzeigen: ```cmd klist tgt ``` Zwischengespeicherte Tickets auflisten: ```cmd klist tickets ``` KDCs anzeigen: ```cmd klist query_bind ``` Zu prüfen sind: - Clientname, - Servername beziehungsweise SPN, - Kerberos-Realm, - Tickettyp, - Start- und Ablaufzeit, - Erneuerungszeit, - Verschlüsselungstyp, - Flags, - verwendeter KDC. Das Löschen des Ticketcaches verändert den Diagnosezustand: ```cmd klist purge ``` `klist purge` sollte erst eingesetzt werden, wenn: - vorhandene Tickets dokumentiert wurden, - klar ist, welcher Sicherheitskontext betroffen ist, - erneute Authentifizierung möglich ist, - keine kritische Sitzung unterbrochen wird, - der Test gezielt ein neues Ticket anfordern soll. Nach dem Löschen kann ein erneuter Zugriff auf die Zielressource ein neues Ticket auslösen. --- **26. Service Principal Names prüfen** SPNs eines Kontos anzeigen: ```cmd setspn -L ``` Bestimmten SPN suchen: ```cmd setspn -Q / ``` Beispiel: ```cmd setspn -Q HTTP\webserver.ad.example.local ``` Doppelte SPNs domänen- beziehungsweise gesamtstrukturweit suchen: ```cmd setspn -X ``` Mögliche SPN-Probleme: - SPN fehlt, - SPN ist dem falschen Konto zugeordnet, - SPN ist doppelt vorhanden, - Client verwendet Alias statt registriertem Hostnamen, - Dienstkonto wurde geändert, - Server wurde umbenannt, - Dienst läuft unter anderem Konto als erwartet, - alter SPN blieb nach Migration erhalten. SPNs dürfen nicht ohne vorherige Suche, Dokumentation und Prüfung verändert werden. Ein falsches Entfernen kann andere Dienste oder Benutzer beeinträchtigen. --- **27. Kerberos und NTLM unterscheiden** Anmeldesitzungen: ```cmd klist sessions ``` Tickets: ```cmd klist ``` Für bestimmte Verbindungen können zusätzlich Ereignisprotokolle, Dienstprotokolle oder geeignete Netzwerkaufzeichnungen erforderlich sein. Mögliche Hinweise auf NTLM statt Kerberos: - kein passendes Dienstticket vorhanden, - Zugriff erfolgt über IP-Adresse, - SPN für den verwendeten Namen fehlt, - Ziel befindet sich außerhalb der Kerberos-Vertrauensbeziehung, - Anwendung fordert ausdrücklich NTLM, - DNS- oder Namensproblem, - Kerberos-Anforderung schlägt fehl und ein Fallback ist möglich. Ein funktionierender Zugriff beweist deshalb nicht automatisch, dass Kerberos verwendet wurde. --- **28. Zugriff über IP-Adresse und Hostname vergleichen** Beispiel: ```text \\192.0.2.10\Freigabe \\server01\Freigabe \\server01.ad.example.local\Freigabe ``` Unterschiedliche Ergebnisse können auf Folgendes hinweisen: - DNS-Problem, - Alias-Problem, - SPN-Problem, - Kerberos funktioniert nur für einen bestimmten Namen, - Zertifikat passt nicht zum verwendeten Namen, - Anwendung verwendet unterschiedliche Sicherheitszonen, - IPv4 und IPv6 führen zu unterschiedlichen Zielen. Der Zugriff per IP-Adresse ist kein allgemeiner Ersatz für korrekte Namensauflösung. Bei Kerberos ist der verwendete Zielname für die SPN-Zuordnung entscheidend. --- **29. Kerberos-Ereignisse untersuchen** Relevante Protokolle können sein: - Sicherheitsprotokoll auf Client, Server und DC, - Systemprotokoll, - Kerberos-Key-Distribution-Center-Protokoll, - NETLOGON-Protokoll, - dienstspezifische Protokolle. PowerShell-Beispiel für aktuelle Sicherheitsereignisse: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Security' StartTime = (Get-Date).AddHours(-2) } | Where-Object { $_.Id -in 4768, 4769, 4771, 4776 } | Select-Object TimeCreated, Id, Message ``` Typische Ereigniskategorien: | Kategorie | Mögliche Bedeutung | |---|---| | TGT wurde angefordert | Benutzer- oder Computerauthentifizierung | | Dienstticket wurde angefordert | Zugriff auf einen bestimmten SPN | | Kerberos-Vorauthentifizierung fehlgeschlagen | Kennwort, Zeit, Kontostatus oder anderer Authentifizierungsfehler | | Anmeldeinformationen wurden validiert | häufig NTLM-bezogene Prüfung | | Kontosperrung | wiederholte fehlerhafte Authentifizierung | Event-IDs müssen mit dem vollständigen Ereignistext und dem jeweiligen System ausgewertet werden. --- **30. Typische Fehlerbilder** | Symptom | Mögliche Ursache | Nächster Test | |---|---|---| | Domäne kann nicht gefunden werden | DNS oder DC-Erreichbarkeit | `ipconfig /all`, SRV-Abfrage, `nltest /dsgetdc` | | Anmeldung funktioniert offline, aber nicht im Firmennetz | DC-, DNS-, Zeit- oder Secure-Channel-Problem | DC-Suche, Zeit und Secure Channel | | Vertrauensstellung fehlgeschlagen | Computerkennwort oder Computerkonto inkonsistent | `Test-ComputerSecureChannel`, Replikation | | neues Kennwort funktioniert nur manchmal | unterschiedliche DC-Daten | verwendeten DC und Replikation prüfen | | Benutzer bleibt trotz Entsperrung gesperrt | gespeicherte alte Anmeldedaten | Sperrquelle und Sicherheitsereignisse | | GPO wird nicht angezeigt | falsche OU, Filterung oder Link | `gpresult`, GPMC | | GPO wird angezeigt, Einstellung fehlt | Überschreibung oder Erweiterungsfehler | Detailbericht und GroupPolicy-Protokoll | | Computerrichtlinie fehlt | Computerobjekt, Neustart oder Computerbereich | `gpresult /scope computer` | | Benutzerrichtlinie fehlt | Benutzerobjekt, Token oder Benutzerbereich | `gpresult /scope user` | | GPO funktioniert nur an einem Standort nicht | Site, DC, Replikation oder Netzwerk | DC-Zuordnung und Replikation | | SYSVOL nicht erreichbar | DNS, SMB, DC oder DFSR | Port 445, Freigabe und DC-Protokolle | | Kerberos-Ticket fehlt | SPN, DNS, KDC oder Anwendung | `klist`, `setspn -Q` | | Kerberos scheitert nur über Alias | fehlender SPN für Alias | verwendeten Namen und SPN prüfen | | Zugriff funktioniert per IP, nicht per Name | DNS, SPN oder Zertifikat | Namen einzeln prüfen | | Zugriff funktioniert per Name, nicht per IP | Kerberos- oder Anwendungsanforderung | Ticket und Zielkonfiguration | | Dienst funktioniert nur mit NTLM | SPN oder Delegierung | Dienstkonto und SPNs | | Replikation meldet RPC-Fehler | DNS, Firewall, RPC oder Partner offline | Namensauflösung und Ports | | Benutzer hat neue Gruppe, aber keinen Zugriff | altes Anmeldetoken | `whoami /groups`, erneute Anmeldung | | Fehler nur auf einem Client | lokaler DNS-, Cache-, Konto- oder Profilfehler | Vergleichsclient und lokale Konfiguration | | Fehler auf vielen Clients | zentrale AD-, DNS-, GPO- oder Netzwerkstörung | DCs, Replikation und Änderungen | | Fehler nach VM-Snapshot | Secure Channel oder Zeit zurückgesetzt | Zeit, Computerkonto und Secure Channel | --- **31. Vorgehensweise bei einer nicht angewendeten GPO** 1. Betroffenen Benutzer und Computer bestimmen. 2. Prüfen, ob Benutzer- und Computerobjekt in den erwarteten OUs liegen. 3. Verwendeten Domänencontroller dokumentieren. 4. DNS- und DC-Erreichbarkeit prüfen. 5. SYSVOL-Zugriff prüfen. 6. `gpresult` als HTML-Bericht erstellen. 7. angewendete und abgelehnte GPOs prüfen. 8. Sicherheitsfilterung und WMI-Filter prüfen. 9. Verknüpfung, Reihenfolge und Vererbung prüfen. 10. Loopbackverarbeitung berücksichtigen. 11. GroupPolicy-Operational-Protokoll auswerten. 12. AD- und SYSVOL-Replikation prüfen. 13. genau eine kontrollierte Korrektur durchführen. 14. Richtlinien erneut verarbeiten. 15. Ergebnisbericht und Benutzerfunktion erneut prüfen. --- **32. Vorgehensweise bei einer fehlgeschlagenen Anmeldung** 1. Exakte Meldung und Zeitpunkt erfassen. 2. Lokale und Domänenanmeldung unterscheiden. 3. Netzwerkverbindung prüfen. 4. DNS-Server und DNS-Suffix prüfen. 5. Domänencontroller über SRV-Einträge suchen. 6. verwendeten DC bestimmen. 7. Zeit und Zeitquelle prüfen. 8. Benutzerkonto auf Sperre, Ablauf und Deaktivierung prüfen. 9. Secure Channel des Clients prüfen. 10. Replikationsstatus der DCs prüfen. 11. Sicherheits- und Kerberos-Ereignisse auswerten. 12. gespeicherte Anmeldedaten, Dienste und Aufgaben berücksichtigen. 13. genau eine Maßnahme durchführen. 14. Anmeldung und Ressourcenabruf erneut testen. --- **33. Vorgehensweise bei Kerberos-Problemen** 1. verwendeten Zielnamen dokumentieren. 2. DNS-Auflösung dieses Namens prüfen. 3. Zeit von Client, Server und DC vergleichen. 4. KDC beziehungsweise DC-Erreichbarkeit prüfen. 5. vorhandene Tickets mit `klist` dokumentieren. 6. nach passendem Dienstticket suchen. 7. erwarteten SPN bestimmen. 8. SPN mit `setspn -Q` suchen. 9. Dienstkonto und tatsächlichen Dienstprozess vergleichen. 10. doppelte SPNs prüfen. 11. Sicherheits- und Kerberos-Ereignisse korrelieren. 12. Vertrauensstellung und Delegierung berücksichtigen. 13. Ticketcache nur kontrolliert leeren. 14. Zugriff erneut auslösen. 15. neues Ticket und Funktion prüfen. --- **34. Maßnahmen und Rückwege** **Ursache: falscher DNS-Server am Client** Nachweis: - Client verwendet einen nicht zuständigen DNS-Server, - AD-SRV-Einträge werden nicht korrekt aufgelöst, - interner DNS-Server liefert die erwarteten Einträge. Maßnahme: - DNS-Konfiguration kontrolliert auf die vorgesehenen internen DNS-Server korrigieren. Rollback: - ursprüngliche Adapter- oder DHCP-Konfiguration dokumentiert wiederherstellen. Verifikation: - SRV-Abfrage, - DC-Suche, - Anmeldung, - GPO-Verarbeitung, - Anwendungszugriff. --- **Ursache: fehlerhafter Secure Channel** Nachweis: - Secure-Channel-Prüfung schlägt fehl, - Computerkonto ist vorhanden, - DNS, Zeit und DC-Erreichbarkeit funktionieren, - Replikation ist ausreichend gesund. Maßnahme: - Secure Channel mit berechtigtem Konto kontrolliert reparieren. Rollback: - vorab dokumentierte Computer- und Domänenkonfiguration verwenden; - bei Fehlschlag nach freigegebenem Wiederherstellungsverfahren vorgehen. Verifikation: - Secure Channel erneut prüfen, - Neustart oder Anmeldung testen, - Gruppenrichtlinien und Ressourcen testen. --- **Ursache: GPO durch Sicherheitsfilterung ausgeschlossen** Nachweis: - `gpresult` nennt die GPO als abgelehnt, - Benutzer oder Computer besitzt nicht die erforderlichen Berechtigungen. Maßnahme: - Sicherheitsfilterung nach dem Minimalprinzip korrigieren. Rollback: - ursprüngliche ACL beziehungsweise Gruppenmitgliedschaft wiederherstellen. Verifikation: - neues Token berücksichtigen, - GPO aktualisieren, - `gpresult` erneut erzeugen, - konkrete Einstellung prüfen. --- **Ursache: doppelter SPN** Nachweis: - `setspn -Q` oder `setspn -X` zeigt den SPN mehrfach, - Kerberos-Ereignisse passen zum Fehler, - Dienstkonto und Zielname wurden bestätigt. Maßnahme: - falsche SPN-Zuordnung nach Freigabe entfernen und korrekte eindeutige Zuordnung sicherstellen. Rollback: - vorherige SPN-Zuordnungen vollständig dokumentieren. Verifikation: - neue Tickets anfordern, - Dienstticket prüfen, - Zugriff mit vorgesehenem Namen testen. --- **Ursache: AD-Replikationsfehler** Nachweis: - `repadmin` oder PowerShell zeigt konkrete Fehler, - betroffene Objekte oder Kennwörter unterscheiden sich zwischen DCs, - Fehlercode und Abhängigkeit wurden bestimmt. Maßnahme: - zugrunde liegendes DNS-, Netzwerk-, RPC-, Zeit-, Authentifizierungs- oder DC-Problem beheben. Rollback: - abhängig von der konkreten Änderung; - keine erzwungene Replikations- oder Metadatenbereinigung ohne Wiederherstellungsplan. Verifikation: - `repadmin /replsummary`, - `repadmin /showrepl`, - Objektvergleich, - Anmeldung und GPO-Verarbeitung. --- **35. Nachkontrolle** Nach jeder Maßnahme sind mindestens folgende Punkte erneut zu prüfen: - Client verwendet die vorgesehenen DNS-Server. - AD-SRV-Einträge werden korrekt aufgelöst. - vorgesehene Domänencontroller sind erreichbar. - Zeit und Zeitquelle sind plausibel. - Secure Channel funktioniert. - Benutzer- und Computerkonto sind aktiv. - Replikation zeigt keine zum Fehler gehörenden Störungen. - SYSVOL und NETLOGON sind erreichbar. - benötigte Gruppenmitgliedschaften sind im aktuellen Token enthalten. - erwartete GPOs werden angewendet. - abgelehnte GPOs sind fachlich erklärbar. - Gruppenrichtlinienprotokoll zeigt keine neuen relevanten Fehler. - erforderliches Kerberos-Ticket wird ausgestellt. - SPN ist eindeutig und dem richtigen Konto zugeordnet. - Benutzerfunktion wurde praktisch getestet. - keine unnötigen Berechtigungen wurden vergeben. - temporäre Diagnose- oder Protokollierungsfunktionen wurden beendet. - Ursache, Maßnahme, Rückweg und Ergebnis wurden dokumentiert. --- **36. Dokumentationsbeispiel** ```text Symptom: Die Laufwerkszuordnung aus der Gruppenrichtlinie wurde auf einem Client nicht erstellt. Zeitpunkt: 02.08.2026, 10:18 Uhr MESZ Betroffener Benutzer: max.mustermann Betroffener Computer: CLIENT-17 Verwendeter Domänencontroller: DC02.ad.example.local Nachweis: DNS-Auflösung, Zeit und SYSVOL-Zugriff waren erfolgreich. Der gpresult-Bericht zeigte die GPO als abgelehnt. Als Ablehnungsgrund wurde die Sicherheitsfilterung angegeben. Die erforderliche Benutzergruppe war im Active Directory eingetragen, fehlte aber im aktuellen Anmeldetoken. Ursache: Die Gruppenmitgliedschaft wurde erst nach Beginn der bestehenden Benutzersitzung hinzugefügt. Maßnahme: Der Benutzer meldete sich kontrolliert ab und erneut an. An der GPO und ihren Berechtigungen wurde nichts verändert. Rollback: Nicht erforderlich, da keine Konfiguration geändert wurde. Verifikation: whoami /groups zeigt die vorgesehene Gruppe. gpresult zeigt die angewendete GPO. Das Laufwerk wurde verbunden. Keine neuen Fehler im GroupPolicy-Protokoll. Prävention: Bei Änderungen an Gruppenmitgliedschaften wird künftig berücksichtigt, dass bestehende Anmeldetoken nicht automatisch vollständig erneuert werden. ``` --- **37. Entscheidungsbaum** ```text Domänenanmeldung, GPO oder Ressourcenzugriff gestört ↓ Stimmen IP-Konfiguration und interne DNS-Server? ├── Nein │ ↓ │ Netzwerk- und DNS-Konfiguration korrigieren │ └── Ja ↓ Werden AD-SRV-Einträge und DCs gefunden? ├── Nein │ ↓ │ DNS-Zone, SRV-Einträge und DC-Dienste prüfen │ └── Ja ↓ Sind DC und benötigte Ports erreichbar? ├── Nein │ ↓ │ Routing, Firewall, Standort und Dienste prüfen │ └── Ja ↓ Stimmen Zeit und Secure Channel? ├── Nein │ ↓ │ Zeitquelle oder Vertrauensbeziehung untersuchen │ └── Ja ↓ Ist die AD-Replikation fehlerfrei? ├── Nein │ ↓ │ Replikationsfehler nach Code und Richtung analysieren │ └── Ja ↓ Betrifft der Fehler Gruppenrichtlinien? ├── Ja │ ↓ │ gpresult, SYSVOL, Filter, OU und Ereignisse prüfen │ └── Nein ↓ Betrifft der Fehler Kerberos oder einen Dienst? ├── Ja │ ↓ │ Tickets, SPNs, Zielname und Dienstkonto prüfen │ └── Nein ↓ Konto, Gruppen, Berechtigungen und Anwendung untersuchen ``` --- **38. Typische Prüfungsfragen** **Warum ist DNS für Active Directory besonders wichtig?**
Antwort anzeigen Active Directory verwendet DNS und insbesondere SRV-Einträge, damit Clients Domänencontroller, Kerberos-Dienste und Global Catalogs finden. Eine reine Auflösung externer Internetnamen reicht für eine funktionierende Domänenumgebung nicht aus.
**Warum kann ein neues Kennwort an einem Client funktionieren und an einem anderen nicht?**
Antwort anzeigen Die Clients können unterschiedliche Domänencontroller verwenden. Bei einer Replikationsstörung ist das neue Kennwort möglicherweise noch nicht auf allen benötigten Domänencontrollern verfügbar.
**Wozu dient `gpresult`?**
Antwort anzeigen `gpresult` zeigt die resultierenden Gruppenrichtlinien für einen Benutzer oder Computer. Es kann angewendete und abgelehnte GPOs, Sicherheitsgruppen, Filter und weitere Verarbeitungsinformationen darstellen.
**Warum ist `gpupdate /force` noch keine Fehlerbehebung?**
Antwort anzeigen Der Befehl löst eine erneute Verarbeitung der Gruppenrichtlinien aus. Er erklärt jedoch nicht, warum eine GPO zuvor nicht angewendet wurde. Dafür müssen Ergebnisbericht, Ereignisse, Filterung, Verknüpfung und Abhängigkeiten geprüft werden.
**Warum kann eine neue Gruppenmitgliedschaft trotz korrektem AD-Eintrag noch wirkungslos sein?**
Antwort anzeigen Das aktuelle Anmeldetoken wurde möglicherweise vor der Gruppenänderung erzeugt. Die neue Mitgliedschaft ist dann noch nicht im Token enthalten und wird häufig erst nach erneuter Anmeldung wirksam.
**Welche drei grundlegenden Abhängigkeiten benötigt Kerberos besonders?**
Antwort anzeigen Kerberos benötigt insbesondere funktionierende DNS-Auflösung, ausreichend genaue Zeitsynchronisation und korrekte beziehungsweise eindeutige Dienstidentitäten in Form von SPNs.
**Was ist ein SPN?**
Antwort anzeigen Ein Service Principal Name identifiziert eine konkrete Dienstinstanz und ist einem Active-Directory-Konto zugeordnet. Der KDC verwendet ihn, um ein Dienstticket für den richtigen Dienst auszustellen.
**Warum kann ein doppelter SPN die Kerberos-Authentifizierung verhindern?**
Antwort anzeigen Der KDC kann den Dienst nicht eindeutig einem Konto zuordnen. Dadurch kann kein korrektes Dienstticket für die erwartete Dienstidentität ausgestellt werden.
**Warum sollte ein Computer nicht sofort aus der Domäne entfernt werden?**
Antwort anzeigen Dadurch wird der für die Diagnose wichtige Zustand verändert. Außerdem kann die Maßnahme zusätzliche Probleme mit Computerkonto, Profilen, Berechtigungen, Zertifikaten und verwalteter Konfiguration erzeugen.
**Worin unterscheiden sich AD- und SYSVOL-Replikation bei einer GPO?**
Antwort anzeigen Der Group Policy Container mit den Verzeichnisinformationen liegt im Active Directory. Das Group Policy Template mit den dateibasierten Richtlinieninhalten liegt in SYSVOL. Beide Bestandteile müssen verfügbar und konsistent sein.
--- **39. Prüfungsfallen** - öffentlichen DNS-Server auf einem Domänenmitglied eintragen. - erfolgreichen Ping als Nachweis für funktionierendes Active Directory bewerten. - nur den A-Eintrag, aber keine SRV-Einträge prüfen. - IP-Erreichbarkeit mit funktionierender Authentifizierung gleichsetzen. - Zeitabweichung übersehen. - Domänencontroller und DNS-Server ungeprüft neu starten. - Computer sofort aus der Domäne entfernen. - Computerkonto ohne Sicherung löschen. - Secure Channel reparieren, obwohl DNS oder Replikation gestört ist. - Gruppenmitgliedschaft im AD mit dem aktuellen Token gleichsetzen. - Benutzer wegen fehlender Berechtigung in eine weitreichende Administratorgruppe aufnehmen. - `gpupdate /force` als alleinige Fehleranalyse verwenden. - Benutzer- und Computerrichtlinien verwechseln. - falschen Benutzerkontext für `gpresult` verwenden. - OU des Benutzers prüfen, obwohl eine Computerrichtlinie betroffen ist. - Sicherheitsfilterung, WMI-Filter oder Loopback übersehen. - GPO löschen, statt Verknüpfung und Filterung zu untersuchen. - SYSVOL-Zugriff nicht prüfen. - AD-Replikation prüfen, aber SYSVOL-Replikation übersehen. - Replikation ungeprüft erzwingen. - einzelne `dcdiag`-Warnung ohne Zusammenhang als Ursache bewerten. - Event-ID ohne Provider und vollständigen Text interpretieren. - Kerberos und NTLM nicht unterscheiden. - Zugriff per IP-Adresse als dauerhafte Lösung verwenden. - Ticketcache vor der Dokumentation löschen. - SPN ohne vorherige Suche verändern. - gültigen SPN dem falschen Dienstkonto zuordnen. - doppelten SPN ungeprüft entfernen. - mehrere Änderungen gleichzeitig durchführen. - nach einer Maßnahme weder Ticket noch GPO-Ergebnis erneut prüfen. - keine praktische Benutzerfunktion testen. --- **40. Checkliste** - [ ] exakter Fehlertext wurde dokumentiert. - [ ] Fehlerzeitpunkt und Zeitzone wurden erfasst. - [ ] betroffener Benutzer wurde bestimmt. - [ ] betroffener Computer wurde bestimmt. - [ ] betroffener Zielserver oder Dienst wurde bestimmt. - [ ] lokale und Domänenanmeldung wurden unterschieden. - [ ] IP-Konfiguration wurde geprüft. - [ ] vorgesehene interne DNS-Server werden verwendet. - [ ] DNS-Suffix wurde geprüft. - [ ] AD-SRV-Einträge wurden geprüft. - [ ] verwendeter Domänencontroller wurde bestimmt. - [ ] Standort beziehungsweise AD-Site wurde berücksichtigt. - [ ] DC-Erreichbarkeit wurde geprüft. - [ ] benötigte Ports wurden geprüft. - [ ] SYSVOL wurde geprüft. - [ ] NETLOGON wurde geprüft. - [ ] Zeit und Zeitzone wurden geprüft. - [ ] Zeitquelle wurde geprüft. - [ ] Secure Channel wurde geprüft. - [ ] Benutzerkonto wurde auf Sperre und Ablauf geprüft. - [ ] Computerkonto wurde geprüft. - [ ] AD-Gruppenmitgliedschaften wurden geprüft. - [ ] aktuelles Benutzertoken wurde geprüft. - [ ] AD-Replikation wurde geprüft. - [ ] letzter erfolgreicher Replikationszeitpunkt wurde dokumentiert. - [ ] Replikationsrichtung wurde berücksichtigt. - [ ] `dcdiag` wurde bei DC-Problemen ausgewertet. - [ ] FSMO-Rollen wurden bei passendem Fehlerbild geprüft. - [ ] Benutzer- und Computerrichtlinien wurden unterschieden. - [ ] `gpresult` wurde im richtigen Kontext erzeugt. - [ ] angewendete und abgelehnte GPOs wurden geprüft. - [ ] OU und GPO-Verknüpfung wurden geprüft. - [ ] Sicherheitsfilterung wurde geprüft. - [ ] WMI-Filter wurde geprüft. - [ ] Vererbung und Erzwingen wurden geprüft. - [ ] Loopbackverarbeitung wurde berücksichtigt. - [ ] GroupPolicy-Operational-Protokoll wurde geprüft. - [ ] vorhandene Kerberos-Tickets wurden dokumentiert. - [ ] verwendeter Zielname wurde dokumentiert. - [ ] benötigter SPN wurde bestimmt. - [ ] SPN-Zuordnung wurde geprüft. - [ ] doppelte SPNs wurden bei Bedarf gesucht. - [ ] Kerberos- und Sicherheitsereignisse wurden zeitlich korreliert. - [ ] letzte Änderungen wurden berücksichtigt. - [ ] funktionierender Vergleichsclient wurde verwendet. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] Anmeldung wurde erneut getestet. - [ ] GPO-Ergebnis wurde erneut geprüft. - [ ] Kerberos-Ticket wurde erneut geprüft. - [ ] konkrete Benutzerfunktion wurde getestet. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. - [ ] vorbeugende Maßnahme wurde festgelegt. --- **41. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Domäne wird nicht gefunden | `ipconfig /all`, `nslookup`, `nltest /dsgetdc` | | falscher DNS-Server | Adapter-, DHCP- und DNS-Konfiguration | | DC wird nicht gefunden | SRV-Abfragen und `nltest` | | Anmeldung nur offline möglich | DC-Erreichbarkeit, Zeit, Secure Channel | | Vertrauensstellung fehlgeschlagen | `Test-ComputerSecureChannel`, `nltest` | | neues Kennwort funktioniert nicht überall | `repadmin`, verwendeten DC bestimmen | | Replikationsfehler | `repadmin /replsummary`, `repadmin /showrepl` | | DC-Zustand unklar | `dcdiag /v` | | DNS auf DC fehlerhaft | `dcdiag /test:dns /v` | | GPO fehlt | `gpresult`, GPMC | | GPO abgelehnt | `gpresult /h`, Sicherheitsfilterung | | GPO-Einstellung fehlt | Detailbericht und GroupPolicy-Protokoll | | SYSVOL nicht erreichbar | DNS, SMB-Port und Freigaben | | Gruppenänderung wirkt nicht | `whoami /groups`, erneute Anmeldung | | Konto wird wiederholt gesperrt | Sicherheitsprotokoll und gespeicherte Anmeldedaten | | Kerberos-Ticket fehlt | `klist`, DNS, Zeit | | Dienstticket fehlt | `klist`, `setspn -Q` | | doppelter SPN vermutet | `setspn -X` | | Fehler nur über Alias | DNS- und SPN-Zuordnung | | Zugriff nur über IP möglich | DNS, Zielname, SPN und Kerberos | | Fehler nur an einem Standort | AD-Site, DC-Auswahl und Replikation | | Fehler nur auf einem Client | lokale DNS-, Konto-, Token- oder Profilprüfung | --- **Merksatz** > Active-Directory-Fehler werden von unten nach oben analysiert: Netzwerk, DNS, Domänencontroller, Zeit, Secure Channel, Replikation, Konten, Gruppenrichtlinien und Kerberos. Erst wenn die Abhängigkeiten nachweislich funktionieren, wird die betroffene Richtlinie, Berechtigung oder Anwendung verändert. Jede Änderung benötigt einen Rückweg und eine erneute Funktionsprüfung. --- **Quellen und weiterführende Dokumentation** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – AD DS Troubleshooting](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/ad-ds-troubleshooting) - [Microsoft Learn – Troubleshooting Active Directory Replication Problems](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshooting-active-directory-replication-problems) - [Microsoft Learn – Diagnose Active Directory Replication Failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures) - [Microsoft Learn – Active Directory Replication Error 1722](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replication-error-1722-rpc-server-unavailable) - [Microsoft Learn – Active Directory Replication Error 5](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/replications-fail-with-error-5) - [Microsoft Learn – Group Policy Processing](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-processing) - [Microsoft Learn – Applying Group Policy Troubleshooting Guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/applying-group-policy-troubleshooting-guidance) - [Microsoft Learn – Kerberos Authentication Troubleshooting Guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance) - [Microsoft Learn – Domain Controller Is Not Functioning Correctly](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/domain-controller-not-functioning-correctly) - [Microsoft Learn – Repadmin](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963(v=ws.11)) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Gpresult](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpresult) - [Microsoft Learn – Gpupdate](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpupdate) - [Microsoft Learn – Klist](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist) - [Microsoft Learn – Setspn](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setspn) - [Microsoft Learn – W32tm](https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings) - [Microsoft Learn – Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel) - [Microsoft Learn – Get-ADReplicationFailure](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationfailure) - [Microsoft Learn – Get-ADReplicationPartnerMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationpartnermetadata) # 8.3 Datei-, Freigabe-, Rechte- und Druckdienste analysieren Datei- und Druckdienstfehler entstehen häufig nicht durch eine einzelne Komponente. Namensauflösung, Netzwerk, Authentifizierung, Freigabeberechtigungen, Dateisystemrechte, Gruppenmitgliedschaften, SMB-Einstellungen, DFS, Speicherplatz und Druckwarteschlangen wirken zusammen. Grundregel: > Zuerst feststellen, ob bereits die Verbindung, die Authentifizierung, die Freigabe, die Datei oder erst die konkrete Aktion fehlschlägt. --- **1. Diagnosekette bei Dateizugriffen** ```text Client ↓ DNS-Auflösung ↓ Netzwerk und TCP 445 ↓ SMB-Dienst ↓ Authentifizierung ↓ Freigabeberechtigung ↓ NTFS-Berechtigung ↓ Datei, Ordner, Sperre oder Anwendung ↓ Datenträger und Backend ``` Jede Stufe muss getrennt geprüft werden. | Prüfschritt | Typische Frage | |---|---| | Namensauflösung | Zeigt der Servername auf die richtige IP-Adresse? | | Netzwerk | Ist der Server über den vorgesehenen Pfad erreichbar? | | SMB-Port | Ist TCP 445 erreichbar? | | SMB-Dienst | Nimmt der Server SMB-Verbindungen an? | | Authentifizierung | Mit welchem Konto erfolgt der Zugriff? | | Freigaberecht | Darf das Konto die Freigabe verwenden? | | NTFS-Recht | Darf das Konto den Ordner oder die Datei verwenden? | | Objektzustand | Existiert die Datei und ist sie verfügbar? | | Sperre | Wird die Datei von einem Prozess blockiert? | | Speicher | Sind Datenträger, Quota und Backend funktionsfähig? | --- **2. Fehler exakt aufnehmen** Zu dokumentieren sind: - vollständiger UNC-Pfad; - Servername und Freigabename; - betroffener Benutzer; - betroffener Client; - genaue Aktion; - vollständiger Fehlertext; - Fehlercode; - Zeitpunkt mit Zeitzone; - verwendete Netzwerkverbindung; - funktioniert der Zugriff über IP-Adresse, Kurzname oder FQDN; - funktioniert eine andere Freigabe auf demselben Server; - funktioniert dieselbe Freigabe für einen anderen Benutzer; - funktioniert derselbe Benutzer an einem anderen Client; - trat der Fehler nach einer Rechte-, Gruppen-, GPO-, DNS- oder Serveränderung auf. Beispiele für unterschiedliche Aktionen: - Freigabe auflisten; - Ordner öffnen; - Datei lesen; - Datei erstellen; - Datei ändern; - Datei löschen; - Datei umbenennen; - Unterordner erstellen; - Berechtigungen ändern; - Eigentümer übernehmen. Ein Benutzer kann einen Ordner möglicherweise öffnen, aber keine Datei erstellen oder löschen. Deshalb genügt die Aussage „Zugriff funktioniert nicht“ nicht. --- **3. UNC-Pfad und Ziel bestimmen** Typischer UNC-Pfad: ```text \\fileserver01\Daten ``` Mit FQDN: ```text \\fileserver01.ad.example.local\Daten ``` Über DFS: ```text \\ad.example.local\Daten\Abteilung ``` Zu unterscheiden sind: - tatsächlicher Dateiserver; - DNS-Name oder Alias; - DFS-Namespace; - Freigabename; - lokaler Pfad auf dem Server; - verbundenes Netzlaufwerk; - eventuell verwendeter Cluster- oder Failovername. Ein Netzlaufwerk wie `H:` verdeckt den tatsächlichen UNC-Pfad. Dieser kann beispielsweise mit folgendem Befehl geprüft werden: ```cmd net use ``` PowerShell: ```powershell Get-SmbMapping ``` --- **4. DNS-Auflösung prüfen** ```powershell Resolve-DnsName fileserver01 ``` ```powershell Resolve-DnsName fileserver01.ad.example.local ``` ```cmd nslookup fileserver01 ``` Zusätzlich prüfen: ```cmd ping fileserver01 ``` Der Ping dient hier hauptsächlich dazu, den aufgelösten Namen und die Zieladresse zu sehen. Er beweist nicht, dass SMB funktioniert. Zu vergleichen sind: - Kurzname; - FQDN; - IP-Adresse; - erwartete Serveradresse; - IPv4- und IPv6-Ergebnis; - DNS-Alias; - DFS-Namespace-Name. Unterschiedliche Ergebnisse können auf Folgendes hinweisen: - falscher oder veralteter DNS-Eintrag; - falsches DNS-Suffix; - DNS-Cache; - `hosts`-Datei; - alter Serveralias; - DFS verweist auf ein anderes Ziel; - IPv4 und IPv6 führen über unterschiedliche Pfade; - Kerberos-SPN passt nicht zum verwendeten Namen. --- **5. SMB-Port prüfen** Windows: ```powershell Test-NetConnection fileserver01 -Port 445 ``` Ausführlicher: ```powershell Test-NetConnection fileserver01 ` -Port 445 ` -InformationLevel Detailed ``` Linux: ```bash nc -vz fileserver01 445 ``` Ein erfolgreicher Test auf TCP 445 zeigt: - der Name wurde aufgelöst; - eine Route zum Ziel ist vorhanden; - der TCP-Verbindungsaufbau war möglich; - auf dem Ziel oder einem vorgeschalteten System wurde die Verbindung angenommen. Er beweist noch nicht: - erfolgreiche SMB-Authentifizierung; - Zugriff auf eine bestimmte Freigabe; - ausreichende Berechtigungen; - Verfügbarkeit einer bestimmten Datei; - Funktionsfähigkeit des Storage-Backends. --- **6. SMB-Clientverbindungen prüfen** Aktuelle SMB-Verbindungen: ```powershell Get-SmbConnection ``` Ausgewählte Informationen: ```powershell Get-SmbConnection | Select-Object ServerName, ShareName, UserName, Credential, Dialect, NumOpens ``` SMB-Zuordnungen: ```powershell Get-SmbMapping ``` Klassische Anzeige: ```cmd net use ``` Dabei sind besonders zu prüfen: - Servername; - Freigabename; - verwendetes Benutzerkonto; - Verbindungsstatus; - SMB-Dialekt; - bereits bestehende Verbindungen zum selben Server; - Verbindung über Alias, Kurzname oder FQDN. --- **7. Konflikt durch unterschiedliche Anmeldedaten** Windows verwendet für Verbindungen zu einem Server nicht beliebig viele verschiedene Anmeldeinformationen innerhalb desselben Benutzerkontexts. Typisches Fehlerbild: ```text Mehrfache Verbindungen zu einem Server oder einer freigegebenen Ressource von demselben Benutzer unter Verwendung mehrerer Benutzernamen sind nicht zulässig. ``` Bestehende Verbindungen anzeigen: ```cmd net use ``` Gespeicherte Anmeldeinformationen anzeigen: ```cmd cmdkey /list ``` Mögliche Ursachen: - alte Verbindung zum selben Server; - Verbindung über einen anderen Freigabenamen; - gespeicherte falsche Anmeldedaten; - Dienst oder Skript verwendet ein anderes Konto; - Server wird einmal über Kurzname und einmal über Alias angesprochen; - Laufwerkszuordnung wurde bereits mit anderen Anmeldedaten hergestellt. Verbindungen dürfen nicht pauschal gelöscht werden, ohne ihre Verwendung zu prüfen. Ein Trennen kann geöffnete Dateien oder Anwendungen unterbrechen. Gezieltes Trennen einer Zuordnung: ```cmd net use Z: /delete ``` Gezieltes Trennen eines UNC-Ziels: ```cmd net use \\fileserver01\Daten /delete ``` --- **8. Freigaben auf dem Server prüfen** Vorhandene SMB-Freigaben: ```powershell Get-SmbShare ``` Bestimmte Freigabe: ```powershell Get-SmbShare -Name Daten ``` Wichtige Eigenschaften: ```powershell Get-SmbShare -Name Daten | Select-Object Name, Path, Description, ScopeName, FolderEnumerationMode, EncryptData, ConcurrentUserLimit ``` Klassische Anzeige: ```cmd net share ``` Zu prüfen sind: - Freigabe existiert; - Freigabename ist korrekt; - lokaler Zielpfad existiert; - Datenträger oder Mountpoint ist verfügbar; - Freigabe zeigt nicht auf einen alten Pfad; - Freigabe ist im richtigen Server- oder Cluster-Scope vorhanden; - erforderliche SMB-Einstellungen sind aktiv; - versteckte Freigabe mit `$` wurde korrekt angegeben. Administrative Freigaben wie `C$` benötigen normalerweise administrative Berechtigungen und sind kein geeigneter allgemeiner Funktionstest für normale Benutzer. --- **9. Freigabeberechtigungen prüfen** ```powershell Get-SmbShareAccess -Name Daten ``` Beispielausgabe: ```text Name AccountName AccessControlType AccessRight ---- ----------- ----------------- ----------- Daten AD\GG-Dateidienst-Lesen Allow Read Daten AD\GG-Dateidienst-Ändern Allow Change ``` Wichtige Freigaberechte: | Freigaberecht | Grundsätzliche Wirkung | |---|---| | Lesen | Inhalte anzeigen und Dateien lesen | | Ändern | zusätzlich erstellen, ändern und löschen | | Vollzugriff | zusätzlich Freigabeberechtigungen verwalten | Die genaue wirksame Berechtigung ergibt sich nicht allein aus dieser Tabelle. Verweigerungen, Gruppenmitgliedschaften und NTFS-Berechtigungen müssen zusätzlich berücksichtigt werden. --- **10. NTFS-Berechtigungen prüfen** PowerShell: ```powershell Get-Acl 'D:\Freigaben\Daten' | Format-List ``` Einzelne Zugriffsregeln: ```powershell (Get-Acl 'D:\Freigaben\Daten').Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited, InheritanceFlags, PropagationFlags ``` Kommandozeile: ```cmd icacls D:\Freigaben\Daten ``` Rekursives Auslesen kann bei großen Verzeichnisstrukturen sehr umfangreich und belastend sein. Es sollte nur gezielt eingesetzt werden. Zu prüfen sind: - Benutzer- und Gruppeneinträge; - Zulassen oder Verweigern; - Vererbung; - nur für diesen Ordner geltende Rechte; - Rechte für Unterordner und Dateien; - Eigentümer; - explizite Einträge; - geerbte Einträge; - unterbrochene Vererbung; - abweichende Rechte auf dem betroffenen Unterordner oder der Datei. --- **11. Freigabe- und NTFS-Rechte gemeinsam bewerten** Bei einem SMB-Zugriff wirken grundsätzlich beide Ebenen: ```text wirksames Freigaberecht + wirksames NTFS-Recht ↓ restriktivere wirksame Kombination ``` Beispiele: | Freigabe | NTFS | Ergebnis über SMB | |---|---|---| | Lesen | Ändern | Lesen | | Ändern | Lesen | Lesen | | Vollzugriff | Ändern | Ändern | | Vollzugriff | Vollzugriff | Vollzugriff | | Ändern | keine Berechtigung | kein Zugriff | Beim lokalen Zugriff auf den Serverpfad gelten die Freigabeberechtigungen nicht. Dort werden nur die Dateisystemberechtigungen ausgewertet. Deshalb kann ein lokaler Test auf dem Server funktionieren, während der Zugriff über SMB fehlschlägt. --- **12. Lesen, Ändern und Vollzugriff unterscheiden** Typische NTFS-Rechte: | Recht | Bedeutung | |---|---| | Ordnerinhalt anzeigen | Ordner durchsuchen und Inhalte auflisten | | Lesen | Inhalte und Eigenschaften lesen | | Schreiben | Dateien oder Daten erstellen beziehungsweise schreiben | | Lesen und Ausführen | Dateien lesen und ausführbare Dateien starten | | Ändern | lesen, schreiben, ausführen und löschen | | Vollzugriff | zusätzlich Berechtigungen und Eigentum verwalten | Für normale gemeinsame Datenordner reicht häufig `Ändern`. `Vollzugriff` sollte nicht ohne fachlichen Grund vergeben werden. --- **13. Löschen benötigt besondere Beachtung** Zum Löschen eines Objekts kann abhängig von der ACL eines der folgenden Rechte entscheidend sein: - `Löschen` auf der Datei oder dem Ordner; - `Unterordner und Dateien löschen` auf dem übergeordneten Ordner. Dadurch können scheinbar widersprüchliche Situationen entstehen: - Benutzer kann eine Datei ändern, aber nicht löschen; - Benutzer kann eine Datei löschen, obwohl die Datei selbst keinen offensichtlichen Lösch-Eintrag zeigt; - Benutzer kann Dateien erstellen, aber nicht umbenennen; - Benutzer kann Ordner öffnen, aber bestimmte Unterordner nicht auflisten. Die Berechtigungen müssen deshalb auf dem betroffenen Objekt und dem übergeordneten Ordner geprüft werden. --- **14. Vererbung kontrollieren** ```powershell (Get-Acl 'D:\Freigaben\Daten\Abteilung').AreAccessRulesProtected ``` Mögliche Zustände: - Vererbung aktiv; - Vererbung deaktiviert und geerbte Einträge kopiert; - Vererbung deaktiviert und geerbte Einträge entfernt; - einzelne explizite Rechte ergänzen die geerbten Rechte; - explizite Verweigerung schränkt geerbte Zulassung ein. Typische Fehler: - neuer Unterordner übernimmt unerwartete Rechte; - Vererbung wurde an einer Zwischenebene unterbrochen; - Berechtigung gilt nur für den aktuellen Ordner; - Berechtigung gilt nur für Unterordner; - migrierte Dateien besitzen alte ACLs; - Eigentümer oder Vererbungsquelle stimmt nicht mehr. Berechtigungen sollten nicht rekursiv ersetzt werden, bevor Umfang, Vererbung und Rückweg vollständig geklärt sind. --- **15. Gruppenmitgliedschaften prüfen** AD-Mitgliedschaften eines Benutzers: ```powershell Get-ADPrincipalGroupMembership max.mustermann | Select-Object Name ``` Aktuelle Gruppen im Anmeldetoken: ```cmd whoami /groups ``` Aktuelles Konto: ```cmd whoami ``` Benutzer-SID: ```cmd whoami /user ``` Berechtigungen des aktuellen Tokens: ```cmd whoami /priv ``` Wichtige Unterscheidung: ```text Mitgliedschaft im Active Directory ≠ Mitgliedschaft im bereits erzeugten Anmeldetoken ``` Wurde ein Benutzer gerade einer Gruppe hinzugefügt, kann eine erneute Anmeldung erforderlich sein. Eine bloße Sperrung und Entsperrung des Bildschirms erzeugt normalerweise kein vollständig neues interaktives Anmeldetoken. --- **16. Effektive Berechtigungen bewerten** Die grafische Registerkarte befindet sich üblicherweise unter: ```text Eigenschaften → Sicherheit → Erweitert → Effektiver Zugriff ``` Dabei muss der richtige Benutzer beziehungsweise Sicherheitsprinzipal ausgewählt werden. Zu berücksichtigen sind: - direkte Benutzerrechte; - verschachtelte Gruppen; - Domänen- und lokale Gruppen; - geerbte Rechte; - explizite Rechte; - Verweigerungen; - aktuelles Token; - Share- und NTFS-Ebene; - Zugriff über DFS oder direkt auf den Zielserver. Die Anzeige der effektiven NTFS-Rechte ersetzt nicht die Prüfung der Freigabeberechtigungen. --- **17. Zulassen und Verweigern** Eine explizite Verweigerung kann ein ansonsten gewährtes Recht blockieren. Trotzdem darf nicht vereinfacht angenommen werden, dass jede sichtbare Verweigerung immer sämtliche Zulassungen überschreibt. Die Auswertung hängt unter anderem ab von: - expliziten und geerbten Einträgen; - Benutzer- und Gruppenzugehörigkeit; - Reihenfolge der kanonischen ACL; - betroffenem Einzelrecht; - Objekt- und Vererbungsbereich; - Share- und NTFS-Ebene. Verweigerungen sollten sparsam verwendet werden. Eine saubere Gruppen- und Ordnerstruktur ist häufig leichter zu analysieren. --- **18. Access-Based Enumeration** Access-Based Enumeration kann Ordner vor Benutzern ausblenden, die darauf keine Berechtigung besitzen. Einstellung anzeigen: ```powershell Get-SmbShare -Name Daten | Select-Object FolderEnumerationMode ``` Mögliche Folge: - Ordner existiert; - direkter Zugriff kann abhängig von den Rechten möglich sein; - Ordner erscheint beim Auflisten der Freigabe nicht. Ein ausgeblendeter Ordner wurde daher nicht zwangsläufig gelöscht oder nicht repliziert. --- **19. Geöffnete Dateien und SMB-Sitzungen prüfen** Auf dem Dateiserver: ```powershell Get-SmbSession ``` Geöffnete Dateien: ```powershell Get-SmbOpenFile ``` Gefiltert nach Pfad: ```powershell Get-SmbOpenFile | Where-Object { $_.Path -like '*\Daten\*' } ``` Wichtige Informationen: - Clientcomputer; - Benutzername; - Sitzungs-ID; - Dateipfad; - Anzahl geöffneter Dateien; - verbundene Zeit; - Leerlaufzeit; - verwendeter SMB-Dialekt. Eine Sitzung oder Datei darf nicht ungeprüft geschlossen werden. Nicht gespeicherte Daten können verloren gehen. --- **20. Dateisperren untersuchen** Typische Meldungen: - Datei wird von einem anderen Prozess verwendet; - Zugriff verweigert; - Dokument ist für die Bearbeitung gesperrt; - schreibgeschützter Zugriff; - Umbenennen oder Löschen nicht möglich. Mögliche Ursachen: - Datei ist auf einem anderen Client geöffnet; - Anwendung verwendet eine eigene Sperrdatei; - Virenscanner oder Indexdienst greift auf die Datei zu; - Backup- oder Synchronisationssoftware hält ein Handle; - Prozess auf dem Server verwendet die Datei; - vorherige Anwendungssitzung wurde nicht sauber beendet; - Benutzer besitzt kein Änderungs- oder Löschrecht; - Datei oder Ordner ist schreibgeschützt; - Anwendung verwendet ein eigenes Check-out-Verfahren. Werkzeuge: - `Get-SmbOpenFile`; - Computerverwaltung → Freigegebene Ordner → Geöffnete Dateien; - Sysinternals Handle; - Process Explorer; - Process Monitor; - anwendungsspezifische Protokolle. Nicht jede Meldung über eine „gesperrte Datei“ beweist eine technische SMB-Sperre. Anwendungen können eigene Sperrmechanismen verwenden. --- **21. SMB-Serverkonfiguration prüfen** ```powershell Get-SmbServerConfiguration ``` Ausgewählte Werte: ```powershell Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol, RequireSecuritySignature, EncryptData, EnableLeasing, EnableOplocks, AuditSmb1Access ``` Clientkonfiguration: ```powershell Get-SmbClientConfiguration ``` Zu prüfen sind: - unterstützter SMB-Dialekt; - SMB-Signierung; - SMB-Verschlüsselung; - Gastzugriff; - alte SMB-Versionen; - Richtlinienänderungen; - Kompatibilität mit NAS, Scanner oder Altgerät; - Abweichungen zwischen funktionierendem und betroffenem Client. SMB 1 darf nicht pauschal als Problemlösung aktiviert werden. Das Protokoll ist veraltet und besitzt erhebliche Sicherheitsnachteile. Bei Altgeräten ist eine Aktualisierung, Segmentierung oder Ablösung zu prüfen. --- **22. Verwendeten SMB-Dialekt bestimmen** ```powershell Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted ``` Mögliche Beobachtungen: - moderner Client verwendet unerwartet alten Dialekt; - Signierung wird verlangt, aber nicht unterstützt; - Verschlüsselung wird verlangt, aber nicht ausgehandelt; - Verbindung zu einem alten NAS scheitert; - Verbindung über einen anderen Namen erzeugt einen anderen Authentifizierungsweg. Die tatsächlich verwendete Verbindung muss geprüft werden. Eine allgemeine Servereinstellung beweist noch nicht, welcher Dialekt in einer bestimmten Sitzung ausgehandelt wurde. --- **23. Kerberos und NTLM bei SMB** Tickets prüfen: ```cmd klist ``` Für SMB ist typischerweise ein Dienstticket für einen SPN nach folgendem Muster relevant: ```text cifs/fileserver01 ``` SPN suchen: ```cmd setspn -Q cifs/fileserver01 ``` Mit FQDN: ```cmd setspn -Q cifs/fileserver01.ad.example.local ``` Mögliche Ursachen für NTLM statt Kerberos: - Zugriff über IP-Adresse; - fehlender oder falscher SPN; - Zugriff über nicht registrierten Alias; - DNS-Problem; - keine geeignete Vertrauensbeziehung; - Anwendung oder Gerät unterstützt Kerberos nicht; - Kerberos schlägt fehl und NTLM-Fallback ist möglich. Ein erfolgreicher SMB-Zugriff beweist nicht automatisch, dass Kerberos verwendet wurde. --- **24. Zugriff über Alias prüfen** Beispiel: ```text \\fileserver01\Daten \\datenserver\Daten ``` Beide Namen können auf dieselbe IP-Adresse zeigen, aber für Kerberos unterschiedliche Dienstidentitäten darstellen. Zu prüfen sind: - DNS-Eintrag des Alias; - CIFS-SPN für den verwendeten Namen; - Konto, dem der SPN zugeordnet ist; - Cluster- oder Computerkonto; - doppelte SPNs; - vorhandene Kerberos-Tickets; - Server- und SMB-Konfiguration. Ein zusätzlicher DNS-CNAME allein stellt noch nicht sicher, dass Kerberos über den Alias funktioniert. --- **25. DFS-Namespace untersuchen** Ein DFS-Pfad kann Benutzer auf einen oder mehrere tatsächliche Zielserver verweisen: ```text \\ad.example.local\Daten\Abteilung ``` DFS-Namespace-Informationen: ```powershell Get-DfsnRoot ``` Ordner und Ziele: ```powershell Get-DfsnFolder ``` ```powershell Get-DfsnFolderTarget ``` Clientseitige DFS-Informationen: ```cmd dfsutil /pktinfo ``` DFS-Cache anzeigen: ```cmd dfsutil /pktinfo ``` Zu prüfen sind: - Namespace erreichbar; - DFS-Ordner vorhanden; - Zielserver korrekt; - Ziel aktiviert; - Client verwendet das erwartete Ziel; - Standortzuordnung korrekt; - Zielserver erreichbar; - DNS-Auflösung des tatsächlichen Zielservers; - Berechtigungen auf jedem Ziel; - Replikationsstatus; - veralteter Client-Referral-Cache. --- **26. DFS-Namespace und DFS-Replikation unterscheiden** | Funktion | Aufgabe | |---|---| | DFS Namespace | stellt einen einheitlichen logischen Pfad bereit | | DFS Replication | repliziert Ordnerinhalte zwischen Servern | Ein funktionierender Namespace beweist nicht, dass die Daten repliziert wurden. Umgekehrt kann die Replikation funktionieren, während ein Namespace-Ziel falsch konfiguriert oder nicht erreichbar ist. Typisches Fehlerbild: - Benutzer erreicht den DFS-Pfad; - abhängig vom ausgewählten Zielserver fehlen Dateien; - Dateien besitzen unterschiedliche Versionen; - Rechte unterscheiden sich zwischen Zielen; - ein Replikationspartner ist verzögert oder gestört. --- **27. DFS-Replikation prüfen** Relevanter Ereignisprotokollpfad: ```text Ereignisanzeige → Anwendungs- und Dienstprotokolle → DFS Replication ``` PowerShell: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'DFS Replication' StartTime = (Get-Date).AddHours(-4) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Replikationsgruppen: ```powershell Get-DfsReplicationGroup ``` Mitgliedschaften: ```powershell Get-DfsrMembership ``` Verbindungen: ```powershell Get-DfsrConnection ``` Zu dokumentieren sind: - Replikationsgruppe; - replizierter Ordner; - Quell- und Zielserver; - betroffene Richtung; - letzter Fehler; - Zeitpunkt; - freier Speicherplatz; - Datenbankzustand; - Backlog; - Konflikt- oder Staging-Bereich; - letzte Änderungen. Eine manuell erzwungene Synchronisation ist keine erste Diagnosemaßnahme. --- **28. Offline Files und Clientcache** Windows kann Netzwerkdateien lokal zwischenspeichern. Dadurch können Benutzer zeitweise mit einer lokalen Kopie arbeiten. Mögliche Fehlerbilder: - alte Dateiversion wird angezeigt; - Synchronisierung schlägt fehl; - Datei ist offline verfügbar, obwohl der Server erreichbar sein sollte; - Konflikt zwischen lokaler und serverseitiger Änderung; - Netzlaufwerk wird als offline angezeigt; - unterschiedliche Benutzer sehen unterschiedliche Stände; - Anwendung arbeitet weiter, obwohl der Server nicht erreichbar ist. Zu prüfen sind: - Synchronisierungscenter; - Offlineverfügbarkeit; - Netzwerkstatus; - verwendeter UNC- beziehungsweise DFS-Pfad; - Konflikte; - Ereignisprotokolle; - GPO-Konfiguration; - Speicherplatz im lokalen Cache. Der Offlinecache darf nicht ungeprüft zurückgesetzt werden. Nicht synchronisierte Benutzerdaten könnten verloren gehen. --- **29. Quotas und freier Speicherplatz** Freien Speicherplatz prüfen: ```powershell Get-Volume ``` Dateisystemlaufwerke: ```powershell Get-PSDrive -PSProvider FileSystem ``` FSRM-Quotas: ```powershell Get-FsrmQuota ``` Mögliche Symptome: - Datei kann nicht gespeichert werden; - Kopieren bricht ab; - „Nicht genügend Speicherplatz“; - Benutzer kann kleine, aber keine großen Dateien speichern; - Anwendung meldet nur einen allgemeinen Schreibfehler; - Freigabe ist erreichbar, Änderungen schlagen jedoch fehl; - DFS-R oder Druckspooler arbeitet nicht mehr. Zu unterscheiden sind: - physischer Datenträger voll; - Thin-Provisioning-Pool voll; - Benutzer- oder Ordnerquota erreicht; - VSS- oder Snapshotbereich belegt Speicher; - temporärer Speicherplatz erschöpft; - Dateisystem besitzt ein anderes Limit; - Backend-Speicher des NAS oder SAN ist voll. --- **30. Lange Pfade und Dateinamen** Mögliche Ursachen: - gesamter Pfad ist zu lang; - Anwendung unterstützt lange Pfade nicht; - Dateiname enthält nicht unterstützte Zeichen; - Name endet problematisch mit Punkt oder Leerzeichen; - reservierter Gerätename wird verwendet; - Anwendung besitzt ein eigenes kürzeres Pfadlimit; - Archiv- oder Synchronisationssoftware kann den Pfad nicht verarbeiten; - Quell- und Zielsystem verwenden unterschiedliche Namensregeln. Typische reservierte Namen unter Windows sind beispielsweise: ```text CON PRN AUX NUL COM1 LPT1 ``` Die Unterstützung langer Pfade hängt nicht nur vom Betriebssystem ab. Auch Anwendung, API und Konfiguration müssen sie unterstützen. --- **31. Eigentümer und ACL-Zustand** Eigentümer anzeigen: ```powershell (Get-Acl 'D:\Freigaben\Daten').Owner ``` Mögliche Probleme: - nicht mehr auflösbare SID; - migriertes Benutzer- oder Gruppenkonto; - Eigentümer ist nicht mehr vorhanden; - ACL wurde bei Kopie oder Restore verändert; - Vererbung ist beschädigt oder unerwartet unterbrochen; - Backup wurde ohne Sicherheitsinformationen wiederhergestellt; - Dateien stammen aus einer anderen Domäne; - NAS bildet Windows-SIDs nicht korrekt ab. Nicht auflösbare SIDs beweisen allein keinen Fehler. Sie können noch wirksame Sicherheitskennungen ehemaliger oder nicht erreichbarer Domänenkonten darstellen und müssen vor einer Entfernung zugeordnet werden. --- **32. Ereignisprotokolle für SMB prüfen** Wichtige Protokollpfade können sein: ```text Microsoft → Windows → SMBClient → Connectivity ``` ```text Microsoft → Windows → SMBClient → Security ``` ```text Microsoft → Windows → SMBServer → Operational ``` ```text Microsoft → Windows → SMBServer → Security ``` PowerShell-Beispiel: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-SMBClient/Connectivity' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Zusätzlich können relevant sein: - System; - Sicherheit; - DNS Client Events; - Kerberos; - NETLOGON; - DFS Replication; - Failover Clustering; - NTFS; - Disk; - StorPort; - anwendungsspezifische Protokolle. Event-ID, Provider, Zeitpunkt, Server, Client und vollständiger Ereignistext müssen gemeinsam bewertet werden. --- **33. SMB-Netzwerkverkehr untersuchen** Bei unklarem Netzwerk- oder Protokollfehler kann ein Paketmitschnitt erforderlich sein. Typische Filter: ```text tcp.port == 445 ``` ```text smb2 ``` ```text ip.addr == 192.0.2.20 && tcp.port == 445 ``` Zu untersuchen sind: - TCP-Verbindungsaufbau; - Retransmissions; - TCP Reset; - SMB-Negotiation; - Session Setup; - Tree Connect; - Authentifizierungsfehler; - SMB-Statuscodes; - lange Antwortzeiten; - Verbindungsabbruch; - Server- oder Clientverzögerung. Ein Paketmitschnitt kann Datei- und Benutzernamen sowie weitere vertrauliche Informationen enthalten und muss geschützt gespeichert werden. --- **34. Druckpfad verstehen** ```text Anwendung ↓ Druckertreiber ↓ Windows-Druckwarteschlange ↓ Spooler ↓ Druckserver oder direkter TCP/IP-Port ↓ Netzwerk ↓ Drucker ↓ Druckwerk, Papier und Verbrauchsmaterial ``` Die Meldung „Drucker druckt nicht“ kann daher verursacht werden durch: - Anwendung; - Treiber; - Spooler; - Queue; - Druckserver; - Berechtigung; - Netzwerk; - DNS; - Portkonfiguration; - SNMP; - Druckerzustand; - Papier oder Toner; - mechanische Störung. --- **35. Druckerfehler exakt eingrenzen** Zu dokumentieren sind: - Druckername; - Freigabename; - Druckserver; - Drucker-IP; - DNS-Name; - Treibername und Version; - verwendeter Port; - betroffener Client; - betroffener Benutzer; - Anwendung; - Dokumenttyp; - Zeitpunkt; - Status der Warteschlange; - vollständiger Fehlertext; - funktioniert eine Windows-Testseite; - funktioniert ein anderes Dokument; - funktioniert der Druck aus einer anderen Anwendung; - funktioniert ein anderer Benutzer; - funktioniert ein anderer Drucker; - betrifft es einen oder alle Clients. Diese Tests trennen Anwendung, Benutzer, Client, Treiber, Queue, Server und Gerät voneinander. --- **36. Drucker und Warteschlangen anzeigen** PowerShell: ```powershell Get-Printer ``` Ausgewählte Eigenschaften: ```powershell Get-Printer | Select-Object Name, ComputerName, DriverName, PortName, Shared, ShareName, PrinterStatus, JobCount ``` Bestimmter Drucker: ```powershell Get-Printer -Name 'Drucker-01' ``` Druckaufträge: ```powershell Get-PrintJob -PrinterName 'Drucker-01' ``` Druckerkonfiguration: ```powershell Get-PrintConfiguration -PrinterName 'Drucker-01' ``` --- **37. Print Spooler prüfen** ```powershell Get-Service Spooler ``` Ausführlicher: ```powershell Get-CimInstance Win32_Service ` -Filter "Name='Spooler'" | Select-Object Name, State, StartMode, StartName, ProcessId ``` Abhängigkeiten: ```powershell Get-Service Spooler -DependentServices ``` Ein Neustart des Spoolers: ```powershell Restart-Service Spooler ``` verändert den Zustand und kann alle lokalen beziehungsweise serverseitigen Druckaufträge beeinflussen. Vorher sind zu prüfen: - betrifft der Fehler alle Drucker; - hängen einzelne oder alle Aufträge; - befinden sich wichtige Aufträge in der Queue; - stürzt der Spooler wiederholt ab; - welcher Treiber oder Print Processor ist beteiligt; - was zeigen Ereignisprotokolle; - besteht ein Wartungs- oder Freigabefenster. --- **38. Druckaufträge kontrollieren** ```powershell Get-PrintJob -PrinterName 'Drucker-01' | Select-Object ID, DocumentName, UserName, SubmittedTime, JobStatus, Size ``` Einzelnen Auftrag entfernen: ```powershell Remove-PrintJob ` -PrinterName 'Drucker-01' ` -ID 17 ``` Vor dem Entfernen prüfen: - gehört der Auftrag zum untersuchten Fehler; - handelt es sich um einen produktiv wichtigen Auftrag; - wird die Queue dadurch für andere Benutzer freigegeben; - tritt der Fehler mit einem neuen Testauftrag wieder auf. Nicht sofort die gesamte Warteschlange leeren, wenn ein einzelner Auftrag die Ursache sein könnte. --- **39. Druckerport prüfen** ```powershell Get-PrinterPort ``` Bestimmter Port: ```powershell Get-PrinterPort -Name 'IP_192.0.2.50' ``` Zu prüfen sind: - richtige IP-Adresse; - richtiger DNS-Name; - Standard-TCP/IP-Port; - Raw oder LPR; - TCP-Port 9100; - LPR-Queue-Name; - SNMP aktiviert; - SNMP-Community; - WSD statt festem TCP/IP-Port; - Druckeradresse nach DHCP-Änderung; - alter Port nach Druckeraustausch. Porttest für RAW Printing: ```powershell Test-NetConnection 192.0.2.50 -Port 9100 ``` Mögliche weitere Protokolle hängen vom Drucksystem ab, beispielsweise IPP, IPPS, LPR oder SMB. --- **40. SNMP-Statusfehler** Ein Drucker kann erreichbar und druckfähig sein, aber in Windows als offline erscheinen, wenn die SNMP-Statusabfrage fehlschlägt. Mögliche Ursachen: - SNMP auf dem Drucker deaktiviert; - falsche Community; - UDP 161 blockiert; - SNMP-Version nicht kompatibel; - Drucker beantwortet Statusabfragen fehlerhaft; - falscher Port verweist auf ein anderes Gerät; - Sicherheitsrichtlinie verhindert die Abfrage. Das Deaktivieren des SNMP-Status kann als kontrollierter Diagnosetest dienen. Es ist jedoch keine allgemeine Lösung, weil dadurch echte Gerätestatusinformationen verloren gehen können. --- **41. Druckertreiber untersuchen** Installierte Treiber: ```powershell Get-PrinterDriver ``` Mögliche Treiberprobleme: - falsches Druckermodell; - alter Treiber; - beschädigtes Treiberpaket; - herstellerspezifischer und universeller Treiber kollidieren; - Architektur- oder Betriebssysteminkompatibilität; - Treiber verursacht Spooler-Absturz; - Point-and-Print-Richtlinie verhindert Installation; - Treiber unterstützt Gerätefunktion nicht; - Druckdatenformat passt nicht zum Drucker; - Upgrade hinterließ alte Treiberkomponenten. Treiber dürfen nicht ungeprüft auf einem produktiven Druckserver ersetzt werden. Dadurch können mehrere Warteschlangen und Benutzer betroffen sein. --- **42. Windows-Testseite verwenden** Eine Testseite trennt die Anwendung teilweise vom restlichen Druckpfad. PowerShell über WMI/CIM: ```powershell Invoke-CimMethod ` -ClassName Win32_Printer ` -MethodName PrintTestPage ` -Arguments @{} ` -Filter "Name='Drucker-01'" ``` Bewertung: | Ergebnis | Wahrscheinlicher Bereich | |---|---| | Testseite funktioniert, Anwendung nicht | Anwendung, Dokument, Format oder anwendungsspezifische Einstellungen | | Testseite bleibt in Queue | Spooler, Treiber, Port oder Druckserver | | Auftrag verlässt Queue, Drucker reagiert nicht | Port, Netzwerk, Protokoll oder Gerät | | Auftrag wird gedruckt, Ausgabe fehlerhaft | Treiber, Druckersprache, Gerätekonfiguration oder Hardware | | alle Drucker betroffen | Spooler, Server, Richtlinie oder gemeinsamer Dienst | | nur ein Drucker betroffen | Queue, Port, Treiber oder Gerät | --- **43. Druckereignisse prüfen** Wichtiger Protokollpfad: ```text Ereignisanzeige → Anwendungs- und Dienstprotokolle → Microsoft → Windows → PrintService → Operational ``` Das Operational-Protokoll muss je nach System zunächst aktiviert werden. PowerShell: ```powershell Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-PrintService/Operational' StartTime = (Get-Date).AddHours(-2) } | Select-Object TimeCreated, Id, LevelDisplayName, Message ``` Zusätzlich prüfen: - PrintService/Admin; - System; - Anwendung; - Spooler-Absturzereignisse; - Treiberereignisse; - Netzwerkereignisse; - Protokolle des Druckservers; - Weboberfläche und Ereignisprotokoll des Druckers. --- **44. CUPS unter Linux und macOS prüfen** Druckerstatus: ```bash lpstat -t ``` Standarddrucker: ```bash lpstat -d ``` Warteschlange: ```bash lpq ``` Druckaufträge: ```bash lpstat -o ``` Auftrag abbrechen: ```bash cancel ``` Alle Aufträge eines Druckers abbrechen: ```bash cancel -a ``` CUPS-Dienst unter systemd: ```bash systemctl status cups ``` Protokoll: ```bash journalctl -u cups ``` Je nach System können die CUPS-Protokolle zusätzlich unter folgendem Pfad liegen: ```text /var/log/cups/ ``` Zu prüfen sind: - CUPS-Dienst; - Queue-Zustand; - deaktivierte oder angehaltene Queue; - Geräte-URI; - Treiber beziehungsweise PPD; - Filterfehler; - Berechtigungen; - Erreichbarkeit des Druckers; - IPP-, LPR- oder RAW-Verbindung; - vollständiger CUPS-Fehlertext. --- **45. Typische Fehlerbilder** | Symptom | Mögliche Ursache | Nächster Test | |---|---|---| | Servername nicht erreichbar | DNS oder Netzwerk | `Resolve-DnsName`, `Test-NetConnection` | | IP funktioniert, Name nicht | DNS, Alias oder SPN | Kurzname, FQDN und DNS-Einträge vergleichen | | TCP 445 nicht erreichbar | Firewall, Routing oder SMB-Dienst | Porttest und Serverstatus | | Freigabe nicht gefunden | falscher Name oder Freigabe fehlt | `Get-SmbShare`, `net share` | | Freigabe öffnet sich, Unterordner nicht | NTFS-Rechte oder ABE | ACL und effektiven Zugriff prüfen | | Datei lesbar, aber nicht änderbar | fehlendes Schreib- oder Änderungsrecht | Share- und NTFS-Rechte | | Datei änderbar, aber nicht löschbar | Löschrecht oder Eltern-ACL | Datei- und Ordner-ACL prüfen | | Zugriff lokal möglich, über SMB nicht | Freigaberecht oder SMB-Pfad | `Get-SmbShareAccess` | | neuer Gruppeneintrag wirkt nicht | altes Anmeldetoken | `whoami /groups`, erneute Anmeldung | | Zugriff verweigert trotz Gruppenmitgliedschaft | Verweigerung, falsches Token oder NTFS-Recht | effektiven Zugriff prüfen | | Datei angeblich in Verwendung | offenes Handle oder Anwendungssperre | `Get-SmbOpenFile` | | Zugriff über Alias schlägt fehl | SPN oder Kerberos | `klist`, `setspn -Q` | | DFS-Pfad zeigt alte Daten | falsches Ziel oder DFS-R-Störung | `dfsutil /pktinfo`, DFS-R-Ereignisse | | Dateien unterscheiden sich je nach Client | unterschiedliche DFS-Ziele | Zielserver und Replikation vergleichen | | Speichern schlägt ab bestimmter Größe fehl | Quota oder freier Speicher | Volume und FSRM prüfen | | Drucker für alle Benutzer offline | Netzwerk, Port oder Gerät | Porttest und Druckerstatus | | nur ein Benutzer kann nicht drucken | Berechtigung oder Benutzerprofil | Druckerrechte und Vergleichsbenutzer | | nur eine Anwendung druckt nicht | Anwendung oder Dokument | Windows-Testseite | | alle Drucker eines Servers betroffen | Spooler oder Druckserver | Dienst und Ereignisse | | nur eine Queue betroffen | Auftrag, Treiber oder Port | Queue, Treiber und Port | | Auftrag bleibt in Warteschlange | Spooler, Treiber oder Port | PrintService-Protokoll | | Auftrag verschwindet, kein Ausdruck | Protokoll, Gerät oder Druckersprache | Druckerprotokoll und Port | | Drucker fälschlich offline | SNMP-Statusabfrage | SNMP-Konfiguration prüfen | | Spooler stürzt wiederholt ab | Treiber oder Print Processor | Ereignisse und Treiberzuordnung | --- **46. Vorgehensweise bei „Zugriff verweigert“** 1. vollständigen UNC-Pfad dokumentieren. 2. Benutzer und Client bestimmen. 3. konkrete fehlgeschlagene Aktion erfassen. 4. verwendetes Konto mit `whoami` prüfen. 5. aktuelle Gruppen mit `whoami /groups` prüfen. 6. Servername und Zieladresse prüfen. 7. SMB-Verbindung und verwendete Anmeldedaten prüfen. 8. Freigabeberechtigungen auslesen. 9. NTFS-Berechtigungen des betroffenen Objekts prüfen. 10. Vererbung und Eigentümer berücksichtigen. 11. Berechtigungen des übergeordneten Ordners prüfen. 12. explizite Verweigerungen untersuchen. 13. Test mit einem funktionierenden Benutzer durchführen. 14. genau eine kontrollierte Korrektur umsetzen. 15. Zugriff mit der ursprünglichen Aktion erneut testen. 16. Rechte nach dem Minimalprinzip dokumentieren. --- **47. Vorgehensweise bei „Datei ist gesperrt“** 1. Dateiname und vollständigen Pfad erfassen. 2. Benutzer, Client und Anwendung bestimmen. 3. prüfen, ob Lesen oder nur Bearbeiten fehlschlägt. 4. `Get-SmbOpenFile` auf dem Dateiserver auswerten. 5. Anwendungssperrdateien berücksichtigen. 6. Serverprozesse mit Handle oder Process Explorer prüfen. 7. Virenscanner, Backup und Synchronisation berücksichtigen. 8. Rechte zum Ändern und Löschen prüfen. 9. Benutzer kontaktieren, der die Datei geöffnet hält. 10. ungespeicherte Daten ausschließen. 11. erst danach gezielt das Handle oder die Sitzung schließen. 12. Datei erneut öffnen, ändern und speichern. 13. Ursache und Auswirkung dokumentieren. --- **48. Vorgehensweise bei DFS-Problemen** 1. logischen DFS-Pfad dokumentieren. 2. Client und Benutzer bestimmen. 3. DFS-Referral des Clients prüfen. 4. tatsächlichen Zielserver dokumentieren. 5. Zielserver per DNS und TCP 445 prüfen. 6. direkten UNC-Pfad zum Zielserver testen. 7. Namespace-Ordner und Ziele prüfen. 8. AD-Site und Zielpriorität berücksichtigen. 9. Rechte auf allen Zielen vergleichen. 10. Dateistände und Zeitstempel vergleichen. 11. DFS-R-Ereignisse prüfen. 12. Replikationsrichtung und Backlog untersuchen. 13. nur die nachgewiesene Ursache korrigieren. 14. Clientzugriff und Replikation erneut prüfen. --- **49. Vorgehensweise bei Druckproblemen** 1. Drucker, Queue, Server und Port dokumentieren. 2. genaue Meldung und Zeitpunkt erfassen. 3. Umfang bestimmen: ein Benutzer, Client, Drucker oder alle. 4. Warteschlange und Auftragsstatus prüfen. 5. Windows-Testseite auslösen. 6. Spoolerstatus prüfen. 7. PrintService-Ereignisse auswerten. 8. Druckername und IP-Adresse prüfen. 9. tatsächlichen Druckerport testen. 10. SNMP-Status kontrollieren. 11. Treibername und Version prüfen. 12. Berechtigungen der Queue prüfen. 13. Gerätestatus und Verbrauchsmaterial prüfen. 14. genau eine kontrollierte Maßnahme durchführen. 15. Testseite und ursprüngliches Dokument erneut drucken. 16. Ereignisse und Queue nachkontrollieren. --- **50. Maßnahmen und Rückwege** **Ursache: falsche Freigabeberechtigung** Nachweis: - SMB-Verbindung funktioniert; - Freigabe existiert; - `Get-SmbShareAccess` zeigt kein ausreichendes Recht; - NTFS-Berechtigung wäre ausreichend. Maßnahme: - vorgesehene Sicherheitsgruppe mit minimal erforderlichem Freigaberecht eintragen. Rollback: - ursprüngliche Freigabe-ACL dokumentiert wiederherstellen. Verifikation: - Verbindung neu testen; - konkrete Dateiaktion ausführen; - Freigabe- und NTFS-Rechte erneut kontrollieren. --- **Ursache: fehlende NTFS-Berechtigung** Nachweis: - Freigaberecht ist ausreichend; - effektiver NTFS-Zugriff zeigt das fehlende Einzelrecht; - Fehler tritt am konkreten Ordner oder Objekt auf. Maßnahme: - Berechtigung über die vorgesehene Sicherheitsgruppe und passende Vererbung korrigieren. Rollback: - vorherige ACL sichern und bei Bedarf wiederherstellen. Verifikation: - Lesen, Erstellen, Ändern und Löschen entsprechend dem Sollzustand einzeln testen. --- **Ursache: altes Anmeldetoken** Nachweis: - AD-Gruppenmitgliedschaft ist vorhanden; - `whoami /groups` enthält die Gruppe noch nicht; - Berechtigungen der Gruppe sind korrekt. Maßnahme: - Benutzer kontrolliert ab- und erneut anmelden. Rollback: - nicht erforderlich, wenn keine Konfiguration verändert wurde. Verifikation: - `whoami /groups`; - Zugriff auf die vorgesehene Ressource; - keine zusätzlichen Rechte vergeben. --- **Ursache: falsches DFS-Ziel** Nachweis: - Client-Referral zeigt auf unerwarteten Server; - direkter Zugriff auf das vorgesehene Ziel funktioniert; - Namespace-Konfiguration oder Zielstatus ist fehlerhaft. Maßnahme: - Zielstatus, Priorität oder Namespace-Zuordnung nach dokumentiertem Sollzustand korrigieren. Rollback: - ursprüngliche DFS-Konfiguration dokumentiert wiederherstellen. Verifikation: - Referral erneut prüfen; - DFS-Pfad öffnen; - Dateistand und Rechte kontrollieren. --- **Ursache: fehlerhafter Druckerport** Nachweis: - Queue und Spooler funktionieren; - Port zeigt auf eine alte oder falsche Adresse; - vorgesehener Drucker ist unter der richtigen Adresse erreichbar. Maßnahme: - Queue kontrolliert auf den korrekten Port umstellen. Rollback: - ursprünglichen Port und seine Einstellungen dokumentieren. Verifikation: - Windows-Testseite; - ursprüngliches Dokument; - Queue- und Druckerstatus; - PrintService-Ereignisse. --- **51. Nachkontrolle** Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen: - vorgesehener Servername wird korrekt aufgelöst; - TCP 445 ist erreichbar; - SMB-Verbindung verwendet das vorgesehene Konto; - SMB-Dialekt und Sicherheitsanforderungen sind plausibel; - Freigabe zeigt auf den richtigen Pfad; - Freigabeberechtigungen entsprechen dem Sollzustand; - NTFS-Berechtigungen entsprechen dem Minimalprinzip; - Vererbung funktioniert wie vorgesehen; - aktuelles Token enthält die benötigten Gruppen; - Lesen, Erstellen, Ändern und Löschen wurden getrennt getestet; - keine unerwünschten zusätzlichen Rechte wurden vergeben; - keine wichtigen Dateien oder Sitzungen wurden getrennt; - DFS verweist auf das vorgesehene Ziel; - replizierte Daten sind konsistent; - ausreichend Speicherplatz ist vorhanden; - Quotas sind plausibel; - Druckwarteschlange verarbeitet neue Aufträge; - Druckerport zeigt auf das richtige Gerät; - Treiber und Spooler arbeiten stabil; - praktische Benutzerfunktion wurde getestet; - temporäre Diagnoseänderungen wurden zurückgenommen; - Ursache, Maßnahme, Rückweg und Ergebnis wurden dokumentiert. --- **52. Dokumentationsbeispiel** ```text Symptom: Der Benutzer konnte Dateien in der Freigabe lesen, aber keine neue Datei im Unterordner „Projekte“ erstellen. Zeitpunkt: 02.08.2026, 11:26 Uhr MESZ Benutzer: max.mustermann Client: CLIENT-17 Pfad: \\fileserver01.ad.example.local\Daten\Projekte Nachweis: DNS-Auflösung und TCP 445 waren erfolgreich. Die SMB-Verbindung verwendete das vorgesehene Domänenkonto. Die Freigabeberechtigung gewährte der zuständigen Gruppe „Ändern“. Die NTFS-Auswertung zeigte jedoch nur Leserechte auf dem Unterordner. Die Vererbung war an diesem Unterordner deaktiviert worden. Ursache: Bei einer früheren manuellen ACL-Änderung wurde die Vererbung auf dem Unterordner unterbrochen. Dadurch fehlte der vorgesehenen Gruppe das Änderungsrecht. Maßnahme: Nach Sicherung der bestehenden ACL wurde die freigegebene Berechtigungsstruktur des übergeordneten Ordners wiederhergestellt. Rollback: Die zuvor exportierte ACL kann wieder eingespielt werden. Verifikation: Der Benutzer kann Dateien lesen, erstellen, ändern und löschen. Er kann keine Berechtigungen verändern. Andere Abteilungsordner bleiben weiterhin unzugänglich. Es wurden keine zusätzlichen administrativen Rechte vergeben. Prävention: Berechtigungsänderungen erfolgen künftig ausschließlich über dokumentierte Sicherheitsgruppen und werden durch einen Test des effektiven Zugriffs geprüft. ``` --- **53. Entscheidungsbaum** ```text Datei- oder Freigabezugriff gestört ↓ Wird der richtige Servername aufgelöst? ├── Nein │ ↓ │ DNS, Alias und DFS-Namen prüfen │ └── Ja ↓ Ist TCP 445 erreichbar? ├── Nein │ ↓ │ Routing, Firewall und SMB-Dienst prüfen │ └── Ja ↓ Existiert die Freigabe und zeigt sie auf den richtigen Pfad? ├── Nein │ ↓ │ Freigabe- und Serverkonfiguration prüfen │ └── Ja ↓ Wird das vorgesehene Benutzerkonto verwendet? ├── Nein │ ↓ │ bestehende Verbindungen und Anmeldedaten prüfen │ └── Ja ↓ Sind Freigabeberechtigungen ausreichend? ├── Nein │ ↓ │ Freigabe-ACL kontrolliert korrigieren │ └── Ja ↓ Sind NTFS-Berechtigungen ausreichend? ├── Nein │ ↓ │ ACL, Vererbung, Gruppen und Token prüfen │ └── Ja ↓ Ist nur eine Datei oder Aktion betroffen? ├── Ja │ ↓ │ Sperre, Einzel-ACL, Pfad, Quota und Anwendung prüfen │ └── Nein ↓ DFS, Storage, Serverzustand und zentrale Abhängigkeiten prüfen ``` --- **54. Typische Prüfungsfragen** **Warum reicht ein erfolgreicher Ping zum Dateiserver nicht als Funktionsnachweis?**
Antwort anzeigen Ein Ping prüft eine bestimmte ICMP-Kommunikation. Er beweist weder die Erreichbarkeit von TCP 445 noch eine erfolgreiche SMB-Authentifizierung oder ausreichende Freigabe- und NTFS-Berechtigungen.
**Welche Berechtigungen wirken bei einem SMB-Zugriff auf einen NTFS-Ordner?**
Antwort anzeigen Es wirken sowohl die Freigabe- als auch die NTFS-Berechtigungen. Für den Zugriff über das Netzwerk ergibt sich die wirksame Berechtigung aus der restriktiveren Kombination beider Ebenen.
**Warum kann der lokale Zugriff auf einen Serverordner funktionieren, während der SMB-Zugriff fehlschlägt?**
Antwort anzeigen Beim lokalen Zugriff werden keine SMB-Freigabeberechtigungen ausgewertet. Über das Netzwerk wirken zusätzlich zu den NTFS-Rechten auch die Freigabeberechtigungen und die SMB-Authentifizierung.
**Warum kann eine neue Gruppenmitgliedschaft noch nicht wirksam sein?**
Antwort anzeigen Die Gruppe kann bereits im Active Directory eingetragen sein, aber im aktuellen Anmeldetoken fehlen. Häufig ist eine erneute Benutzeranmeldung erforderlich, damit ein neues Token erzeugt wird.
**Worin unterscheiden sich DFS Namespace und DFS Replication?**
Antwort anzeigen DFS Namespace stellt einen einheitlichen logischen Zugriffspfad bereit. DFS Replication synchronisiert Ordnerinhalte zwischen mehreren Servern. Beide Funktionen können unabhängig voneinander gestört sein.
**Warum sollte eine geöffnete SMB-Datei nicht sofort zwangsweise geschlossen werden?**
Antwort anzeigen Die zugehörige Anwendung kann noch nicht gespeicherte Änderungen besitzen. Ein erzwungenes Schließen kann Datenverlust oder beschädigte Anwendungszustände verursachen.
**Warum beweist ein erfolgreicher Zugriff über einen Alias nicht automatisch die Verwendung von Kerberos?**
Antwort anzeigen Fehlt ein passender CIFS-SPN für den Alias, kann der Zugriff abhängig von der Umgebung über NTLM erfolgen. Tickets und SPN-Zuordnung müssen gesondert geprüft werden.
**Welche Funktion besitzt der Print Spooler?**
Antwort anzeigen Der Print Spooler nimmt Druckaufträge entgegen, verarbeitet beziehungsweise zwischenspeichert sie und übergibt sie über die konfigurierte Warteschlange und den Druckerport an das Ziel.
**Warum kann ein Drucker fälschlich als offline angezeigt werden?**
Antwort anzeigen Die eigentliche Druckverbindung kann funktionieren, während die SNMP-Statusabfrage fehlschlägt. Ursachen können eine falsche Community, blockiertes UDP 161 oder eine fehlerhafte SNMP-Konfiguration sein.
--- **55. Prüfungsfallen** - erfolgreichen Ping mit funktionierendem SMB gleichsetzen; - nur die IP-Adresse, aber nicht den verwendeten Namen prüfen; - verbundenes Laufwerk prüfen, ohne den UNC-Pfad zu bestimmen; - Freigabe- und NTFS-Berechtigungen verwechseln; - nur die ACL der Freigabeebene prüfen; - nur die ACL des übergeordneten Ordners prüfen; - Vererbung und Einzelrechte nicht berücksichtigen; - Lesen, Schreiben, Ändern und Löschen gleichsetzen; - Gruppenmitgliedschaft im AD mit aktuellem Token gleichsetzen; - Benutzer direkt statt über Sicherheitsgruppen berechtigen; - Benutzer zur Fehlerbehebung in eine Administratorgruppe aufnehmen; - pauschal Vollzugriff gewähren; - Verweigerung ungeprüft entfernen; - ACLs rekursiv ersetzen, ohne Rückweg festzulegen; - Eigentümer übernehmen, ohne die ursprüngliche ACL zu sichern; - alte oder unbekannte SID ungeprüft löschen; - alle SMB-Verbindungen pauschal trennen; - Datei-Handle schließen, ohne ungespeicherte Daten auszuschließen; - SMB 1 als schnelle Kompatibilitätslösung aktivieren; - erfolgreichen Zugriff mit Kerberos-Authentifizierung gleichsetzen; - DNS-Alias ohne CIFS-SPN verwenden; - DFS-Namespace und DFS-Replikation verwechseln; - DFS-Cache leeren, bevor das verwendete Ziel dokumentiert wurde; - Replikation ungeprüft erzwingen; - Offlinecache zurücksetzen, ohne nicht synchronisierte Daten zu prüfen; - nur freien Speicherplatz, aber keine Quota prüfen; - Druckwarteschlange vollständig leeren, obwohl nur ein Auftrag betroffen ist; - Spooler sofort neu starten, ohne Ereignisse und Queue zu sichern; - Treiber auf einem produktiven Druckserver ungeprüft ersetzen; - SNMP dauerhaft deaktivieren, ohne die eigentliche Ursache zu prüfen; - Drucker per IP neu installieren, obwohl nur DNS oder Port falsch ist; - mehrere Änderungen gleichzeitig durchführen; - nur eine Testseite, aber nicht die ursprüngliche Benutzerfunktion prüfen. --- **56. Checkliste** - [ ] vollständiger UNC-Pfad wurde dokumentiert. - [ ] betroffener Benutzer wurde bestimmt. - [ ] betroffener Client wurde bestimmt. - [ ] genaue fehlgeschlagene Aktion wurde erfasst. - [ ] Fehlertext und Fehlercode wurden dokumentiert. - [ ] Zeitpunkt und Zeitzone wurden erfasst. - [ ] Servername wurde aufgelöst. - [ ] Ziel-IP wurde mit dem Sollzustand verglichen. - [ ] Kurzname, FQDN und Alias wurden unterschieden. - [ ] TCP 445 wurde geprüft. - [ ] tatsächliche SMB-Verbindung wurde geprüft. - [ ] verwendetes Benutzerkonto wurde geprüft. - [ ] bestehende Verbindungen wurden berücksichtigt. - [ ] gespeicherte Anmeldedaten wurden berücksichtigt. - [ ] Freigabe und lokaler Zielpfad wurden geprüft. - [ ] Freigabeberechtigungen wurden geprüft. - [ ] NTFS-Berechtigungen wurden geprüft. - [ ] Vererbung wurde geprüft. - [ ] Eigentümer wurde geprüft. - [ ] explizite Verweigerungen wurden geprüft. - [ ] Rechte des übergeordneten Ordners wurden berücksichtigt. - [ ] AD-Gruppenmitgliedschaften wurden geprüft. - [ ] aktuelles Anmeldetoken wurde geprüft. - [ ] effektiver Zugriff wurde bewertet. - [ ] Lesen, Erstellen, Ändern und Löschen wurden getrennt getestet. - [ ] Access-Based Enumeration wurde bei unsichtbaren Ordnern berücksichtigt. - [ ] geöffnete SMB-Dateien wurden geprüft. - [ ] Anwendungssperren wurden berücksichtigt. - [ ] SMB-Dialekt wurde geprüft. - [ ] Signierung und Verschlüsselung wurden berücksichtigt. - [ ] Kerberos und NTLM wurden unterschieden. - [ ] CIFS-SPN wurde bei Aliasproblemen geprüft. - [ ] DFS-Referral wurde bei DFS-Pfaden geprüft. - [ ] tatsächlicher DFS-Zielserver wurde bestimmt. - [ ] DFS-Replikation wurde bei abweichenden Datenständen geprüft. - [ ] Offline Files wurden berücksichtigt. - [ ] freier Speicherplatz wurde geprüft. - [ ] Quotas wurden geprüft. - [ ] Pfadlänge und Dateiname wurden berücksichtigt. - [ ] SMB- und Systemereignisse wurden geprüft. - [ ] Drucker, Queue, Server und Port wurden dokumentiert. - [ ] Spoolerstatus wurde geprüft. - [ ] Druckaufträge wurden geprüft. - [ ] Druckerport und Zieladresse wurden geprüft. - [ ] SNMP-Status wurde geprüft. - [ ] Treibername und Version wurden geprüft. - [ ] PrintService-Protokolle wurden geprüft. - [ ] Windows-Testseite wurde verwendet. - [ ] ursprüngliche Benutzerfunktion wurde erneut getestet. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde festgelegt. - [ ] keine unnötigen Rechte wurden vergeben. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. --- **57. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Servername zeigt auf falsche IP | `Resolve-DnsName`, `nslookup` | | SMB-Port nicht erreichbar | `Test-NetConnection -Port 445` | | bestehende Netzlaufwerke unklar | `net use`, `Get-SmbMapping` | | verwendetes SMB-Konto unklar | `Get-SmbConnection` | | Freigabe fehlt | `Get-SmbShare`, `net share` | | Freigaberecht unklar | `Get-SmbShareAccess` | | NTFS-Recht unklar | `Get-Acl`, `icacls` | | aktuelle Gruppen unklar | `whoami /groups` | | Datei gesperrt | `Get-SmbOpenFile`, Handle | | SMB-Sitzung unklar | `Get-SmbSession` | | SMB-Version unklar | `Get-SmbConnection` | | Alias funktioniert nicht | `klist`, `setspn -Q` | | DFS-Ziel unklar | `dfsutil /pktinfo` | | DFS-Konfiguration unklar | `Get-DfsnFolderTarget` | | DFS-R-Störung | DFS-Replication-Protokoll | | Speicherplatz unklar | `Get-Volume`, `Get-PSDrive` | | Quota vermutet | `Get-FsrmQuota` | | Druckerstatus unklar | `Get-Printer` | | Druckaufträge hängen | `Get-PrintJob` | | Spoolerstatus unklar | `Get-Service Spooler` | | Druckerport unklar | `Get-PrinterPort` | | Treiber unklar | `Get-PrinterDriver` | | Druckereignis gesucht | PrintService/Operational | | CUPS-Status unklar | `lpstat -t`, `journalctl -u cups` | --- **Merksatz** > Bei Datei- und Freigabefehlern wird vom Namen über TCP 445, SMB-Sitzung und Authentifizierung bis zu Freigabe- und NTFS-Rechten geprüft. Bei Druckfehlern wird der Weg von Anwendung und Treiber über Queue, Spooler und Port bis zum physischen Drucker verfolgt. Rechte, Sitzungen, Dateien und Druckaufträge werden erst verändert, wenn Ursache, Auswirkung und Rückweg geklärt sind. --- **Quellen und weiterführende Dokumentation** **Offizielle Microsoft-Dokumentation** - [Microsoft Learn – SMB troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/smb-file-server-share-troubleshooting) - [Microsoft Learn – Get-SmbConnection](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbconnection) - [Microsoft Learn – Get-SmbShare](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbshare) - [Microsoft Learn – Get-SmbShareAccess](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbshareaccess) - [Microsoft Learn – Get-SmbSession](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbsession) - [Microsoft Learn – Get-SmbOpenFile](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbopenfile) - [Microsoft Learn – Get-SmbServerConfiguration](https://learn.microsoft.com/en-us/powershell/module/smbshare/get-smbserverconfiguration) - [Microsoft Learn – Get-Acl](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-acl) - [Microsoft Learn – Icacls](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/icacls) - [Microsoft Learn – File and folder permissions](https://learn.microsoft.com/en-us/windows-server/storage/file-server/enable-access-based-enumeration) - [Microsoft Learn – DFS Namespaces overview](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview) - [Microsoft Learn – DFS Replication overview](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/dfsr-overview) - [Microsoft Learn – DFSR troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dfsr-overview) - [Microsoft Learn – Get-DfsnFolderTarget](https://learn.microsoft.com/en-us/powershell/module/dfsn/get-dfsnfoldertarget) - [Microsoft Learn – Get-DfsReplicationGroup](https://learn.microsoft.com/en-us/powershell/module/dfsr/get-dfsreplicationgroup) - [Microsoft Learn – Get-Printer](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printer) - [Microsoft Learn – Get-PrintJob](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printjob) - [Microsoft Learn – Get-PrinterPort](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printerport) - [Microsoft Learn – Get-PrinterDriver](https://learn.microsoft.com/en-us/powershell/module/printmanagement/get-printerdriver) - [Microsoft Learn – Windows print troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/printing/welcome-to-troubleshooting-windows-printing) **Offizielle CUPS-Dokumentation** - [OpenPrinting – CUPS Command-Line Printing](https://openprinting.github.io/cups/doc/options.html) - [OpenPrinting – CUPS Administration](https://openprinting.github.io/cups/doc/admin.html) - [OpenPrinting – CUPS Documentation](https://openprinting.github.io/cups/) # 8.4 Linux-Server – Dienste, Prozesse, Protokolle, Ressourcen und Speicher --- **1. Ziel dieser Seite** Diese Seite beschreibt die strukturierte Fehleranalyse auf Linux-Servern. Typische Störungen betreffen: - systemd-Dienste; - Prozesse; - Konfigurationsdateien; - Benutzer und Berechtigungen; - SELinux oder AppArmor; - Netzwerk und Ports; - DNS und Namensauflösung; - CPU, RAM und Swap; - Datenträger und Dateisysteme; - Inodes; - Mounts; - LVM und Software-RAID; - Paketverwaltung; - Cronjobs und systemd-Timer; - Kernel, Treiber und Hardware; - Bootvorgang; - Zeit- und Zertifikatsprobleme. Das Ziel ist nicht, einen Dienst möglichst schnell neu zu starten. Zuerst werden Fehlerzustand, Ursache, Auswirkungen und Rückweg dokumentiert. --- **2. Diagnosegrundsatz** ```text Symptom erfassen ↓ Umfang bestimmen ↓ Systemzustand und Zeitpunkt prüfen ↓ Dienst, Prozess und Port untersuchen ↓ Protokolle auswerten ↓ Abhängigkeiten prüfen ↓ Konfiguration und Berechtigungen prüfen ↓ Ressourcen und Storage prüfen ↓ Ursache nachweisen ↓ Eine kontrollierte Maßnahme durchführen ↓ Funktion und Nebenwirkungen kontrollieren ``` Ein erfolgreicher Prozessstart beweist noch keine funktionierende Anwendung. Ebenso beweist ein offener Port nicht, dass die Anwendung korrekte Antworten liefert. --- **3. Fehlerbild exakt erfassen** Zu dokumentieren sind: - Hostname; - Distribution; - Betriebssystemversion; - Kernelversion; - Architektur; - betroffener Dienst; - betroffene Anwendung; - vollständiger Fehlertext; - Fehlercode; - Zeitpunkt mit Zeitzone; - betroffener Benutzer; - Quell- und Zielsystem; - Port und Protokoll; - betroffene Funktion; - Umfang der Störung; - letzte funktionierende Nutzung; - letzte Änderungen; - installierte Updates; - Neustarts; - Ressourcenstatus; - bisherige Diagnose- und Änderungsversuche. Wichtige Abgrenzungsfragen: - Ist nur ein Benutzer betroffen? - Ist nur ein Client betroffen? - Ist nur eine Anwendung betroffen? - Ist nur eine Instanz betroffen? - Betrifft es einen oder mehrere Server? - Funktioniert der Dienst lokal? - Funktioniert der Dienst über das Netzwerk? - Ist nur IPv4 oder IPv6 betroffen? - Tritt der Fehler dauerhaft oder sporadisch auf? - Begann der Fehler nach einer Änderung? - Funktioniert die Anwendung, obwohl der Dienststatus einen Fehler meldet? --- **4. System identifizieren** Hostname: ```bash hostnamectl ``` Kurzer Hostname: ```bash hostname ``` Betriebssysteminformationen: ```bash cat /etc/os-release ``` Kernelversion und Architektur: ```bash uname -a ``` Nur Kernelversion: ```bash uname -r ``` Architektur: ```bash uname -m ``` Systemlaufzeit und Last: ```bash uptime ``` Letzter Systemstart: ```bash who -b ``` Aktuelle Zeit und Zeitzone: ```bash timedatectl ``` Diese Informationen sind wichtig, weil Befehle, Dateipfade, Paketmanager, Sicherheitsmodule und Protokollierung je nach Distribution und Version unterschiedlich sein können. --- **5. Letzte Änderungen bestimmen** Mögliche Ursachen kurz vor Beginn einer Störung: - Paketupdate; - Kernelupdate; - Konfigurationsänderung; - Zertifikatsaustausch; - Änderung von Benutzer oder Gruppe; - Änderung von Dateirechten; - Firewalländerung; - DNS-Änderung; - neue Mount-Konfiguration; - Storage-Erweiterung; - Neustart; - Deployment; - geänderte Umgebungsvariable; - neuer systemd-Drop-in; - geänderte SELinux- oder AppArmor-Regel; - abgelaufenes Kennwort oder Zertifikat. Anmeldehistorie: ```bash last ``` Fehlgeschlagene Anmeldungen, sofern unterstützt und berechtigt: ```bash lastb ``` Letzte Neustarts: ```bash last reboot ``` Zeitstempel einer Datei: ```bash stat /etc/example/application.conf ``` RPM-basierte Systeme: ```bash dnf history ``` Debian- und Ubuntu-Systeme: ```bash grep -E ' install | upgrade | remove ' /var/log/dpkg.log ``` Rotierte Protokolle müssen gegebenenfalls zusätzlich geprüft werden. --- **6. systemd-Gesamtzustand prüfen** Fehlgeschlagene Units: ```bash systemctl --failed ``` Systemzustand: ```bash systemctl is-system-running ``` Alle geladenen Dienste: ```bash systemctl list-units --type=service --all ``` Installierte Unit-Dateien: ```bash systemctl list-unit-files --type=service ``` Abweichende oder lokal angepasste Units: ```bash systemd-delta ``` Ein System kann als `degraded` angezeigt werden, obwohl die vom Benutzer benötigte Anwendung funktioniert. Deshalb müssen die fehlgeschlagenen Units einzeln bewertet werden. --- **7. Dienststatus untersuchen** Beispieldienst: ```bash systemctl status example.service ``` Aktivitätsstatus: ```bash systemctl is-active example.service ``` Autostartstatus: ```bash systemctl is-enabled example.service ``` Fehlerzustand: ```bash systemctl is-failed example.service ``` Ausgewählte Eigenschaften: ```bash systemctl show example.service \ -p ActiveState \ -p SubState \ -p Result \ -p ExecMainCode \ -p ExecMainStatus \ -p MainPID \ -p User \ -p Group \ -p FragmentPath ``` Zu unterscheiden sind: - `loaded`: Unit-Datei wurde geladen; - `active`: Unit ist aktiv; - `inactive`: Unit ist nicht aktiv; - `failed`: vorheriger Start oder Betrieb endete fehlerhaft; - `enabled`: Unit ist für automatischen Start eingebunden; - `disabled`: kein automatischer Start über die übliche Aktivierung; - `masked`: Start wurde durch eine Verknüpfung auf `/dev/null` blockiert; - `static`: Unit besitzt normalerweise keinen eigenen Installationsabschnitt und wird durch andere Units gestartet; - `activating`: Startvorgang läuft; - `deactivating`: Beendigung läuft. `enabled` bedeutet nicht, dass der Dienst gerade läuft. `active` bedeutet nicht automatisch, dass er beim nächsten Systemstart wieder gestartet wird. --- **8. Dienstprotokoll mit journalctl prüfen** Aktuelles Dienstprotokoll: ```bash journalctl -u example.service ``` Nur aktueller Systemstart: ```bash journalctl -u example.service -b ``` Vorheriger Systemstart: ```bash journalctl -u example.service -b -1 ``` Letzte 100 Einträge: ```bash journalctl -u example.service -n 100 ``` Fortlaufende Anzeige: ```bash journalctl -u example.service -f ``` Bestimmter Zeitraum: ```bash journalctl -u example.service \ --since "2026-08-02 10:00:00" \ --until "2026-08-02 11:00:00" ``` Warnungen und schwerere Meldungen des aktuellen Starts: ```bash journalctl -b -p warning ``` Kernelmeldungen des aktuellen Starts: ```bash journalctl -k -b ``` Ausführliche Ausgabe: ```bash journalctl -u example.service -o verbose ``` Zu dokumentieren sind: - genauer Zeitpunkt; - Unit; - Prozess-ID; - Benutzer; - Fehlercode; - Signal; - erste relevante Fehlermeldung; - nachfolgende Kaskadenfehler; - wiederholte Startversuche; - betroffene Datei; - betroffene Adresse oder Portnummer. Die letzte Fehlermeldung muss nicht die eigentliche Ursache sein. Häufig steht die erste relevante Meldung weiter oben. --- **9. Klassische Protokolldateien** Je nach Distribution und Dienst können zusätzlich relevant sein: ```text /var/log/syslog /var/log/messages /var/log/auth.log /var/log/secure /var/log/kern.log /var/log/audit/audit.log /var/log/dmesg /var/log/cron /var/log/maillog ``` Anwendungsprotokolle befinden sich häufig unter: ```text /var/log// ``` Letzte Zeilen anzeigen: ```bash tail -n 100 /var/log/syslog ``` Fortlaufend beobachten: ```bash tail -f /var/log/example/application.log ``` Komprimierte rotierte Protokolle durchsuchen: ```bash zgrep -i 'error' /var/log/example/application.log*.gz ``` Nicht jede Distribution verwendet alle genannten Dateien. Auf ausschließlich journalbasierten Systemen können einzelne klassische Protokolldateien fehlen. --- **10. Unit-Datei und Überschreibungen prüfen** Wirksame Unit einschließlich Drop-ins anzeigen: ```bash systemctl cat example.service ``` Pfad und Drop-ins: ```bash systemctl show example.service \ -p FragmentPath \ -p DropInPaths ``` Abhängigkeiten: ```bash systemctl list-dependencies example.service ``` Umgekehrte Abhängigkeiten: ```bash systemctl list-dependencies --reverse example.service ``` Startreihenfolge und Abhängigkeiten können beeinflusst werden durch: - `Requires=`; - `Wants=`; - `After=`; - `Before=`; - `BindsTo=`; - `Condition...=`; - `Assert...=`; - Socket-Aktivierung; - Mount-Abhängigkeiten; - Netzwerk-Targets; - Drop-in-Dateien; - Environment-Dateien. `After=` legt eine Reihenfolge fest, erzeugt allein aber keine Startabhängigkeit. --- **11. systemd-Konfiguration verifizieren** Unit-Dateien prüfen: ```bash systemd-analyze verify example.service ``` Nach einer Änderung an Unit-Dateien: ```bash systemctl daemon-reload ``` `daemon-reload` lädt die systemd-Konfiguration neu. Es startet den betroffenen Dienst nicht automatisch neu. Vor einem Neustart des Dienstes sind zu prüfen: - wurde nur die Unit-Datei oder auch die Anwendungskonfiguration geändert; - besitzt die Anwendung einen eigenen Syntaxprüfer; - verarbeitet der Dienst produktive Verbindungen; - gehen Sitzungen oder Daten verloren; - existiert ein Wartungsfenster; - ist ein Rückweg vorbereitet. --- **12. Anwendungsidentität prüfen** Der Dienst kann unter einem anderen Benutzer laufen als erwartet. systemd-Konfiguration: ```bash systemctl show example.service \ -p User \ -p Group \ -p SupplementaryGroups \ -p DynamicUser ``` Prozessbenutzer: ```bash ps -eo user,group,pid,ppid,stat,lstart,cmd ``` Bestimmter Prozess: ```bash ps -o user,group,pid,ppid,stat,lstart,cmd -p ``` Benutzerinformationen: ```bash id exampleuser ``` Gruppen eines Benutzers: ```bash id -nG exampleuser ``` Kontoeintrag: ```bash getent passwd exampleuser ``` Gruppeneintrag: ```bash getent group examplegroup ``` `getent` berücksichtigt die konfigurierte Namensdienstauflösung und ist deshalb bei LDAP-, Active-Directory- oder SSSD-Umgebungen häufig aussagekräftiger als das alleinige Lesen von `/etc/passwd`. --- **13. Prozesse untersuchen** Alle Prozesse: ```bash ps aux ``` Hierarchische Darstellung: ```bash ps -ef --forest ``` Prozesse eines Benutzers: ```bash ps -u exampleuser -f ``` Prozess anhand des Namens suchen: ```bash pgrep -a example ``` Prozessbaum: ```bash pstree -ap ``` Dynamische Anzeige: ```bash top ``` Falls installiert: ```bash htop ``` Zu prüfen sind: - Prozess vorhanden; - richtige ausführbare Datei; - richtiger Benutzer; - Elternprozess; - Startzeit; - CPU-Verbrauch; - Speicherverbrauch; - Prozesszustand; - Anzahl der Threads; - wiederholte Neustarts; - Zombie-Prozesse; - nicht unterbrechbarer Schlafzustand; - unerwartete Kommandozeilenparameter. --- **14. Prozesszustände bewerten** Wichtige Zustände in `ps`: | Zustand | Bedeutung | |---|---| | `R` | läuft oder ist ausführbar | | `S` | unterbrechbarer Schlafzustand | | `D` | nicht unterbrechbarer Schlafzustand, häufig I/O-bezogen | | `T` | angehalten oder verfolgt | | `Z` | Zombieprozess | | `I` | inaktiver Kernelthread | Ein Prozess im Zustand `D` kann häufig nicht sofort beendet werden, weil er auf eine Kernel- oder I/O-Operation wartet. Ein Zombie verbraucht normalerweise kaum Ressourcen. Er zeigt jedoch, dass der Elternprozess den Beendigungsstatus des Kindprozesses noch nicht abgeholt hat. --- **15. Signale und Prozessbeendigung** Normale Beendigungsanforderung: ```bash kill -TERM ``` Standardsignal von `kill`: ```bash kill ``` Erzwungene Beendigung: ```bash kill -KILL ``` Signale anzeigen: ```bash kill -l ``` `SIGTERM` erlaubt einem Prozess eine kontrollierte Beendigung. `SIGKILL` kann nicht abgefangen werden und verhindert eine geordnete Bereinigung. Vor einer Prozessbeendigung prüfen: - besitzt der Prozess ungespeicherte Daten; - hält er Datenbanktransaktionen; - verwaltet systemd den Prozess; - wird er automatisch neu gestartet; - existieren Kindprozesse; - ist der Prozess im Zustand `D`; - welcher Benutzer ist betroffen; - entstehen Ausfälle oder Inkonsistenzen. Ein von systemd verwalteter Prozess sollte normalerweise über die zuständige Unit und nicht ausschließlich über seine PID gesteuert werden. --- **16. Offene Dateien und Arbeitsverzeichnisse prüfen** Offene Dateien eines Prozesses: ```bash lsof -p ``` Prozesse mit Zugriff auf eine Datei: ```bash lsof /var/lib/example/data.db ``` Alternativ: ```bash fuser -v /var/lib/example/data.db ``` Prozesse auf einem Mountpoint: ```bash fuser -vm /mnt/data ``` Gelöschte, aber weiterhin geöffnete Dateien: ```bash lsof +L1 ``` Eine gelöschte Datei kann weiterhin Speicherplatz belegen, solange ein Prozess sie geöffnet hält. Der Speicher wird normalerweise erst nach dem Schließen des Deskriptors freigegeben. --- **17. Ausführbare Datei und Bibliotheken prüfen** Verwendete Binärdatei: ```bash readlink -f /proc//exe ``` Arbeitsverzeichnis: ```bash readlink -f /proc//cwd ``` Kommandozeile: ```bash tr '\0' ' ' < /proc//cmdline ``` Umgebungsvariablen, nur mit erforderlicher Berechtigung: ```bash tr '\0' '\n' < /proc//environ ``` Bibliotheksabhängigkeiten: ```bash ldd /usr/local/bin/example ``` `ldd` sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Je nach Datei und Implementierung kann dabei ein Sicherheitsrisiko entstehen. --- **18. Anwendungskonfiguration prüfen** Zu prüfen sind: - Pfad der tatsächlich geladenen Konfiguration; - Syntax; - Dateirechte; - Eigentümer; - Umgebungsvariablen; - Include-Dateien; - relative Pfade; - Zertifikate und Schlüssel; - Port und Bind-Adresse; - Datenbankverbindung; - DNS-Namen; - temporäre Verzeichnisse; - PID- und Socket-Dateien; - Abhängigkeiten; - Zeichencodierung; - Unterschiede zwischen Soll- und Ist-Konfiguration. Datei anzeigen: ```bash sed -n '1,200p' /etc/example/application.conf ``` Dateieigenschaften: ```bash stat /etc/example/application.conf ``` Viele Dienste besitzen einen eigenen Syntaxprüfer. Beispiele: ```bash sshd -t ``` ```bash nginx -t ``` ```bash apachectl configtest ``` Der passende Prüfbefehl muss zur tatsächlich installierten Anwendung und Version passen. --- **19. Dateirechte prüfen** Lange Darstellung: ```bash ls -la /var/lib/example ``` Numerische IDs: ```bash ls -lan /var/lib/example ``` Alle Bestandteile eines Pfades prüfen: ```bash namei -l /var/lib/example/data/file.db ``` Dateistatus: ```bash stat /var/lib/example/data/file.db ``` ACL anzeigen: ```bash getfacl /var/lib/example/data/file.db ``` Zu prüfen sind: - Eigentümer; - Gruppe; - klassische Modusbits; - ACL; - ACL-Maske; - Rechte aller übergeordneten Verzeichnisse; - Setuid; - Setgid; - Sticky Bit; - Dateisystem nur lesbar; - SELinux-Kontext; - AppArmor-Profil; - NFS-Einschränkungen; - Container- oder Namespace-Zuordnung. Für das Betreten eines Verzeichnisses wird das Ausführungsrecht benötigt. Ausreichende Rechte auf der Datei allein genügen nicht, wenn ein übergeordnetes Verzeichnis nicht durchlaufen werden darf. --- **20. Zugriff als Dienstbenutzer testen** Kontrollierter Lesetest: ```bash sudo -u exampleuser -- test -r /var/lib/example/data/file.db ``` Schreibbarkeit eines Verzeichnisses: ```bash sudo -u exampleuser -- test -w /var/lib/example/data ``` Pfadzugriff: ```bash sudo -u exampleuser -- namei -l /var/lib/example/data/file.db ``` Ein Test sollte möglichst dieselbe Identität, denselben Pfad und dieselbe Aktion wie die Anwendung verwenden. Keine produktiven Dateien ungeprüft verändern oder überschreiben. Für Schreibtests ist eine dafür vorgesehene Testdatei zu verwenden. --- **21. SELinux prüfen** Status: ```bash getenforce ``` Ausführlicher Status: ```bash sestatus ``` Dateikontext: ```bash ls -lZ /var/lib/example ``` Prozesskontext: ```bash ps -eZ ``` Aktuelle AVC-Meldungen: ```bash ausearch \ -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR \ -ts recent ``` Auswertung, sofern `setroubleshoot` installiert ist: ```bash sealert -a /var/log/audit/audit.log ``` Sollkontext eines Pfades prüfen: ```bash matchpathcon /var/lib/example/data ``` Kontext anhand der Richtlinie wiederherstellen: ```bash restorecon -Rv /var/lib/example ``` SELinux darf nicht pauschal deaktiviert werden, nur um eine Anwendung zum Laufen zu bringen. Eine Ablehnung weist häufig auf einen falschen Pfad, falsches Label, eine unpassende Dienstkonfiguration oder eine fehlende gezielte Richtlinie hin. Ein Wechsel in den permissiven Modus verändert den Sicherheitszustand des gesamten Systems und ist keine harmlose Standarddiagnose. --- **22. AppArmor prüfen** Status: ```bash aa-status ``` Kernel- und Auditmeldungen: ```bash journalctl -k | grep -i apparmor ``` Je nach System: ```bash grep -i apparmor /var/log/syslog ``` Mögliche Ursachen: - Anwendung verwendet einen neuen Pfad; - Profil erlaubt eine benötigte Datei nicht; - ausführbare Datei wurde verschoben; - Include-Regel fehlt; - Profil befindet sich im Enforce-Modus; - Anwendung startet einen nicht erlaubten Unterprozess; - Netzwerkzugriff ist eingeschränkt. Ein Profil sollte nicht ungeprüft deaktiviert werden. Zuerst sind Ablehnung, betroffener Pfad und notwendige Mindestberechtigung zu bestimmen. --- **23. Port und Socket prüfen** Lauschende TCP- und UDP-Sockets: ```bash ss -tulpn ``` Nur lauschende TCP-Sockets: ```bash ss -ltnp ``` Bestimmter Port: ```bash ss -ltnp 'sport = :443' ``` Bestehende TCP-Verbindungen: ```bash ss -tanp ``` Unix-Sockets: ```bash ss -lxnp ``` Zu unterscheiden sind: - kein Prozess lauscht; - Prozess lauscht nur auf `127.0.0.1`; - Prozess lauscht nur auf IPv6; - Prozess lauscht auf falscher Adresse; - anderer Prozess belegt den Port; - Socket-Aktivierung wird verwendet; - Firewall blockiert den Zugriff; - Anwendung lauscht, beantwortet Anfragen aber fehlerhaft. --- **24. Portkonflikt untersuchen** Belegung eines Ports: ```bash ss -ltnp 'sport = :8080' ``` Alternativ: ```bash lsof -nP -iTCP:8080 -sTCP:LISTEN ``` Mögliche Ursachen: - zweite Instanz wurde gestartet; - alter Prozess läuft noch; - Testdienst belegt den Produktionsport; - Container veröffentlicht denselben Hostport; - systemd-Socket besitzt den Port; - IPv4- und IPv6-Bindung kollidieren; - Konfiguration verwendet einen falschen Port. Ein Prozess darf nicht allein deshalb beendet werden, weil er den gewünschten Port belegt. Zuerst muss seine Funktion und Zuständigkeit geklärt werden. --- **25. Lokale Anwendungsfunktion prüfen** TCP-Verbindung: ```bash nc -vz 127.0.0.1 8080 ``` HTTP-Abfrage: ```bash curl -v http://127.0.0.1:8080/ ``` HTTPS einschließlich Zertifikatsprüfung: ```bash curl -v https://server.example.local/ ``` TLS-Verbindung untersuchen: ```bash openssl s_client \ -connect server.example.local:443 \ -servername server.example.local ``` Bewertung: | Ergebnis | Wahrscheinlicher Bereich | |---|---| | lokal kein Listener | Dienst, Konfiguration oder Startfehler | | lokal erreichbar, remote nicht | Firewall, Routing, Bind-Adresse oder Netzwerk | | TCP funktioniert, HTTP fehlerhaft | Anwendung, Reverse Proxy oder Backend | | HTTP über IP funktioniert, Name nicht | DNS, Virtual Host, SNI oder Zertifikat | | TLS schlägt fehl | Zertifikat, Schlüssel, Protokoll oder Cipher | | Antwort langsam | Anwendung, Backend, DNS, Storage oder Ressourcen | --- **26. Netzwerkkonfiguration prüfen** Adressen: ```bash ip address show ``` Kurzform: ```bash ip -br address ``` Links: ```bash ip -br link ``` Routingtabelle: ```bash ip route show ``` IPv6-Routen: ```bash ip -6 route show ``` Route zu einem konkreten Ziel: ```bash ip route get 192.0.2.20 ``` Nachbarn: ```bash ip neigh show ``` Netzwerkstatistik: ```bash ip -s link show ``` Zu prüfen sind: - Interface aktiv; - richtige IP-Adresse; - Präfix; - Default Gateway; - richtige Route; - Policy Routing; - VLAN; - Bond oder Bridge; - Paketfehler; - Drops; - MTU; - doppelte IP-Adresse; - IPv4- beziehungsweise IPv6-Auswahl. --- **27. Namensauflösung prüfen** Resolverkonfiguration: ```bash cat /etc/resolv.conf ``` Auf systemd-resolved-Systemen: ```bash resolvectl status ``` Namensauflösung über NSS: ```bash getent hosts server.example.local ``` DNS-Abfrage: ```bash dig server.example.local ``` Bestimmten DNS-Server abfragen: ```bash dig @192.0.2.53 server.example.local ``` Reverse Lookup: ```bash dig -x 192.0.2.20 ``` Zu unterscheiden sind: - DNS-Server nicht erreichbar; - falsche Suchdomäne; - falscher A- oder AAAA-Eintrag; - `/etc/hosts` überschreibt DNS; - Split DNS; - Cache enthält alten Wert; - Anwendung verwendet einen eigenen Resolver; - IPv6-Adresse wird bevorzugt, ist aber nicht erreichbar; - DNS-Auflösung funktioniert, die Anwendung verwendet jedoch einen anderen Namen. --- **28. Firewall prüfen** Je nach System können unterschiedliche Werkzeuge verwendet werden. firewalld: ```bash firewall-cmd --get-active-zones ``` ```bash firewall-cmd --list-all ``` nftables: ```bash nft list ruleset ``` iptables-Kompatibilitätsansicht: ```bash iptables -S ``` Zu prüfen sind: - zuständige Firewalltechnik; - aktive Zone; - Interface-Zuordnung; - Quellnetz; - Zielport; - Protokoll; - IPv4 und IPv6; - Eingangs- und Ausgangsrichtung; - Standardpolicy; - NAT; - Containerregeln; - Cloud- oder vorgelagerte Firewall; - Hostfirewall auf dem Gegenserver. Ein geöffneter Port in der Hostfirewall beweist nicht, dass vorgelagerte Firewalls, Routing oder die Anwendung funktionieren. --- **29. Paketmitschnitt** Beispiel für TCP-Port 443: ```bash tcpdump -ni any tcp port 443 ``` Bestimmter Host und Port: ```bash tcpdump -ni any \ host 192.0.2.20 and tcp port 443 ``` In Datei schreiben: ```bash tcpdump -ni any \ -s 0 \ -w /tmp/example-443.pcap \ tcp port 443 ``` Zu untersuchen sind: - kommen Anfragen am Server an; - sendet der Server Antworten; - TCP-SYN; - SYN/ACK; - Reset; - Retransmissions; - ICMP-Fehler; - falsches Interface; - falsche Quell- oder Zieladresse; - TLS-Handshake; - Zeitabstände; - MTU- oder Fragmentierungsprobleme. Paketmitschnitte können vertrauliche IP-Adressen, Hostnamen, Nutzdaten, Tokens und Anmeldeinformationen enthalten und müssen geschützt gespeichert sowie kontrolliert gelöscht werden. --- **30. CPU und Load prüfen** Überblick: ```bash uptime ``` Dynamische Prozessansicht: ```bash top ``` Logische Prozessoren: ```bash nproc ``` CPU-Informationen: ```bash lscpu ``` Falls `sysstat` installiert ist: ```bash mpstat -P ALL 1 5 ``` Prozessbezogene Statistik: ```bash pidstat 1 5 ``` Load Average beschreibt nicht ausschließlich CPU-Auslastung. Je nach Linux-Zustand können auch Tasks in nicht unterbrechbarem Zustand zur Last beitragen. Zu unterscheiden sind: - ein einzelner CPU-intensiver Prozess; - gleichmäßige Last auf allen CPUs; - Single-Thread-Limit; - hohe I/O-Wartezeit; - virtuelle CPU wird vom Hypervisor nicht ausreichend ausgeführt; - Interruptlast; - Prozessschleife; - zu viele gleichzeitig ausführbare Tasks. --- **31. Arbeitsspeicher prüfen** Speicherübersicht: ```bash free -h ``` Detaillierte Kernelwerte: ```bash cat /proc/meminfo ``` Prozesse nach Speicherverbrauch: ```bash ps aux --sort=-%mem | head ``` Falls verfügbar: ```bash vmstat 1 5 ``` Wichtige Unterscheidungen: - `free` ist nicht der allein verfügbare Speicher; - Cache kann bei Bedarf teilweise freigegeben werden; - `available` ist für die praktische Bewertung meist aussagekräftiger; - hoher Swap-Verbrauch beweist allein keine aktuelle Speicherknappheit; - aktive Swap-Ein- und -Auslagerung kann auf Speicherdruck hinweisen; - Speicherlimit eines Containers oder einer systemd-Unit kann unterhalb des Hostspeichers liegen. --- **32. OOM Killer untersuchen** Kernelmeldungen: ```bash journalctl -k -b | grep -Ei 'out of memory|oom|killed process' ``` Systemweites Journal: ```bash journalctl -b | grep -Ei 'out of memory|oom|killed process' ``` Mögliche Ursachen: - physischer Arbeitsspeicher erschöpft; - kein oder zu wenig Swap; - Speicherleck; - zu viele Prozesse; - Container- oder cgroup-Limit; - große temporäre Last; - falsche Anwendungskonfiguration; - übermäßiger Page Cache in Verbindung mit anderem Druck; - Kernel kann benötigten Speicher nicht bereitstellen. Zu dokumentieren sind: - beendeter Prozess; - Zeitpunkt; - Speicherverbrauch; - cgroup oder Container; - Host- und cgroup-Limit; - vorherige Last; - wiederholtes Auftreten; - Anwendungsprotokoll unmittelbar vor dem Kill. Ein automatischer Dienstneustart kann den OOM-Kill verdecken. Der Dienst erscheint anschließend wieder aktiv, obwohl die Ursache weiter besteht. --- **33. Swap prüfen** Aktive Swap-Bereiche: ```bash swapon --show ``` Speicherübersicht: ```bash free -h ``` Aktivität: ```bash vmstat 1 10 ``` Bei `vmstat` sind insbesondere zu beachten: - `si`: Swap-In; - `so`: Swap-Out; - `wa`: I/O-Wartezeit; - `r`: ausführbare Prozesse; - `b`: blockierte Prozesse. Swap darf nicht ungeprüft mit `swapoff` deaktiviert werden. Der Inhalt muss in den Arbeitsspeicher übernommen werden können; andernfalls drohen starke Last oder Fehler. --- **34. Speicherplatz prüfen** Dateisysteme: ```bash df -hT ``` Bestimmter Pfad: ```bash df -hT /var/lib/example ``` Verzeichnisgrößen: ```bash du -xhd1 /var ``` Größte Unterverzeichnisse: ```bash du -xhd1 /var | sort -h ``` Zu unterscheiden sind: - Dateisystem voll; - Thin Pool voll; - Snapshotbereich voll; - Quote erreicht; - gelöschte, aber geöffnete Datei; - reservierter Speicher; - anderes darunterliegendes Dateisystem; - temporäres Dateisystem voll; - Container-Overlay voll; - Logdatei wächst unkontrolliert; - Anwendung schreibt in einen unerwarteten Pfad. `df` und `du` können unterschiedliche Werte zeigen, beispielsweise wegen gelöschter, aber geöffneter Dateien oder wegen Mounts innerhalb des untersuchten Verzeichnisbaums. --- **35. Inodes prüfen** Inode-Nutzung: ```bash df -ih ``` Ein Dateisystem kann freien Speicherplatz besitzen und trotzdem keine neuen Dateien mehr aufnehmen, wenn keine freien Inodes vorhanden sind. Typische Ursachen: - sehr viele kleine Dateien; - Cache-Verzeichnis; - Mailqueue; - Sessiondateien; - temporäre Dateien; - fehlerhafte Rotation; - Anwendung erzeugt Dateien, löscht sie aber nicht; - Containerlayer; - Build- oder Paketcache. Anzahl der Einträge in einem kontrollierten Verzeichnisbaum: ```bash find /var/tmp/example -xdev -type f | wc -l ``` Bei sehr großen Verzeichnisbäumen kann bereits das Zählen erhebliche I/O-Last verursachen. --- **36. Mounts prüfen** Aktuelle Mounts: ```bash findmnt ``` Bestimmter Pfad: ```bash findmnt -T /var/lib/example ``` Blockgeräte und Dateisysteme: ```bash lsblk -f ``` Persistente Konfiguration: ```bash cat /etc/fstab ``` fstab-Konfiguration ohne tatsächliches Mounten prüfen: ```bash findmnt --verify ``` systemd-Mount-Units: ```bash systemctl list-units --type=mount --all ``` Zu prüfen sind: - richtiges Gerät oder UUID; - richtiger Mountpoint; - Dateisystemtyp; - Mountoptionen; - `ro` statt `rw`; - Netzwerkabhängigkeit; - `_netdev`; - Automount; - Berechtigungen; - verschachtelte Mounts; - nicht mehr erreichbares NFS- oder SMB-Ziel; - veralteter Handle; - Timeout; - lokales Verzeichnis wird sichtbar, weil der erwartete Mount fehlt. Eine Anwendung kann scheinbar korrekt in einen lokalen Ordner schreiben, obwohl das vorgesehene Netzwerk- oder Datenvolume nicht eingehängt ist. --- **37. Schreibgeschütztes Dateisystem** Mountoptionen: ```bash findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS ``` Kernelmeldungen: ```bash journalctl -k -b | grep -Ei 'read-only|I/O error|filesystem|ext4|xfs' ``` Mögliche Ursachen: - Dateisystem wurde wegen Fehlern schreibgeschützt eingehängt; - Datenträgerfehler; - Storage-Verbindung unterbrochen; - falsche Mountoption; - Snapshot oder Image ist absichtlich read-only; - Container-Dateisystem ist schreibgeschützt; - NFS-Export ist read-only; - Cluster- oder Schutzmechanismus verhindert Schreibzugriff. Ein ungeprüftes Remount als `rw` kann eine bestehende Storage- oder Dateisystemstörung verschärfen. Zuerst müssen Kernelmeldungen und Datenträgerzustand bewertet werden. --- **38. Datenträger- und I/O-Fehler prüfen** Blockgeräte: ```bash lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL ``` Kernelmeldungen: ```bash journalctl -k -b | grep -Ei 'I/O error|blk_update|reset|timeout|nvme|ata|scsi|ext4|xfs' ``` Falls `sysstat` installiert ist: ```bash iostat -xz 1 5 ``` S.M.A.R.T.-Informationen, sofern unterstützt: ```bash smartctl -a /dev/sda ``` NVMe-Informationen, sofern das Werkzeug installiert ist: ```bash nvme smart-log /dev/nvme0 ``` Zu prüfen sind: - I/O-Fehler; - Timeouts; - Resets; - Medienfehler; - hohe Latenz; - hohe Queue; - fehlendes Gerät; - Multipath-Fehler; - RAID-Degradation; - Dateisystemfehler; - virtuelle oder externe Storage-Abhängigkeit. S.M.A.R.T.-Tests und Reparaturwerkzeuge können Last oder Zustandsänderungen verursachen. Sie sind nicht ungeprüft auf produktivem Storage auszuführen. --- **39. Dateisystemprüfung sicher planen** Dateisystemtyp feststellen: ```bash findmnt -no FSTYPE,SOURCE,TARGET /var/lib/example ``` Ein klassisches `fsck` darf normalerweise nicht auf einem schreibend eingehängten Dateisystem ausgeführt werden. Vor einer Reparatur sind zu klären: - Dateisystemtyp; - Herstellerverfahren; - Mountzustand; - Backup; - Wartungsfenster; - Ausfallwirkung; - Storage- und RAID-Zustand; - erwartete Reparaturdauer; - Rückweg; - Notfallzugang. Bei XFS, ext4, Btrfs und anderen Dateisystemen unterscheiden sich Diagnose- und Reparaturwerkzeuge erheblich. --- **40. LVM prüfen** Übersicht: ```bash pvs ``` ```bash vgs ``` ```bash lvs ``` Ausführlicher: ```bash lvs -a -o +devices ``` Zu prüfen sind: - Physical Volume vorhanden; - Volume Group vollständig; - Logical Volume aktiv; - freier Platz in der Volume Group; - Thin Pool; - Thin-Metadaten; - Snapshot; - zugrunde liegende Geräte; - Dateisystemgröße; - Mountzustand. Ein vergrößertes Logical Volume bedeutet nicht automatisch, dass auch das darin enthaltene Dateisystem vergrößert wurde. --- **41. Software-RAID prüfen** Status: ```bash cat /proc/mdstat ``` Detailinformationen: ```bash mdadm --detail /dev/md0 ``` Zu prüfen sind: - RAID-Level; - aktive Geräte; - fehlende Geräte; - degradiert; - Rebuild; - Resync; - Geschwindigkeit; - Fehlerzähler; - Ersatzgerät; - zugrunde liegender Datenträgerzustand. Ein Rebuild erhöht die I/O-Last und ersetzt kein Backup. Ein zweiter Fehler während der Wiederherstellung kann je nach RAID-Level zum Datenverlust führen. --- **42. Netzwerk-Mounts prüfen** NFS-Mounts: ```bash findmnt -t nfs,nfs4 ``` SMB-/CIFS-Mounts: ```bash findmnt -t cifs ``` RPC-Dienste eines NFS-Servers: ```bash rpcinfo -p ``` NFS-Exporte, sofern erreichbar: ```bash showmount -e ``` Zu prüfen sind: - Namensauflösung; - Route; - Port; - Serverzustand; - Export oder Freigabe; - Protokollversion; - Mountoptionen; - Benutzer- und ID-Zuordnung; - Kerberos; - Firewall; - Timeout; - Hard- oder Soft-Mount; - veralteter NFS-Handle; - blockierte Prozesse im Zustand `D`. Ein hängender Netzwerk-Mount kann Befehle wie `df`, `du`, `ls` oder Anwendungen blockieren. --- **43. Paketverwaltung prüfen** Debian- und Ubuntu-Systeme: ```bash apt update ``` Installierten Paketstatus prüfen: ```bash dpkg -l ``` Unterbrochene Paketkonfiguration: ```bash dpkg --audit ``` RPM-basierte Systeme: ```bash dnf check ``` Installiertes Paket bestimmen: ```bash rpm -q ``` Datei einem Paket zuordnen: ```bash rpm -qf /usr/bin/example ``` Debian-Paket zuordnen: ```bash dpkg -S /usr/bin/example ``` Mögliche Ursachen: - Repository nicht erreichbar; - DNS- oder Proxyfehler; - abgelaufenes Repository-Zertifikat; - falsche Systemzeit; - Signaturfehler; - Paketdatenbank gesperrt; - abgebrochene Transaktion; - inkompatible Paketversionen; - fehlende Bibliothek; - Drittanbieter-Repository; - Paket wurde manuell überschrieben; - Konfigurationsdatei wurde bei einem Upgrade ersetzt oder nicht übernommen. Paketdatenbanken und Lockdateien dürfen nicht ungeprüft gelöscht werden. Zuerst ist zu bestimmen, ob ein legitimer Paketprozess aktiv ist. --- **44. Paketdateien verifizieren** RPM-Paket: ```bash rpm -V ``` Debian- und Ubuntu-Systeme, falls `debsums` installiert ist: ```bash debsums ``` Abweichungen können entstehen durch: - legitime Konfigurationsänderung; - Update; - beschädigte Datei; - manuelle Änderung; - Sicherheitsvorfall; - falsche Berechtigung; - falscher Eigentümer. Eine Abweichung beweist allein weder einen Defekt noch eine Manipulation. Dateityp und erwartete lokale Anpassung müssen berücksichtigt werden. --- **45. Cronjobs prüfen** Systemweite Crontab: ```bash cat /etc/crontab ``` Systemverzeichnisse: ```bash ls -la /etc/cron.d/ ``` Benutzer-Crontab: ```bash crontab -l ``` Crontab eines anderen Benutzers: ```bash sudo crontab -u exampleuser -l ``` Cron-Dienst: ```bash systemctl status cron ``` Je nach Distribution: ```bash systemctl status crond ``` Cron-Protokoll: ```bash journalctl -u cron ``` Oder: ```bash journalctl -u crond ``` Typische Ursachen: - falscher Benutzer; - eingeschränkte `PATH`-Variable; - relatives Arbeitsverzeichnis; - fehlende Umgebungsvariable; - falsche Zeitzone; - Shell-Unterschied; - fehlendes Ausführungsrecht; - Skript verwendet interaktive Eingaben; - Ausgabe und Fehler werden nicht protokolliert; - Datei besitzt falsche Zeilenenden; - überlappende Ausführungen; - Zielmount ist zum Ausführungszeitpunkt nicht verfügbar. Ein erfolgreicher manueller Skriptstart beweist nicht, dass der Cronjob mit seiner reduzierten Umgebung funktioniert. --- **46. systemd-Timer prüfen** Timer anzeigen: ```bash systemctl list-timers --all ``` Bestimmten Timer: ```bash systemctl status example.timer ``` Zugehörigen Dienst: ```bash systemctl status example.service ``` Protokolle: ```bash journalctl -u example.timer -u example.service ``` Konfiguration: ```bash systemctl cat example.timer ``` Zu prüfen sind: - Timer aktiv; - Timer aktiviert; - nächste Ausführung; - letzte Ausführung; - zugehörige Service-Unit; - Kalenderausdruck; - `Persistent=`; - Zufallsverzögerung; - Zeitzone; - Fehler der aufgerufenen Service-Unit. Der Timer kann erfolgreich ausgelöst haben, obwohl die zugehörige Service-Unit fehlgeschlagen ist. --- **47. Zeit und Zeitsynchronisation prüfen** Systemzeit: ```bash date --iso-8601=seconds ``` Status: ```bash timedatectl ``` Bei chrony: ```bash chronyc tracking ``` ```bash chronyc sources -v ``` Bei systemd-timesyncd: ```bash timedatectl timesync-status ``` Mögliche Auswirkungen falscher Zeit: - TLS-Zertifikate erscheinen ungültig; - Kerberos schlägt fehl; - Protokollereignisse lassen sich falsch zuordnen; - Tokens sind noch nicht oder nicht mehr gültig; - Cronjobs laufen zum falschen Zeitpunkt; - Replikation oder Clustermechanismen werden gestört; - Dateien besitzen unplausible Zeitstempel. Die Zeit darf auf produktiven Datenbank-, Cluster- oder Authentifizierungssystemen nicht ungeprüft sprunghaft verändert werden. --- **48. Zertifikate prüfen** Zertifikatsdatei: ```bash openssl x509 \ -in /etc/example/server.crt \ -noout \ -subject \ -issuer \ -dates \ -fingerprint ``` Private-Key-Dateirechte: ```bash stat /etc/example/server.key ``` Zertifikat und Schlüssel vergleichen, beispielhaft für RSA: ```bash openssl x509 \ -noout \ -modulus \ -in /etc/example/server.crt | openssl sha256 ``` ```bash openssl rsa \ -noout \ -modulus \ -in /etc/example/server.key | openssl sha256 ``` Zu prüfen sind: - Ablaufdatum; - Gültigkeitsbeginn; - Hostname beziehungsweise SAN; - Aussteller; - Zertifikatskette; - passender privater Schlüssel; - Dateirechte; - tatsächlich vom Dienst geladenes Zertifikat; - SNI; - Systemzeit; - vertrauenswürdige CA. Private Schlüssel dürfen nicht in Diagnoseprotokolle oder Tickets kopiert werden. --- **49. Kernelmeldungen prüfen** Aktueller Systemstart: ```bash journalctl -k -b ``` Warnungen und Fehler: ```bash journalctl -k -b -p warning ``` Klassische Anzeige: ```bash dmesg --level=emerg,alert,crit,err,warn ``` Mögliche relevante Meldungen: - I/O-Fehler; - Dateisystemfehler; - OOM; - Treiberfehler; - Linkverlust; - NIC-Reset; - SCSI- oder NVMe-Timeout; - Hardwarefehler; - Kernel-Warnung; - Soft Lockup; - Hard Lockup; - Hung Task; - Segmentation Fault; - AppArmor- oder SELinux-Ablehnung. Der `dmesg`-Puffer kann ältere Meldungen überschreiben. Das persistente Journal oder ein zentraler Logserver kann deshalb zusätzliche Informationen liefern. --- **50. Kernelmodule und Hardware prüfen** Geladene Module: ```bash lsmod ``` Modulinformationen: ```bash modinfo ``` PCI-Geräte und Treiber: ```bash lspci -k ``` USB-Geräte: ```bash lsusb ``` Hardwareübersicht: ```bash lscpu ``` ```bash lsblk ``` Mögliche Ursachen: - benötigtes Modul fehlt; - falsches Modul ist gebunden; - Firmware fehlt; - Kernelupdate passt nicht zu externem Modul; - DKMS-Build fehlgeschlagen; - Gerät wurde getrennt; - virtuelle Hardware wurde geändert; - Modulparameter sind falsch; - Secure Boot verhindert das Laden eines nicht vertrauenswürdigen Moduls. Kernelmodule dürfen nicht ungeprüft entladen werden. Ein Modul kann von Netzwerk-, Storage- oder anderen produktiven Geräten verwendet werden. --- **51. Bootfehler untersuchen** Bootzeit analysieren: ```bash systemd-analyze ``` Langsame Units: ```bash systemd-analyze blame ``` Kritische Kette: ```bash systemd-analyze critical-chain ``` Fehlgeschlagene Units: ```bash systemctl --failed ``` Protokoll des aktuellen Starts: ```bash journalctl -b ``` Protokoll des vorherigen Starts: ```bash journalctl -b -1 ``` Verfügbare Starts: ```bash journalctl --list-boots ``` Zu prüfen sind: - Kernelkommandozeile; - initramfs; - Root-Dateisystem; - fehlerhafte `/etc/fstab`; - fehlendes Blockgerät; - Netzwerk-Mount; - systemd-Abhängigkeit; - Timeout; - Dateisystemprüfung; - Treiber; - verschlüsseltes Volume; - falscher Default-Target; - wiederholt abstürzender Dienst. --- **52. Unerwarteten Neustart oder Absturz prüfen** Letzte Neustarts: ```bash last reboot ``` Vorheriger Boot: ```bash journalctl -b -1 -e ``` Kernelmeldungen des vorherigen Boots: ```bash journalctl -k -b -1 ``` Mögliche Ursachen: - geplanter Neustart; - Paket- oder Kernelupdate; - Stromausfall; - Hypervisoraktion; - Hardware-Watchdog; - Kernel Panic; - OOM; - Temperaturproblem; - manuelle Administratoraktion; - Cloud- oder Hostingereignis; - fehlerhafte Automation. Fehlende Abschlussmeldungen im Journal können auf einen abrupten Ausfall hinweisen, beweisen aber keine bestimmte Ursache. --- **53. Hängendes System und Hung Tasks** Nach Meldungen suchen: ```bash journalctl -k | grep -Ei 'blocked for more than|hung task|soft lockup|hard lockup' ``` Mögliche Ursachen: - blockiertes Storage; - hängender Netzwerk-Mount; - Treiberfehler; - defektes Gerät; - Kernelproblem; - hohe I/O-Latenz; - Deadlock; - Ressourcenerschöpfung. Magic SysRq kann in schweren Störungsfällen Diagnose- oder Notfallfunktionen auslösen. Die verfügbaren Funktionen hängen von Kernelkonfiguration und Systemwerten ab. Status: ```bash cat /proc/sys/kernel/sysrq ``` SysRq-Aktionen können erhebliche Auswirkungen bis hin zu Prozessbeendigung oder Neustart besitzen. Sie dürfen nur nach einem dafür vorgesehenen Notfallverfahren verwendet werden. --- **54. Strace als gezielte Tiefenanalyse** Systemaufrufe eines gestarteten Programms: ```bash strace -f -o /tmp/example.strace ``` An laufenden Prozess anhängen: ```bash strace -f -p ``` Nach Dateioperationen filtern: ```bash strace -f -e trace=file ``` Nach Netzwerkoperationen filtern: ```bash strace -f -e trace=network ``` Zu erkennen sind beispielsweise: - `ENOENT`: Datei oder Pfad nicht vorhanden; - `EACCES`: Zugriff verweigert; - `ECONNREFUSED`: Verbindung abgelehnt; - `ETIMEDOUT`: Zeitüberschreitung; - `ENOSPC`: kein Speicherplatz; - `EROFS`: Dateisystem nur lesbar. `strace` kann Leistung und Zeitverhalten beeinflussen sowie vertrauliche Dateinamen, Argumente und Daten sichtbar machen. --- **55. Typische Fehlerbilder** | Symptom | Mögliche Ursache | Nächster Test | |---|---|---| | Dienst startet nicht | Syntax, Rechte, Abhängigkeit oder fehlende Datei | `systemctl status`, `journalctl -u` | | Dienst beendet sich sofort | Anwendung meldet Fehler oder Prozess forkt anders als erwartet | Journal und `ExecMainStatus` | | Dienst ist `active`, Anwendung funktioniert nicht | interner Fehler, falscher Port oder Backend gestört | `ss`, `curl`, Anwendungslog | | Dienst ist `failed`, Prozess läuft | Prozess wurde außerhalb von systemd gestartet | `ps`, `systemctl show` | | Dienst startet nach Reboot nicht | nicht aktiviert oder Boot-Abhängigkeit fehlerhaft | `is-enabled`, Bootjournal | | Dienst läuft als falscher Benutzer | Unit oder Drop-in geändert | `systemctl cat`, `systemctl show` | | Konfigurationsänderung wirkt nicht | falsche Datei oder kein Reload/Restart | Prozessargumente und Unit prüfen | | Port ist nicht geöffnet | Dienststart oder Bind-Konfiguration | `ss -ltnp` | | Port ist nur lokal erreichbar | Bind-Adresse oder Firewall | `ss`, Firewall, Remote-Test | | Port bereits belegt | zweite Instanz oder anderer Dienst | `ss`, `lsof` | | Zugriff verweigert | Unix-Rechte, ACL, SELinux oder AppArmor | `namei`, `getfacl`, Auditlog | | Datei nicht gefunden, obwohl sie existiert | falscher Namespace, Mount oder Pfadbestandteil | `namei`, `findmnt`, Prozessumgebung | | Schreiben schlägt fehl | Rechte, `ro`, Speicher oder Inodes | `test -w`, `findmnt`, `df -h`, `df -i` | | `df` zeigt voll, `du` nicht | gelöschte offene Datei oder reservierter Bereich | `lsof +L1` | | `du` hängt | Netzwerk-Mount oder Storageproblem | `findmnt`, Prozesszustand, Kerneljournal | | hohe Load bei geringer CPU | I/O-Wait oder Tasks im Zustand `D` | `vmstat`, `iostat`, `ps` | | Prozess wurde unerwartet beendet | OOM, Signal oder Crash | Kernel- und Dienstjournal | | Server nutzt Swap stark | früherer oder aktueller Speicherdruck | `vmstat`, `free`, Prozessspeicher | | keine neuen Dateien trotz freiem Speicher | Inodes erschöpft | `df -ih` | | Mount fehlt nach Neustart | fstab, Abhängigkeit oder Gerät fehlt | `findmnt --verify`, Bootjournal | | Dateisystem plötzlich read-only | I/O- oder Dateisystemfehler | Kerneljournal | | Cronjob läuft manuell, aber nicht automatisch | Umgebung, Benutzer, Pfad oder Shell | Cronlog und kontrollierter Umgebungstest | | systemd-Timer löst aus, Aufgabe scheitert | zugehörige Service-Unit fehlerhaft | Journal beider Units | | TLS-Zertifikat angeblich abgelaufen | falsche Zeit oder altes geladenes Zertifikat | `timedatectl`, `openssl s_client` | | Paketupdate schlägt fehl | Repository, DNS, Signatur oder Lock | Paketmanager- und Prozessstatus | | Server startet langsam | Mount-, Netzwerk- oder Unit-Timeout | `systemd-analyze critical-chain` | | Netzwerk funktioniert nach IP, nicht nach Name | DNS oder NSS | `getent hosts`, `dig` | --- **56. Vorgehensweise bei „Dienst startet nicht“** 1. Host, Dienstname und Zeitpunkt dokumentieren. 2. `systemctl status` auswerten. 3. `systemctl show` auf Ergebnis und Exit-Status prüfen. 4. Dienstjournal seit dem letzten Startversuch lesen. 5. erste relevante Fehlermeldung bestimmen. 6. tatsächlich verwendete Unit und Drop-ins anzeigen. 7. Startbenutzer und Gruppen prüfen. 8. Anwendungskonfiguration mit dem vorgesehenen Syntaxprüfer testen. 9. benötigte Dateien und Pfade prüfen. 10. Unix-Rechte, ACL und alle Pfadbestandteile prüfen. 11. SELinux- oder AppArmor-Ablehnungen prüfen. 12. Portkonflikte prüfen. 13. Mounts und externe Abhängigkeiten prüfen. 14. Speicherplatz, Inodes, RAM und Limits kontrollieren. 15. genau eine nachgewiesene Ursache korrigieren. 16. Dienst kontrolliert starten. 17. Journal, Prozess, Port und Anwendungsfunktion nachkontrollieren. 18. Ursache, Maßnahme und Rückweg dokumentieren. --- **57. Vorgehensweise bei „Server ist langsam“** 1. Zeitraum und konkrete langsame Funktion erfassen. 2. Vergleichswert oder normalen Zustand bestimmen. 3. Load, CPU, RAM und Swap prüfen. 4. Prozesse nach CPU- und Speicherverbrauch sortieren. 5. Prozesszustände und blockierte Tasks prüfen. 6. `vmstat` auswerten. 7. I/O-Latenz und Datenträgerauslastung prüfen. 8. Kernelmeldungen auf Storage- oder Treiberfehler untersuchen. 9. Netzwerkfehler, Drops und Retransmissions berücksichtigen. 10. DNS-Antwortzeiten prüfen. 11. Anwendung und Backend getrennt testen. 12. cgroup-, Container- oder Unit-Limits prüfen. 13. geplante Jobs, Backups und Updates berücksichtigen. 14. Engpass anhand von Messwerten nachweisen. 15. eine kontrollierte Maßnahme durchführen. 16. dieselbe Funktion mit denselben Messwerten erneut testen. --- **58. Vorgehensweise bei „Kein Speicherplatz“** 1. betroffenen Pfad dokumentieren. 2. zugehöriges Dateisystem mit `findmnt -T` bestimmen. 3. Speicherplatz mit `df -hT` prüfen. 4. Inodes mit `df -ih` prüfen. 5. Quotas und Storage-Limits berücksichtigen. 6. Verzeichnisgrößen innerhalb desselben Dateisystems untersuchen. 7. gelöschte offene Dateien mit `lsof +L1` prüfen. 8. Logs, Caches, temporäre Dateien und Containerdaten unterscheiden. 9. LVM-Thin-Pool oder Snapshotbereich prüfen. 10. Ursache des Wachstums bestimmen. 11. Aufbewahrungs- und Löschregeln prüfen. 12. keine unbekannten Dateien pauschal löschen. 13. eine kontrollierte Bereinigung oder Erweiterung durchführen. 14. Anwendung und Speicherzustand erneut prüfen. 15. Präventionsmaßnahme wie Rotation, Monitoring oder Quota dokumentieren. --- **59. Vorgehensweise bei „Dateisystem oder Mount nicht verfügbar“** 1. betroffenen Mountpoint dokumentieren. 2. `findmnt` und `lsblk -f` auswerten. 3. Blockgerät, UUID und Dateisystemtyp bestimmen. 4. `/etc/fstab` prüfen. 5. `findmnt --verify` ausführen. 6. systemd-Mount-Unit und Journal prüfen. 7. Kernelmeldungen auf I/O-Fehler untersuchen. 8. bei Netzwerk-Mounts DNS, Route, Port und Server prüfen. 9. offene Prozesse und Abhängigkeiten berücksichtigen. 10. Storage-, RAID-, LVM- oder Multipath-Zustand prüfen. 11. Backup und Wartungsfenster klären. 12. nur die nachgewiesene Ursache korrigieren. 13. Mount kontrolliert herstellen. 14. Lese- und Schreibfunktion entsprechend dem Sollzustand testen. 15. Neustartverhalten gesondert verifizieren. --- **60. Maßnahmen und Rückwege** **Ursache: Syntaxfehler in der Dienstkonfiguration** Nachweis: - Dienstjournal nennt die Konfigurationsdatei und Zeile; - anwendungseigener Syntaxprüfer reproduziert den Fehler; - vorherige Konfiguration war funktionsfähig. Maßnahme: - fehlerhafte Anweisung nach dokumentiertem Sollzustand korrigieren. Rollback: - gesicherte vorherige Konfiguration wiederherstellen. Verifikation: - Syntaxprüfung; - Dienststart; - Journal; - Port; - praktische Anwendungsfunktion. --- **Ursache: falsche Dateiberechtigung** Nachweis: - Dienst läuft unter dem vorgesehenen Benutzer; - benötigte Aktion schlägt für diesen Benutzer fehl; - `namei`, `stat` oder `getfacl` zeigt das fehlende Recht; - kein SELinux- oder AppArmor-Problem liegt vor. Maßnahme: - Eigentümer, Gruppe oder Mindestberechtigung nach dem Sollzustand korrigieren. Rollback: - vorherige Eigentümer-, Modus- und ACL-Werte dokumentiert wiederherstellen. Verifikation: - Zugriff als Dienstbenutzer; - Dienststart; - keine unnötigen zusätzlichen Rechte; - Anwendungsfunktion. --- **Ursache: falscher SELinux-Kontext** Nachweis: - AVC-Meldung passt zum Fehlerzeitpunkt; - Pfad besitzt einen vom Richtlinien-Soll abweichenden Kontext; - Unix-Rechte sind ausreichend. Maßnahme: - vorgesehenen persistenten Dateikontext konfigurieren und Kontext kontrolliert wiederherstellen. Rollback: - vorherige lokale Kontextregel dokumentiert wiederherstellen oder entfernen. Verifikation: - korrekter Kontext; - keine neue AVC-Ablehnung; - Dienst- und Benutzerfunktion; - SELinux bleibt enforcing. --- **Ursache: Portkonflikt** Nachweis: - Anwendung meldet „Address already in use“; - `ss` oder `lsof` zeigt den belegenden Prozess; - Prozess und Zuständigkeit wurden identifiziert. Maßnahme: - falsche Doppelinstanz kontrolliert entfernen oder den vorgesehenen Dienstport nach Sollkonfiguration zuordnen. Rollback: - ursprüngliche Port- und Dienstkonfiguration wiederherstellen. Verifikation: - vorgesehener Prozess besitzt den Port; - Anwendung antwortet lokal und remote; - keine zweite Anwendung wurde beeinträchtigt. --- **Ursache: gelöschte offene Logdatei belegt Speicher** Nachweis: - `df` zeigt hohe Belegung; - `du` erklärt die Belegung nicht; - `lsof +L1` zeigt eine große gelöschte Datei; - zuständiger Prozess wurde bestimmt. Maßnahme: - Prozess nach betrieblicher Freigabe kontrolliert zum erneuten Öffnen seiner Logs veranlassen oder neu starten. Rollback: - bei einem reinen Reopen normalerweise nicht erforderlich; bei Neustart gilt das dienstbezogene Rückfallverfahren. Verifikation: - Dateideskriptor geschlossen; - Speicherplatz freigegeben; - neue Protokolldatei wird korrekt beschrieben; - Dienstfunktion bleibt erhalten. --- **61. Nachkontrolle** Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen: - Dienst besitzt den erwarteten Zustand; - Prozess läuft unter dem vorgesehenen Benutzer; - Prozess wird nicht fortlaufend neu gestartet; - keine neuen Fehler erscheinen im Journal; - erwarteter Port wird von der richtigen Anwendung verwendet; - Bind-Adresse ist korrekt; - lokale Anwendungsfunktion funktioniert; - Remotezugriff funktioniert; - DNS-Name zeigt auf das richtige System; - Firewallzustand entspricht dem Soll; - benötigte Dateien sind erreichbar; - Eigentümer und Berechtigungen sind minimal und korrekt; - SELinux oder AppArmor bleibt wirksam; - erforderliche Mounts sind vorhanden; - Dateisystem ist im vorgesehenen Modus eingehängt; - Speicherplatz und Inodes sind ausreichend; - keine gelöschten großen Dateien bleiben geöffnet; - CPU, RAM, Swap und I/O sind plausibel; - keine neuen Kernel- oder Storagefehler erscheinen; - Timer oder Cronjob arbeitet auch automatisch; - Verhalten nach einem Neustart wurde berücksichtigt; - temporäre Diagnoseänderungen wurden zurückgenommen; - Ursache, Maßnahme, Rückweg und Ergebnis wurden dokumentiert. --- **62. Dokumentationsbeispiel** ```text Symptom: Der Dienst example-api ließ sich nach einem Konfigurationsupdate nicht mehr starten. Clients erhielten „Connection refused“ auf TCP-Port 8443. Zeitpunkt: 02.08.2026, 11:42 Uhr MESZ Server: linux-app-01.example.local Dienst: example-api.service Nachweis: systemctl status zeigte den Zustand „failed“. Im Journal war unmittelbar nach dem Startversuch ein Berechtigungsfehler für /etc/example-api/server.key dokumentiert. Der Dienst lief als Benutzer example-api. Ein kontrollierter Lesetest als example-api schlug fehl. Die übergeordneten Verzeichnisse waren zugänglich. Es gab keine passende SELinux- oder AppArmor-Ablehnung. Die Schlüsseldatei war nach dem Austausch irrtümlich root:root mit Modus 0600 zugeordnet worden. Ursache: Die neue private Schlüsseldatei besaß nicht den vorgesehenen Gruppeneigentümer. Der Dienstbenutzer konnte sie deshalb nicht lesen. Maßnahme: Nach Dokumentation des Ausgangszustands wurde die Datei der vorgesehenen Dienstgruppe zugeordnet. Der Modus blieb auf das erforderliche Minimum beschränkt. Rollback: Der ursprüngliche Eigentümer und die ursprüngliche Gruppe wurden dokumentiert und können wiederhergestellt werden. Verifikation: Der Konfigurationstest war erfolgreich. Der Dienst startete ohne neue Fehlermeldung. TCP-Port 8443 wurde durch den vorgesehenen Prozess geöffnet. Die lokale und externe HTTPS-Prüfung waren erfolgreich. Der private Schlüssel ist weiterhin nicht für andere Benutzer lesbar. Prävention: Der Zertifikatsaustausch wird künftig durch einen dokumentierten Ablauf mit Kontrolle von Eigentümer, Gruppe, Modus, Sicherheitskontext und anschließendem Konfigurationstest durchgeführt. ``` --- **63. Entscheidungsbaum** ```text Linux-Dienst oder Anwendung gestört ↓ Ist das System erreichbar und die Zeit plausibel? ├── Nein │ ↓ │ Boot, Netzwerk, Routing, DNS und Zeit prüfen │ └── Ja ↓ Ist die Unit aktiv? ├── Nein │ ↓ │ Status, Exit-Code und Dienstjournal prüfen │ └── Ja ↓ Läuft der erwartete Prozess unter der richtigen Identität? ├── Nein │ ↓ │ Unit, Drop-ins, Benutzer und Startmethode prüfen │ └── Ja ↓ Lauscht die Anwendung auf der vorgesehenen Adresse und dem Port? ├── Nein │ ↓ │ Konfiguration, Portkonflikt und Socket-Aktivierung prüfen │ └── Ja ↓ Funktioniert die Anwendung lokal? ├── Nein │ ↓ │ Anwendung, Backend, Rechte, Mounts und Ressourcen prüfen │ └── Ja ↓ Funktioniert der Zugriff über das Netzwerk? ├── Nein │ ↓ │ Bind-Adresse, Firewall, Route, DNS und Paketfluss prüfen │ └── Ja ↓ Benutzerfunktion, Lastverhalten und abhängige Systeme prüfen ``` --- **64. Typische Prüfungsfragen** **Warum reicht der Zustand `active` eines systemd-Dienstes nicht als vollständiger Funktionsnachweis?**
Antwort anzeigen Der Zustand zeigt, dass systemd die Unit als aktiv betrachtet. Er beweist nicht, dass die Anwendung auf dem richtigen Port lauscht, ihre Backends erreicht oder korrekte Antworten auf Benutzeranfragen liefert.
**Worin unterscheiden sich `enabled` und `active`?**
Antwort anzeigen `enabled` beschreibt die Einbindung für einen automatischen Start. `active` beschreibt den aktuellen Laufzeitzustand. Ein Dienst kann aktiv und gleichzeitig nicht aktiviert sein oder aktiviert, aber aktuell fehlgeschlagen sein.
**Warum sollte zuerst `SIGTERM` und nicht sofort `SIGKILL` verwendet werden?**
Antwort anzeigen `SIGTERM` ermöglicht dem Prozess eine kontrollierte Beendigung, beispielsweise das Schreiben von Daten und Schließen von Dateien. `SIGKILL` kann nicht behandelt werden und verhindert eine geordnete Bereinigung.
**Warum können `df` und `du` unterschiedliche Speicherbelegungen anzeigen?**
Antwort anzeigen Eine häufige Ursache sind gelöschte Dateien, die von einem laufenden Prozess weiterhin geöffnet gehalten werden. `du` findet sie nicht mehr im Verzeichnisbaum, während das Dateisystem den belegten Speicher weiterhin berücksichtigt.
**Warum kann ein Dateisystem trotz freiem Speicherplatz keine neue Datei aufnehmen?**
Antwort anzeigen Die verfügbaren Inodes können erschöpft sein. In diesem Fall ist noch Datenkapazität frei, aber es können keine weiteren Dateisystemobjekte angelegt werden.
**Warum beweist ein erfolgreicher manueller Skriptstart nicht, dass ein Cronjob funktioniert?**
Antwort anzeigen Cron verwendet häufig eine reduzierte Umgebung, einen anderen Benutzer, ein anderes Arbeitsverzeichnis und eine eingeschränkte `PATH`-Variable. Das Skript kann deshalb manuell funktionieren und automatisch scheitern.
**Warum sollte SELinux nicht pauschal deaktiviert werden?**
Antwort anzeigen Dadurch wird eine wichtige Sicherheitsschicht für das gesamte System entfernt, ohne die eigentliche Ursache zu beheben. Stattdessen müssen Ablehnung, Pfad, Dateikontext und notwendige Mindestberechtigung untersucht werden.
**Was bedeutet ein Prozess im Zustand `D`?**
Antwort anzeigen Der Prozess befindet sich in einem nicht unterbrechbaren Schlafzustand und wartet häufig auf eine I/O- oder Kerneloperation. Die zugrunde liegende Storage-, Mount- oder Treiberstörung muss untersucht werden.
**Warum kann ein fehlender Mount zu Daten am falschen Ort führen?**
Antwort anzeigen Wenn der vorgesehene Mount fehlt, bleibt das lokale Mountpoint-Verzeichnis sichtbar. Eine Anwendung kann dann unbemerkt in das lokale Root-Dateisystem statt auf das vorgesehene Volume schreiben.
--- **65. Prüfungsfallen** - einen Dienst sofort neu starten, bevor Status und Protokolle gesichert wurden; - `active` mit vollständiger Anwendungsfunktion gleichsetzen; - `enabled` mit aktuell laufend gleichsetzen; - nur die letzte statt der ersten ursächlichen Fehlermeldung betrachten; - Unit-Drop-ins nicht berücksichtigen; - `After=` mit einer Startabhängigkeit gleichsetzen; - Prozess außerhalb von systemd starten und dadurch den Sollzustand verfälschen; - sofort `SIGKILL` verwenden; - Prozess im Zustand `D` wie einen normalen hängenden Prozess behandeln; - Zombieprozess ungeprüft als Hauptursache hoher Last ansehen; - Anwendung als `root` starten, um Berechtigungsfehler zu umgehen; - pauschal Modus `777` vergeben; - nur die Dateirechte, aber nicht die übergeordneten Verzeichnisse prüfen; - ACL-Maske nicht berücksichtigen; - SELinux oder AppArmor pauschal deaktivieren; - Auditmeldungen ohne zeitlichen Zusammenhang bewerten; - Portöffnung mit funktionierender Anwendung gleichsetzen; - nur localhost testen; - nur Remotezugriff testen, ohne die lokale Anwendung zu prüfen; - nur IPv4 und nicht IPv6 berücksichtigen; - `/etc/hosts`, NSS und DNS verwechseln; - Firewallregel ändern, ohne Zone und Interface zu prüfen; - Paketmitschnitte ungeschützt speichern; - Load Average mit reiner CPU-Auslastung gleichsetzen; - niedrigen Wert bei `free` automatisch als Speichermangel bewerten; - hohen Swap-Verbrauch ohne aktuelle Swap-Aktivität als Fehler ansehen; - OOM-Kill übersehen, weil systemd den Dienst neu gestartet hat; - nur Speicherplatz, aber keine Inodes prüfen; - Dateien allein nach Größe ungeprüft löschen; - Logdatei löschen, obwohl der Prozess sie weiterhin geöffnet hält; - `df` oder `du` auf hängenden Netzwerk-Mounts ungeprüft ausführen; - fehlenden Mount übersehen und in das lokale Mountpoint-Verzeichnis schreiben; - ein read-only-Dateisystem sofort als `rw` remounten; - `fsck` auf einem schreibend eingehängten Dateisystem ausführen; - LVM-Volume vergrößern, aber das Dateisystem nicht berücksichtigen; - RAID-Rebuild mit Backup gleichsetzen; - Paketmanager-Lockdatei ungeprüft löschen; - Drittanbieter-Repository und Versionsabhängigkeiten nicht berücksichtigen; - Cronjob mit der interaktiven Benutzerumgebung testen; - Timerstatus prüfen, aber die zugehörige Service-Unit nicht; - Systemzeit ungeprüft sprunghaft ändern; - private Schlüssel in Protokolle oder Tickets kopieren; - Kernelmodule ungeprüft entladen; - mehrere Änderungen gleichzeitig durchführen; - nur den Dienststatus, aber nicht die ursprüngliche Benutzerfunktion nachtesten. --- **66. Checkliste** - [ ] Hostname und Betriebssystem wurden dokumentiert. - [ ] Kernelversion und Architektur wurden erfasst. - [ ] Zeitpunkt und Zeitzone wurden geprüft. - [ ] vollständiger Fehlertext wurde dokumentiert. - [ ] Umfang der Störung wurde bestimmt. - [ ] letzte funktionierende Nutzung wurde erfasst. - [ ] letzte Änderungen wurden geprüft. - [ ] systemd-Gesamtzustand wurde geprüft. - [ ] Unit-Status und Exit-Code wurden geprüft. - [ ] Dienstjournal wurde ausgewertet. - [ ] vorheriger Boot wurde bei Bedarf berücksichtigt. - [ ] tatsächlich verwendete Unit-Datei wurde geprüft. - [ ] Drop-ins wurden berücksichtigt. - [ ] Abhängigkeiten und Startreihenfolge wurden geprüft. - [ ] Anwendungsidentität wurde bestimmt. - [ ] Prozess und Prozesszustand wurden geprüft. - [ ] wiederholte Prozessneustarts wurden berücksichtigt. - [ ] offene Dateien wurden bei Bedarf geprüft. - [ ] tatsächlich verwendete Konfiguration wurde bestimmt. - [ ] Konfigurationssyntax wurde geprüft. - [ ] Eigentümer, Gruppe und Modus wurden geprüft. - [ ] alle Bestandteile des Pfades wurden geprüft. - [ ] ACL wurde berücksichtigt. - [ ] Zugriff wurde als Dienstbenutzer getestet. - [ ] SELinux wurde geprüft. - [ ] AppArmor wurde geprüft. - [ ] Listener, Port und Bind-Adresse wurden geprüft. - [ ] Portkonflikt wurde ausgeschlossen. - [ ] lokale Anwendungsfunktion wurde getestet. - [ ] Remotezugriff wurde getestet. - [ ] IP-Adressen und Routen wurden geprüft. - [ ] DNS und NSS wurden berücksichtigt. - [ ] Firewallregeln wurden geprüft. - [ ] IPv4 und IPv6 wurden unterschieden. - [ ] CPU und Load wurden geprüft. - [ ] RAM und Swap wurden geprüft. - [ ] OOM-Ereignisse wurden geprüft. - [ ] Speicherplatz wurde geprüft. - [ ] Inodes wurden geprüft. - [ ] gelöschte offene Dateien wurden berücksichtigt. - [ ] Mounts wurden geprüft. - [ ] `/etc/fstab` wurde bei Mountproblemen geprüft. - [ ] read-only-Zustand wurde berücksichtigt. - [ ] Kernel- und I/O-Fehler wurden geprüft. - [ ] LVM oder RAID wurde bei Bedarf geprüft. - [ ] Netzwerk-Mounts wurden berücksichtigt. - [ ] Paketstatus und letzte Updates wurden geprüft. - [ ] Cronjob oder systemd-Timer wurde in seiner tatsächlichen Umgebung geprüft. - [ ] Zeit- und Zertifikatsprobleme wurden berücksichtigt. - [ ] Boot- und Kernelmeldungen wurden geprüft. - [ ] genau eine kontrollierte Maßnahme wurde durchgeführt. - [ ] Rückweg wurde vor der Änderung festgelegt. - [ ] Dienst, Port und Benutzerfunktion wurden nachgetestet. - [ ] temporäre Diagnoseänderungen wurden zurückgenommen. - [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert. --- **67. Schnellreferenz** | Beobachtung | Nächstes Werkzeug | |---|---| | Betriebssystemversion unklar | `cat /etc/os-release` | | Kernelversion unklar | `uname -r` | | Systemzustand unklar | `systemctl is-system-running` | | fehlgeschlagene Units gesucht | `systemctl --failed` | | Dienststatus unklar | `systemctl status` | | Exit-Code unklar | `systemctl show` | | Dienstprotokoll gesucht | `journalctl -u` | | vorheriger Boot relevant | `journalctl -b -1` | | tatsächliche Unit unklar | `systemctl cat` | | Drop-ins vermutet | `systemctl show -p DropInPaths` | | Unit-Syntax unklar | `systemd-analyze verify` | | Prozess gesucht | `pgrep -a`, `ps` | | Prozessbaum benötigt | `pstree -ap` | | offene Datei unklar | `lsof`, `fuser` | | gelöschte Datei belegt Speicher | `lsof +L1` | | Dienstbenutzer unklar | `systemctl show -p User -p Group` | | Benutzergruppen unklar | `id`, `getent` | | Pfadberechtigung unklar | `namei -l`, `stat` | | ACL unklar | `getfacl` | | SELinux-Status unklar | `getenforce`, `sestatus` | | SELinux-Ablehnung vermutet | `ausearch` | | AppArmor-Ablehnung vermutet | `aa-status`, Kerneljournal | | Listener unklar | `ss -ltnp` | | Portkonflikt vermutet | `ss`, `lsof` | | lokale HTTP-Funktion unklar | `curl -v` | | TLS-Fehler | `openssl s_client` | | IP-Konfiguration unklar | `ip -br address` | | Route unklar | `ip route get` | | DNS-Auflösung unklar | `getent hosts`, `dig` | | Firewallzustand unklar | `firewall-cmd`, `nft` | | Paketfluss unklar | `tcpdump` | | CPU-Last unklar | `top`, `mpstat`, `pidstat` | | RAM unklar | `free -h`, `vmstat` | | OOM vermutet | `journalctl -k` | | Swap unklar | `swapon --show`, `vmstat` | | Speicherplatz unklar | `df -hT` | | Verzeichnisgröße unklar | `du -xhd1` | | Inodes unklar | `df -ih` | | Mount unklar | `findmnt` | | Blockgerät unklar | `lsblk -f` | | fstab fehlerhaft vermutet | `findmnt --verify` | | I/O-Fehler vermutet | Kerneljournal, `iostat` | | LVM-Zustand unklar | `pvs`, `vgs`, `lvs` | | Software-RAID unklar | `/proc/mdstat`, `mdadm --detail` | | Paketdatei verändert | `rpm -V`, `debsums` | | Cronjob unklar | Crontab und Cronjournal | | systemd-Timer unklar | `systemctl list-timers --all` | | Zeitsynchronisation unklar | `timedatectl`, `chronyc` | | Boot langsam | `systemd-analyze critical-chain` | | Systemaufruf scheitert | `strace` | --- **Merksatz** > Auf einem Linux-Server wird vom objektiven Symptom über Unit, Prozess, Protokoll, Identität, Port und Abhängigkeiten bis zu Berechtigungen, Sicherheitsrichtlinien, Ressourcen, Mounts und Kernel geprüft. Ein Dienst wird erst verändert oder neu gestartet, wenn der Fehlerzustand gesichert, die Auswirkung bewertet und ein Rückweg festgelegt wurde. `active`, ein offener Port und ein erfolgreicher lokaler Test sind jeweils nur Teilnachweise – entscheidend ist die ursprüngliche Benutzerfunktion. --- **Quellen und weiterführende Dokumentation** **Offizielle systemd-Dokumentation** - [systemd – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) - [systemd – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html) - [systemd – systemd.service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) - [systemd – systemd.unit](https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html) - [systemd – systemd.timer](https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html) - [systemd – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html) - [systemd – systemd.resource-control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html) **Offizielle Linux-Kernel-Dokumentation** - [Linux Kernel – Administration Guide](https://docs.kernel.org/admin-guide/index.html) - [Linux Kernel – Magic SysRq](https://docs.kernel.org/admin-guide/sysrq.html) - [Linux Kernel – Kernel Parameters](https://docs.kernel.org/admin-guide/kernel-parameters.html) - [Linux Kernel – Out Of Memory Handling](https://docs.kernel.org/mm/oom.html) - [Linux Kernel – Software RAID](https://docs.kernel.org/admin-guide/md.html) **Offizielle Red-Hat-Dokumentation** - [Red Hat Enterprise Linux 9 – Systemadministration und Monitoring](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9) - [Red Hat Enterprise Linux 9 – SELinux verwenden](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/) - [Red Hat – SELinux-Probleme untersuchen](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux) - [Red Hat Enterprise Linux 9 – Dateisysteme verwalten](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_file_systems/) - [Red Hat Enterprise Linux 9 – Systemstatus und Leistung überwachen](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/) - [Red Hat Enterprise Linux 9 – Logische Volumes verwalten](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/) **Offizielle Ubuntu-Dokumentation** - [Ubuntu Server – How to manage systemd services](https://documentation.ubuntu.com/server/how-to/software/manage-services/) - [Ubuntu Server – Security](https://documentation.ubuntu.com/server/explanation/security/) - [Ubuntu Server – Networking](https://documentation.ubuntu.com/server/explanation/networking/) **Linux-Handbuchseiten** - [Linux man-pages – Übersicht](https://man7.org/linux/man-pages/dir_all_alphabetic.html) - [man7 – proc(5)](https://man7.org/linux/man-pages/man5/proc.5.html) - [man7 – signal(7)](https://man7.org/linux/man-pages/man7/signal.7.html) - [man7 – capabilities(7)](https://man7.org/linux/man-pages/man7/capabilities.7.html) # 8.5 macOS – Prozesse, Dienste, Protokolle, Ressourcen und Speicher analysieren Diese Seite beschreibt die systematische Fehleranalyse auf macOS. Im Mittelpunkt stehen Prozesse, `launchd`-Dienste, Protokolle, CPU, Arbeitsspeicher, APFS-Datenträger, Dateiberechtigungen, Datenschutzfreigaben und Startprobleme. --- **8.5.1 Ziel und Abgrenzung** Nach dieser Seite soll beurteilt werden können: - ob eine Störung nur eine App, einen Benutzer oder das gesamte System betrifft; - ob ein Prozess ausgeführt wird, blockiert ist, abstürzt oder ungewöhnlich viele Ressourcen verbraucht; - ob ein Dienst im richtigen `launchd`-Bereich registriert ist; - ob Protokolle, Absturzberichte oder Systemdiagnosen eine Ursache belegen; - ob CPU, Arbeitsspeicher, Datenträger oder Dateisystem den Engpass bilden; - ob Unix-Berechtigungen, ACLs oder macOS-Datenschutzfreigaben den Zugriff verhindern; - ob Anmeldeobjekte, Hintergrunddienste oder Systemerweiterungen beteiligt sind; - ob ein Software-, Konfigurations- oder Hardwareproblem vorliegt. Eine laufende App, ein vorhandener Prozess oder ein registrierter Dienst beweist noch nicht, dass die ursprüngliche Benutzerfunktion funktioniert. --- **8.5.2 Besonderheiten der macOS-Systemarchitektur** Für die Fehleranalyse sind insbesondere folgende Komponenten wichtig: | Komponente | Aufgabe | Bedeutung für die Diagnose | |---|---|---| | Kernel | Verwaltet Hardware, Speicher, Prozesse und Systemressourcen | Kernel-Panics, Treiber- oder Hardwareprobleme können das gesamte System betreffen | | `launchd` | Startet und verwaltet Dienste, Agents und XPC-Dienste | Ein Dienst kann dauerhaft oder nur bei Bedarf gestartet werden | | LaunchDaemon | Systemweiter Hintergrunddienst | Wird gewöhnlich im `system`-Bereich verwaltet | | LaunchAgent | Benutzerbezogener Hintergrunddienst | Wird gewöhnlich im `gui/`-Bereich verwaltet | | Unified Logging | Zentrales Protokollsystem von macOS | Wird über „Konsole“ oder den Befehl `log` ausgewertet | | APFS | Standarddateisystem moderner macOS-Systeme | Container, Volumes, Snapshots und gemeinsam genutzter Speicher müssen unterschieden werden | | TCC | Datenschutz- und Zugriffssteuerung | Kann Zugriffe trotz korrekter Unix-Berechtigungen verhindern | | Systemerweiterungen | Erweiterungen für Netzwerk, Sicherheit, Treiber und andere Funktionen | Fehlerhafte Erweiterungen können systemweite Auswirkungen verursachen | | Aktivitätsanzeige | Grafische Prozess- und Ressourcenanalyse | Zeigt CPU, Speicher, Energie, Datenträger und Netzwerkaktivität | `launchd`-Dienste können bedarfsgesteuert arbeiten. Ein registrierter Dienst ohne aktuelle PID ist deshalb nicht automatisch fehlerhaft. --- **8.5.3 Typische Symptome** - Eine App startet nicht oder beendet sich sofort. - Eine App reagiert nicht mehr. - Ein Hintergrunddienst funktioniert nach der Anmeldung oder einem Neustart nicht. - Das System ist dauerhaft oder zeitweise langsam. - Der Lüfter läuft stark oder der Energieverbrauch ist ungewöhnlich hoch. - Der Speicherdruck steigt auf Gelb oder Rot. - Der verfügbare Datenträgerspeicher nimmt unerwartet ab. - Ein Prozess verursacht dauerhaft hohe CPU- oder Datenträgeraktivität. - Eine App kann bestimmte Dateien, Ordner, Geräte oder Netzwerkziele nicht verwenden. - Eine Funktion arbeitet nur unter einem bestimmten Benutzerkonto. - Der Fehler verschwindet im sicheren Modus. - Der Mac startet wiederholt neu oder meldet einen Kernel-Panic. - Ein externes Speichermedium wird nicht oder nur schreibgeschützt eingebunden. - Eine App funktioniert nach einem macOS- oder App-Update nicht mehr. --- **8.5.4 Kennzeichnung der Befehle** | Kennzeichnung | Bedeutung | |---|---| | `[LESEND]` | Liest Informationen aus und verändert normalerweise keine Konfiguration | | `[LIVE]` | Beobachtet laufende Ereignisse bis zum Abbruch | | `[PRIVILEGIERT]` | Benötigt möglicherweise `sudo` oder Administratorrechte | | `[BELASTEND]` | Kann CPU, Datenträger oder Protokollsystem zusätzlich belasten | | `[VERÄNDERND]` | Verändert einen Prozess, Dienst oder eine Systemeinstellung | | `[NEUSTART]` | Unterbricht laufende Sitzungen oder Funktionen | Vor verändernden Maßnahmen müssen Befund, Konfiguration und Rückweg dokumentiert werden. --- **8.5.5 Sicherheits- und Betriebswarnungen** - Flüchtige Informationen müssen vor dem Beenden einer App oder vor einem Neustart gesichert werden. - `kill -9`, erzwungenes Ausschalten und erzwungenes Aushängen eines Datenträgers können zu Datenverlust führen. - Apple-Systemdienste dürfen nicht versuchsweise deaktiviert oder aus `/System/Library` entfernt werden. - SIP, Gatekeeper, FileVault und Datenschutzfunktionen dürfen nicht als dauerhafte Fehlerlösung deaktiviert werden. - Protokolle, Systemberichte und `sysdiagnose`-Archive können Benutzernamen, Pfade, Seriennummern, Netzwerkdaten und andere vertrauliche Informationen enthalten. - `diskutil` besitzt sowohl lesende als auch destruktive Unterbefehle. Datenträgerkennung und Unterbefehl müssen vor der Ausführung kontrolliert werden. - Eine Dateisystemreparatur ersetzt kein Backup. - Das manuelle Löschen unbekannter Dateien aus `/Library`, `/System`, `/private` oder APFS-Systembereichen ist keine sichere Standardmaßnahme. - Bei verwalteten Macs können MDM-Richtlinien Einstellungen absichtlich erzwingen. - Befehlsoptionen können sich zwischen macOS-Versionen ändern. Maßgeblich ist die lokale Manpage der tatsächlich installierten Version. Beispiel: ```bash man launchctl man log man diskutil ``` --- **8.5.6 Benötigte Informationen** Vor der Diagnose sollten mindestens folgende Angaben erfasst werden: - genaue macOS-Version und Buildnummer; - Apple-Chip oder Intel-Prozessor; - Zeitpunkt und Häufigkeit der Störung; - betroffene App, Funktion, Benutzer und Geräte; - letzte Updates, Installationen oder Konfigurationsänderungen; - angemeldeter Benutzer und vorhandene Administratorrechte; - MDM- oder Unternehmensverwaltung; - angeschlossene Datenträger, Docks und USB-Geräte; - freier Speicherplatz; - genaue Fehlermeldung; - Verhalten nach Ab- und Anmeldung oder Neustart; - Verhalten unter einem anderen Benutzerkonto; - Verhalten im sicheren Modus; - vorhandene Absturz-, Spin- oder Panic-Berichte. --- **8.5.7 Systemzustand und Basisdaten sichern** Die folgenden Befehle sind lesend. Systeminformationen können Seriennummern und andere vertrauliche Daten enthalten und müssen vor einer Weitergabe geprüft werden. ```bash date sw_vers uname -a uname -m uptime who last reboot | head -n 10 system_profiler SPHardwareDataType SPSoftwareDataType ``` Wichtige Fragen: - Stimmt die Systemzeit? - Welche macOS-Version und welcher Build sind installiert? - Wurde das System kurz vor der Störung neu gestartet? - Betrifft das Problem einen Mac mit Apple-Chip oder einen Intel-Mac? - Ist die problematische App für die vorhandene Prozessorarchitektur geeignet? - Trat der Fehler unmittelbar nach einem Update auf? Die Installationshistorie kann ergänzend geprüft werden: ```bash system_profiler SPInstallHistoryDataType ``` Die zeitliche Übereinstimmung zwischen einer Installation und dem Beginn der Störung ist ein Hinweis, aber noch kein Ursachenbeweis. --- **8.5.8 Ungefährliche Schnellprüfung** ```bash df -h df -ih diskutil list vm_stat sysctl vm.swapusage ps -axo pid,ppid,user,state,%cpu,%mem,etime,command | head -n 30 log show --last 15m --style compact \ --predicate 'messageType == error OR messageType == fault' ``` Zusätzlich in der grafischen Oberfläche prüfen: 1. „Aktivitätsanzeige“ öffnen. 2. CPU, Speicher, Energie, Festplatte und Netzwerk kontrollieren. 3. Nach ungewöhnlich belastenden oder nicht reagierenden Prozessen suchen. 4. „Konsole“ öffnen und den Fehlerzeitraum untersuchen. 5. Unter „Systemeinstellungen → Allgemein → Speicher“ den verfügbaren Speicher prüfen. 6. Unter „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ auffällige Hintergrundobjekte erfassen. 7. Unter „Datenschutz & Sicherheit“ prüfen, ob die betroffene App die tatsächlich benötigten Freigaben besitzt. Noch keine Prozesse beenden, Dienste neu starten oder Dateien löschen. --- **8.5.9 Prozesse systematisch untersuchen** Prozesse können über die Aktivitätsanzeige oder das Terminal untersucht werden. Alle Prozesse anzeigen: ```bash ps -axo pid,ppid,user,state,%cpu,%mem,etime,command ``` Mehrere Messungen der aktiven Prozesse durchführen: ```bash top -l 3 -s 2 -o cpu \ -stats pid,command,cpu,mem,threads,state,time ``` Nach einem Prozess suchen: ```bash pgrep -fl "BeispielApp" ``` Einen bestimmten Prozess untersuchen, wobei `1234` durch die tatsächliche PID ersetzt wird: ```bash ps -p 1234 \ -o pid,ppid,user,state,%cpu,%mem,etime,command ``` Geöffnete Dateien und Verbindungen des Prozesses anzeigen: ```bash lsof -nP -p 1234 | head -n 100 ``` Einen Prozess für zehn Sekunden analysieren: ```bash sample 1234 10 -file "$HOME/Desktop/BeispielApp-sample.txt" ``` Alternativ kann in der Aktivitätsanzeige ein Prozess ausgewählt und über „Mehr → Prozess analysieren“ untersucht werden. Zu prüfen sind: - Elternprozess; - ausführender Benutzer; - Laufzeit; - CPU- und Speicherverbrauch; - geöffnete Dateien; - Netzwerkverbindungen; - wiederholte Neustarts; - nicht reagierende Threads; - zugehörige Protokoll- und Absturzmeldungen. Ein hoher Messwert während eines kurzen Startvorgangs kann normal sein. Aussagekräftiger ist eine wiederholte oder dauerhaft hohe Auslastung im Fehlerzeitraum. --- **8.5.10 Prozesse kontrolliert beenden** Zuerst sollte die App regulär beendet werden. Reagiert sie nicht, kann die Aktivitätsanzeige verwendet werden. Ein Prozess kann im Terminal zunächst mit `SIGTERM` zum geordneten Beenden aufgefordert werden: ```bash kill -TERM 1234 ``` Kennzeichnung: `[VERÄNDERND]` Risiken: - nicht gespeicherte Daten können verloren gehen; - verbundene Anwendungen können ihre Verbindung verlieren; - ein von `launchd` verwalteter Prozess kann automatisch erneut gestartet werden. `SIGKILL` beziehungsweise `kill -9` beendet einen Prozess ohne geordnetes Aufräumen und ist nur die letzte Eskalationsstufe: ```bash kill -KILL 1234 ``` Kennzeichnung: `[VERÄNDERND] [HOHES RISIKO]` Vorher müssen PID, Prozessname, Benutzer und Auswirkungen eindeutig geprüft werden. --- **8.5.11 Dienste und Agents mit launchd analysieren** Systemweite Dienste und benutzerbezogene Agents liegen in unterschiedlichen `launchd`-Bereichen. | Bereich | Typische Verwendung | |---|---| | `system` | Systemweite Daemons | | `user/` | Benutzerbereich ohne zwingenden Bezug zur grafischen Anmeldung | | `gui/` | Grafische Anmeldesitzung eines Benutzers | Systembereich anzeigen: ```bash launchctl print system ``` Bereich des aktuell angemeldeten Benutzers anzeigen: ```bash launchctl print gui/$(id -u) ``` Einen konkreten systemweiten Dienst prüfen: ```bash launchctl print system/com.example.service ``` Einen konkreten Benutzer-Agent prüfen: ```bash launchctl print gui/$(id -u)/com.example.agent ``` Deaktivierungszustände anzeigen: ```bash launchctl print-disabled system launchctl print-disabled gui/$(id -u) ``` Typische Speicherorte: ```text ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons /System/Library/LaunchAgents /System/Library/LaunchDaemons ``` Eine Drittanbieter-Property-List syntaktisch prüfen: ```bash plutil -lint "/Library/LaunchDaemons/com.example.service.plist" ``` Zu untersuchen sind: - korrekter `launchd`-Bereich; - exaktes Dienstlabel; - Programmpfad und Argumente; - ausführender Benutzer; - letzte Exit-Codes; - Startbedingungen; - Standardausgabe und Fehlerausgabe; - Dateiberechtigungen der Property-List; - Existenz und Ausführbarkeit des hinterlegten Programms; - Abhängigkeiten und benötigte Dateien. Ein nicht laufender On-Demand-Dienst kann sich im Normalzustand befinden. Entscheidend ist, ob der vorgesehene Auslöser den Dienst startet und die Benutzerfunktion anschließend funktioniert. --- **8.5.12 Dienst kontrolliert neu starten** Ein eindeutig identifizierter Drittanbieterdienst kann zu Diagnosezwecken neu gestartet werden. Systemweiter Dienst: ```bash sudo launchctl kickstart -k system/com.example.service ``` Benutzer-Agent: ```bash launchctl kickstart -k gui/$(id -u)/com.example.agent ``` Kennzeichnung: `[VERÄNDERND]` Vorher dokumentieren: - Dienstlabel; - aktueller Status; - PID; - offene Verbindungen; - aktuelle Protokollmeldungen; - mögliche Benutzerunterbrechung; - erwartetes Ergebnis. Ein erfolgreicher Neustart beweist nur, dass der Dienst erneut gestartet werden konnte. Danach muss die ursprüngliche Funktion getestet werden. --- **8.5.13 Unified Logging und Konsole** Die App „Konsole“ und der Befehl `log` greifen auf das zentrale macOS-Protokollsystem zu. Fehler und Fault-Meldungen der letzten 30 Minuten: ```bash log show --last 30m --style compact \ --predicate 'messageType == error OR messageType == fault' ``` Meldungen eines bestimmten Prozesses: ```bash log show --last 30m --style compact \ --predicate 'process == "BeispielApp"' ``` Bestimmten Zeitraum untersuchen: ```bash log show \ --start "2026-08-02 13:00:00" \ --end "2026-08-02 13:30:00" \ --style compact ``` Protokollmeldungen live verfolgen: ```bash log stream --style compact --level info \ --predicate 'process == "BeispielApp"' ``` Kennzeichnung: `[LIVE]` Die Live-Ausgabe wird mit `Ctrl-C` beendet. Ein Protokollarchiv der letzten 30 Minuten erstellen: ```bash sudo log collect --last 30m \ --output "$HOME/Desktop/macOS-30m.logarchive" ``` Kennzeichnung: `[PRIVILEGIERT] [DATENSCHUTZRELEVANT]` Bei der Auswertung beachten: - Fehlerzeitpunkt möglichst genau eingrenzen; - Prozess, Subsystem und Kategorie berücksichtigen; - erste Fehlermeldung einer Fehlerkette suchen; - wiederholte Folgefehler nicht automatisch als Ursache interpretieren; - Meldungen vor und nach dem Fehler vergleichen; - normale Warnungen von reproduzierbaren Fehlern unterscheiden; - fehlende Protokollmeldungen sind kein Beweis für Fehlerfreiheit; - Info- und Debug-Meldungen werden nicht immer dauerhaft gespeichert. --- **8.5.14 Absturz-, Spin- und Diagnoseberichte** Die App „Konsole“ zeigt unter anderem: - Absturzberichte mit der Erweiterung `.ips`; - Spin-Berichte nicht reagierender Prozesse; - Protokollberichte; - Diagnoseberichte; - ältere Einträge aus `system.log`; - System- und Benutzerberichte. Benutzerbezogene Diagnoseberichte können zusätzlich in folgendem Verzeichnis liegen: ```bash ls -lt "$HOME/Library/Logs/DiagnosticReports" | head -n 20 ``` Systemweite Diagnoseberichte: ```bash sudo ls -lt "/Library/Logs/DiagnosticReports" | head -n 20 ``` Wichtige Inhalte eines Absturzberichts: - betroffener Prozess und Version; - Zeitpunkt; - Prozessorarchitektur; - Exception Type; - Termination Reason; - auslösender Thread; - verwendete Bibliotheken; - wiederkehrende Funktionsnamen oder Module; - Übereinstimmung mit dem tatsächlichen Fehlerzeitpunkt. Ein einzelner Absturzbericht beweist nicht automatisch einen dauerhaften Defekt. Entscheidend sind Reproduzierbarkeit, Häufigkeit und Übereinstimmung mit der beobachteten Störung. --- **8.5.15 CPU-Auslastung analysieren** Grafisch: 1. Aktivitätsanzeige öffnen. 2. Bereich „CPU“ auswählen. 3. Nach `% CPU` sortieren. 4. Messung während der Störung beobachten. 5. Prozess analysieren oder Spindump erstellen. Im Terminal: ```bash top -l 5 -s 2 -o cpu \ -stats pid,command,cpu,mem,threads,state,time ``` Mögliche Befunde: | Befund | Mögliche Bedeutung | |---|---| | Ein Prozess dauerhaft stark ausgelastet | Endlosschleife, fehlerhafte Verarbeitung oder außergewöhnliche Arbeitslast | | Viele Prozesse gleichzeitig ausgelastet | Systemweite Last, Indizierung, Update oder konkurrierende Aufgaben | | Hohe CPU mit normaler Benutzerfunktion | Möglicherweise erwartete Verarbeitung | | Niedrige CPU bei langsamer App | Warten auf Datenträger, Netzwerk, Sperre oder externen Dienst | | App reagiert nicht und CPU ist nahezu null | Blockierter Thread oder Warten auf eine Ressource | | Wiederkehrende kurze Lastspitzen | Regelmäßiger Agent, Synchronisation oder geplanter Hintergrundprozess | Die CPU-Auslastung muss immer zusammen mit Prozesszustand, Benutzerfunktion, Protokollen und I/O-Aktivität bewertet werden. --- **8.5.16 Arbeitsspeicher analysieren** Apple empfiehlt, den Speicherdruck und nicht nur den freien Arbeitsspeicher zu bewerten. Grafisch: 1. Aktivitätsanzeige öffnen. 2. Bereich „Speicher“ auswählen. 3. Speicherdruck beobachten. 4. Speicher, komprimierten Speicher und Swap-Nutzung prüfen. 5. Nach Speicherverbrauch sortieren. Terminalprüfung: ```bash vm_stat sysctl vm.swapusage ``` Mehrere Messungen im Abstand von zwei Sekunden: ```bash vm_stat -c 5 2 ``` Wichtige Werte: - freie und aktive Speicherseiten; - komprimierter Speicher; - Page-ins und Page-outs; - Swap-ins und Swap-outs; - Entwicklung der Werte während der Störung. Interpretation: | Befund | Bewertung | |---|---| | Speicherdruck Grün | Speicherverwaltung arbeitet derzeit ausreichend | | Speicherdruck Gelb | Ressourcen werden knapp; Verlauf und verursachende Prozesse prüfen | | Speicherdruck Rot | Akuter Speicherengpass wahrscheinlich | | Hohe Komprimierung ohne Störung | Kann normal sein | | Wachsende Swap-Nutzung und Leistungseinbruch | Speicherengpass oder übermäßiger Prozessverbrauch möglich | | Einzelner Prozess wächst kontinuierlich | Mögliches Speicherleck | | Hohe historische Swap-Zahl ohne aktuelle Änderung | Kein ausreichender Ursachenbeweis | Ein einmaliger Gesamtwert ist weniger aussagekräftig als die Veränderung während des reproduzierten Fehlers. --- **8.5.17 Datenträger, APFS und Speicherplatz analysieren** Dateisystembelegung: ```bash df -h df -h /System/Volumes/Data df -ih ``` Datenträgerstruktur: ```bash diskutil list diskutil info / diskutil apfs list ``` Lokale Time-Machine-Snapshots anzeigen: ```bash tmutil listlocalsnapshots / ``` Speicherbelegung im Benutzerordner untersuchen: ```bash du -x -h -d 1 "$HOME" 2>/dev/null | sort -h ``` Datenträgeraktivität beobachten: ```bash iostat -w 2 -c 5 ``` Dateisystem oder Datenträger-I/O für 15 Sekunden verfolgen: ```bash sudo fs_usage -w -f diskio -t 15 ``` Kennzeichnung: `[PRIVILEGIERT] [LIVE] [BELASTEND] [DATENSCHUTZRELEVANT]` Ein Volume prüfen: ```bash diskutil verifyVolume / ``` Kennzeichnung: `[PRÜFEND] [POTENZIELL BELASTEND]` Bei APFS beachten: - mehrere Volumes können Speicher innerhalb eines Containers gemeinsam nutzen; - lokale Snapshots können Speicher belegen; - löschbarer Speicher wird nicht in jeder Anzeige identisch dargestellt; - System- und Datenvolume bilden gemeinsam das startfähige macOS-System; - ein voller Datenträger kann Updates, Protokollierung, Swap, App-Starts und Datenbanken beeinträchtigen; - freie Inodes und freier Speicherplatz sind unterschiedliche Größen; - externe Datenträger können durch Kabel, Stromversorgung, Adapter oder Dateisystemfehler ausfallen. Für Reparaturen sollte das Festplattendienstprogramm verwendet werden. Apple empfiehlt, „Erste Hilfe“ zuerst für die Volumes, anschließend für die Container und zuletzt für das physische Speichergerät auszuführen. Bei Problemen mit dem Startvolume kann die macOS-Wiederherstellung erforderlich sein. --- **8.5.18 Dateiberechtigungen, ACLs und erweiterte Attribute** Identität des aktuellen Benutzers prüfen: ```bash id groups ``` Datei oder Ordner untersuchen: ```bash ls -ldeO@ "/Pfad/zum/Ordner" stat -x "/Pfad/zum/Ordner" ``` Dabei werden unter anderem sichtbar: - Eigentümer; - Gruppe; - klassische Unix-Berechtigungen; - ACL-Einträge; - Dateiflags; - erweiterte Attribute. Zu prüfen ist der gesamte benötigte Pfad. Schreibrechte auf eine Datei reichen beispielsweise nicht aus, wenn ein übergeordneter Ordner nicht betreten oder verändert werden darf. Berechtigungen dürfen nicht pauschal mit `chmod -R 777` geöffnet werden. Dadurch entstehen Sicherheitsprobleme, und bestehende ACLs oder Eigentümerfehler werden nicht zuverlässig behoben. --- **8.5.19 Datenschutzfreigaben und TCC** macOS schützt bestimmte Daten und Geräte zusätzlich zu den Unix-Berechtigungen. Mögliche Freigaben sind unter anderem: - Dateien und Ordner; - Festplattenvollzugriff; - Kamera; - Mikrofon; - Bildschirm- und Systemaudioaufnahme; - Bedienungshilfen; - Automation; - Eingabeüberwachung; - Bluetooth; - lokales Netzwerk. Ein Zugriff kann deshalb fehlschlagen, obwohl `ls -l` korrekte Unix-Berechtigungen anzeigt. Prüfung: 1. „Systemeinstellungen → Datenschutz & Sicherheit“ öffnen. 2. Nur die für die App tatsächlich benötigte Kategorie auswählen. 3. Prüfen, ob die richtige App oder das richtige Terminalprogramm eingetragen ist. 4. Nach einer Änderung die betroffene App gegebenenfalls vollständig beenden und neu starten. 5. Funktion erneut testen. Festplattenvollzugriff sollte nicht pauschal vergeben werden. Die kleinste benötigte Freigabe ist vorzuziehen. --- **8.5.20 App-Signatur, Gatekeeper und Quarantäne prüfen** Eine App kann wegen einer beschädigten Signatur, einer nicht vertrauenswürdigen Herkunft oder einer unvollständigen Installation nicht starten. Signatur einer Beispiel-App prüfen: ```bash codesign --verify --deep --strict --verbose=2 \ "/Applications/Beispiel.app" ``` Gatekeeper-Bewertung prüfen: ```bash spctl --assess --type execute --verbose=4 \ "/Applications/Beispiel.app" ``` Erweiterte Attribute anzeigen: ```bash xattr -l "/Applications/Beispiel.app" ``` Diese Befehle sind lesend. Ein negatives Ergebnis sollte durch eine unveränderte, signierte Installationsdatei des Herstellers behoben werden. Das Entfernen von Quarantäneattributen, das Ad-hoc-Signieren oder das Deaktivieren von Gatekeeper ist keine allgemeine Fehlerlösung. --- **8.5.21 Anmeldeobjekte, Hintergrunddienste und Erweiterungen** Grafische Prüfung: 1. „Systemeinstellungen → Allgemein → Anmeldeobjekte & Erweiterungen“ öffnen. 2. „Bei der Anmeldung öffnen“ erfassen. 3. „Im Hintergrund erlauben“ erfassen. 4. installierte Erweiterungen prüfen. 5. unbekannte oder zeitlich zur Störung passende Drittanbieterkomponenten dokumentieren. Systemerweiterungen anzeigen: ```bash systemextensionsctl list ``` MDM-Registrierungsstatus prüfen: ```bash profiles status -type enrollment ``` Sicherheitszustände können ergänzend gelesen werden: ```bash fdesetup status csrutil status spctl --status ``` Diese Zustände dürfen nicht ohne begründete Anforderung verändert werden. Wenn Anmeldeobjekte als Ursache vermutet werden: 1. vollständige Liste sichern; 2. verdächtige Drittanbieterobjekte kontrolliert deaktivieren; 3. ab- und wieder anmelden oder neu starten; 4. ursprüngliche Funktion testen; 5. Objekte einzeln wieder aktivieren; 6. den tatsächlich verursachenden Eintrag bestätigen. --- **8.5.22 Netzwerkabhängigkeiten kurz prüfen** Wenn eine App langsam ist oder einen Dienst nicht erreicht, muss zwischen lokalem Prozessproblem und externer Abhängigkeit unterschieden werden. ```bash scutil --dns route -n get default netstat -rn lsof -nP -iTCP -sTCP:LISTEN ``` Fragen: - Ist die lokale App blockiert oder wartet sie auf DNS? - Ist das Ziel per IP und Name erreichbar? - Ist ein erforderlicher lokaler Listener vorhanden? - Verhindern Proxy, VPN, Firewall oder lokaler Netzwerkzugriff die Verbindung? - Wartet die App auf einen Server, eine API, eine Freigabe oder einen Cloud-Dienst? Die ausführliche Netzwerkdiagnose erfolgt nach den Abläufen aus Kapitel 3. --- **8.5.23 Fehler auf Benutzer, System oder Hardware eingrenzen** | Test | Erkenntnis | |---|---| | Nur eine App betroffen | App-Konfiguration, App-Daten oder Abhängigkeit wahrscheinlich | | Mehrere Apps eines Benutzers betroffen | Benutzerprofil, TCC, LaunchAgent oder Anmeldeobjekt möglich | | Alle Benutzer betroffen | Systemdienst, systemweite Konfiguration, Datenträger oder Hardware möglich | | Fehler nur mit einem externen Gerät | Gerät, Kabel, Adapter, Stromversorgung oder Treiber untersuchen | | Fehler verschwindet nach App-Neustart | Prozesszustand wahrscheinlich, Ursache aber noch nicht bewiesen | | Fehler verschwindet nach Abmeldung | Benutzerbezogener Agent oder Sitzungszustand möglich | | Fehler verschwindet im sicheren Modus | Drittanbietererweiterung, Anmeldeobjekt oder zusätzlich geladene Komponente möglich | | Fehler bleibt im sicheren Modus bestehen | Grundsystem, Benutzerdateien, Hardware oder weiterhin aktive Abhängigkeit untersuchen | | Fehler tritt auch in der Wiederherstellung auf | Hardware oder Datenträger wird wahrscheinlicher | | Apple Diagnose meldet Referenzcode | Hardwarebefund dokumentieren und nach Apple-Vorgabe weiterbearbeiten | --- **8.5.24 Sicherer Modus** Der sichere Modus hilft zu prüfen, ob beim normalen Start zusätzlich geladene Software beteiligt ist. Mac mit Apple-Chip: 1. Mac vollständig ausschalten. 2. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen. 3. Startvolume auswählen. 4. Umschalttaste gedrückt halten. 5. „Im gesicherten Modus fortfahren“ auswählen. Intel-Mac: 1. Mac einschalten oder neu starten. 2. Sofort die Umschalttaste gedrückt halten. 3. Taste loslassen, wenn das Anmeldefenster erscheint. Der sichere Modus ist ein Kreuztest. Wenn der Fehler dort nicht auftritt, ist damit noch keine einzelne Ursache bewiesen. Anschließend müssen Anmeldeobjekte, Agents, Erweiterungen und Drittanbietersoftware einzeln geprüft werden. Ein normaler Neustart beendet den sicheren Modus. --- **8.5.25 Apple Diagnose und Wiederherstellung** Apple Diagnose prüft Hardwarekomponenten. Mac mit Apple-Chip: 1. Mac ausschalten. 2. Nicht benötigte externe Geräte trennen. 3. Ein-/Ausschalter gedrückt halten, bis die Startoptionen erscheinen. 4. Befehlstaste und `D` gedrückt halten, bis der Mac neu startet. 5. Diagnoseanweisungen befolgen. 6. angezeigte Referenzcodes dokumentieren. Intel-Mac: 1. Mac einschalten. 2. Sofort `D` gedrückt halten. 3. Falls erforderlich, beim Start `Option-D` verwenden. 4. Diagnoseanweisungen befolgen. 5. Referenzcodes dokumentieren. Die macOS-Wiederherstellung wird benötigt, wenn beispielsweise das Startvolume nicht im laufenden System repariert werden kann. - Apple-Chip: Ein-/Ausschalter bis zu den Startoptionen gedrückt halten und „Optionen“ auswählen. - Intel-Mac: beim Einschalten `Command-R` gedrückt halten. Eine erfolgreiche Apple Diagnose schließt nicht jede denkbare Hardwarestörung aus. Sporadische Fehler, Kabelprobleme oder externe Geräte müssen weiterhin durch Kreuztests untersucht werden. --- **8.5.26 Systematischer Diagnoseablauf** 1. **Störung aufnehmen** Benutzer, App, Funktion, Zeitpunkt, Häufigkeit und genaue Meldung erfassen. 2. **Umfang bestimmen** Eine App, ein Benutzer, alle Benutzer oder der gesamte Mac? 3. **Basiszustand sichern** macOS-Version, Build, Architektur, Laufzeit, Installationshistorie und Speicherplatz dokumentieren. 4. **Fehler reproduzieren** Zeitpunkt notieren und nur den erforderlichen Ablauf ausführen. 5. **Prozess prüfen** Existenz, Benutzer, Elternprozess, Zustand, CPU, Speicher und offene Dateien untersuchen. 6. **Dienstzuordnung prüfen** Richtiges `launchd`-Label und richtigen Bereich bestimmen. 7. **Protokolle korrelieren** Meldungen unmittelbar vor, während und nach dem Fehler auswerten. 8. **Ressourcen untersuchen** CPU, Speicherdruck, Swap, Datenträgerbelegung und I/O messen. 9. **Zugriff prüfen** Unix-Berechtigungen, ACLs, TCC-Freigaben und App-Signatur unterscheiden. 10. **Abhängigkeiten prüfen** Netzwerk, DNS, Server, API, Freigabe, Cloud-Dienst oder externes Gerät kontrollieren. 11. **Fehlerdomäne isolieren** Anderer Benutzer, sicherer Modus, getrennte Peripherie oder Wiederherstellung verwenden. 12. **Hypothese formulieren** Erwartetes Prüfergebnis und Gegenbeweis festlegen. 13. **Eine kontrollierte Maßnahme durchführen** Risiko, Rückweg und Messkriterium dokumentieren. 14. **Ursprüngliche Funktion verifizieren** Nicht nur den Prozessstatus, sondern den realen Benutzerablauf testen. 15. **Nachkontrolle durchführen** Protokolle und Ressourcen erneut prüfen sowie Rückfall ausschließen. --- **8.5.27 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | App-Prozess fehlt | App wurde nicht gestartet oder beendet sich sofort | Absturzbericht und zeitlich passende Logs prüfen | | Prozess läuft, App reagiert nicht | Thread blockiert oder wartet auf Ressource | Prozessanalyse oder Spindump erstellen | | Dienstlabel im `system`-Bereich nicht gefunden | Falsches Label, falscher Bereich oder Dienst nicht geladen | Property-List und tatsächliches Label prüfen | | Agent fehlt im `gui/`-Bereich | Falscher Benutzer oder keine grafische Sitzung | UID und Anmeldesitzung prüfen | | Dienst besitzt keine PID | On-Demand-Zustand oder Startfehler | Auslöser betätigen und Logs beobachten | | Hohe CPU bei einem Prozess | Schleife, hohe Last oder fehlerhafte Verarbeitung | Mehrfach messen und Prozess analysieren | | Niedrige CPU, App trotzdem langsam | Warten auf I/O, Netzwerk oder Sperre | `fs_usage`, Netzwerk und Prozessanalyse | | Speicherdruck Gelb oder Rot | Speicherengpass | Speicherverbrauch und zeitliche Entwicklung prüfen | | Swap wächst während der Störung | Arbeitsspeicher reicht für aktuelle Last nicht aus | verursachende Prozesse bestimmen | | Startvolume fast voll | Apps, Updates, Logs und Swap beeinträchtigt | große Verzeichnisse und Snapshots prüfen | | Viele lokale Snapshots | Speicher wird durch Snapshots mitbelegt | Time-Machine-Zustand und Richtlinie prüfen | | Unix-Rechte korrekt, Zugriff trotzdem verweigert | TCC- oder Sandbox-Einschränkung | Datenschutzfreigabe der richtigen App prüfen | | Signaturprüfung schlägt fehl | App beschädigt oder verändert | Originaldatei des Herstellers vergleichen | | Nur ein Benutzer betroffen | Benutzerprofil, LaunchAgent oder TCC | anderes Benutzerkonto als Kreuztest | | Fehler verschwindet im sicheren Modus | zusätzliche Software beteiligt | Drittanbieterkomponenten einzeln prüfen | | Kernel-Panics treten wiederholt auf | Treiber-, Erweiterungs- oder Hardwareproblem | Panic-Berichte, Peripherietest und Apple Diagnose | | Prozess und Port sind vorhanden, Funktion scheitert | Abhängigkeit oder Anwendungsebene fehlerhaft | vollständigen Benutzerpfad Ende zu Ende prüfen | --- **8.5.28 Mögliche Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | Fehlerhafte App-Konfiguration | Fehler ist mit gesicherter Standardkonfiguration reproduzierbar beziehungsweise verschwindet kontrolliert ohne diese Konfiguration | | Beschädigte App-Installation | Signatur- oder Integritätsprüfung schlägt fehl und eine unveränderte Herstellerinstallation funktioniert | | Fehlerhafter LaunchAgent | Fehler tritt nur im zugehörigen Benutzerkontext auf und verschwindet nach kontrollierter Deaktivierung | | Fehlerhafter LaunchDaemon | Systemweiter Fehler korreliert mit Dienststatus, Logs und reproduzierbarem Neustartverhalten | | CPU-Engpass | CPU ist während der Störung dauerhaft ausgelastet und der verursachende Prozess ist bestimmt | | Speicherengpass | Speicherdruck und Swap wachsen während der reproduzierten Störung | | Voller Datenträger | Freier Speicher ist kritisch niedrig und die Funktion arbeitet nach kontrollierter Freigabe wieder | | APFS- oder Dateisystemfehler | `diskutil`, Erste Hilfe oder Systemprotokolle melden konkrete Fehler | | Berechtigungsfehler | Zugriff scheitert mit konkretem Berechtigungsbefund und funktioniert nach minimaler Korrektur | | TCC-Verweigerung | Benötigte Datenschutzfreigabe fehlt und die Funktion arbeitet nach gezielter Freigabe | | Netzwerkabhängigkeit | Lokaler Prozess arbeitet, aber DNS, Verbindung oder Zielsystem scheitert reproduzierbar | | Drittanbietererweiterung | Fehler verschwindet im sicheren Modus und kehrt mit der einzeln aktivierten Erweiterung zurück | | Hardwarefehler | Apple Diagnose, wiederkehrende Panic-Berichte oder unabhängige Kreuztests belegen den Fehler | --- **8.5.29 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg | |---|---|---| | App regulär beenden und neu öffnen | Nicht gespeicherte Daten | App erneut starten und gesicherte Daten öffnen | | Prozess mit `SIGTERM` beenden | Funktionsunterbrechung | App oder Dienst kontrolliert neu starten | | Drittanbieterdienst mit `kickstart` neu starten | Kurzzeitiger Dienstausfall | dokumentierten Ausgangszustand und Konfiguration wiederherstellen | | Anmeldeobjekt vorübergehend deaktivieren | Funktion steht nach Anmeldung nicht bereit | Eintrag anhand der gesicherten Liste wieder aktivieren | | TCC-Freigabe gezielt erteilen | zusätzlicher Datenzugriff | Freigabe nach Test wieder entziehen | | Drittanbieter-App aktualisieren | neue Version kann Konfiguration verändern | Installationsdatei und Konfiguration der vorherigen Version sichern | | App aus Originalquelle neu installieren | lokale App-Bestandteile werden ersetzt | Konfiguration und Benutzerdaten vorher sichern | | Nicht benötigte Benutzerdaten verschieben | Datei steht am alten Ort nicht mehr bereit | Datei aus dem Sicherungsort zurückverschieben | | Sicherer Modus | eingeschränkte Funktionen | normal neu starten | | Erste Hilfe ausführen | zusätzliche Datenträgerbelastung | aktuelles Backup bereithalten; bei Fehler abbrechen und Befund sichern | | Peripheriegerät trennen | zugehörige Funktion steht nicht bereit | Gerät nach Test wieder anschließen | Pro Maßnahme darf möglichst nur eine relevante Variable verändert werden. --- **8.5.30 Verifikation** Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen: - ursprünglicher Benutzerablauf funktioniert vollständig; - App startet und reagiert; - benötigter Dienst wird im richtigen Kontext ausgeführt; - erwartete Datei- und Netzwerkzugriffe funktionieren; - keine neuen Fehler oder Fault-Meldungen erscheinen; - CPU-Auslastung normalisiert sich; - Speicherdruck bleibt im normalen Bereich; - Swap wächst nicht weiter ungewöhnlich; - ausreichender Datenträgerspeicher ist vorhanden; - temporär erteilte Rechte wurden geprüft oder zurückgenommen; - deaktivierte Sicherheitsfunktionen wurden nicht als Dauerlösung belassen; - Funktion bleibt nach Ab- und Anmeldung stabil; - falls relevant, Funktion bleibt nach einem kontrollierten Neustart stabil; - keine andere Benutzerfunktion wurde beeinträchtigt. --- **8.5.31 Präventionsmaßnahmen** - macOS und Anwendungen kontrolliert aktuell halten; - vor Updates Kompatibilität geschäftskritischer Software prüfen; - ausreichend freien Datenträgerspeicher vorhalten; - Backups regelmäßig durchführen und Wiederherstellung testen; - Anmeldeobjekte und Hintergrunddienste dokumentieren; - nicht mehr benötigte Drittanbietererweiterungen entfernen; - Datenschutzfreigaben nach dem Minimalprinzip vergeben; - Installationsquellen und Signaturen prüfen; - Baseline-Werte für CPU, Speicher, Datenträger und Startzeit erfassen; - zentrale oder regelmäßige Protokollauswertung für wichtige Systeme einrichten; - Änderungen mit Zeitpunkt, Version und Rückweg dokumentieren; - Systemdiagnosen und Protokolle datenschutzgerecht behandeln; - bei wiederkehrenden Kernel-Panics Hardware und Erweiterungen frühzeitig isolieren. --- **8.5.32 Typische Fehler bei der Diagnose** - Einen Prozess allein wegen eines hohen Einzelwerts beenden. - Einen fehlenden PID-Wert automatisch als Dienstfehler interpretieren. - Einen Agent im `system`-Bereich suchen, obwohl er im Benutzerkontext läuft. - Nur nach dem Wort „error“ suchen und Zeit, Prozess oder Subsystem ignorieren. - Alte Protokollmeldungen mit dem aktuellen Fehler verwechseln. - Freien RAM als einziges Speicherkriterium verwenden. - APFS-Container, Volume, Snapshot und physisches Laufwerk gleichsetzen. - Unix-Berechtigungen und TCC-Freigaben verwechseln. - Gatekeeper oder SIP zum Testen dauerhaft deaktivieren. - `chmod -R 777` als allgemeine Berechtigungslösung verwenden. - unbekannte Systemdateien oder lokale Snapshots manuell löschen. - sofort `kill -9` verwenden. - nach einem Neustart den vorherigen flüchtigen Zustand nicht mehr rekonstruieren können. - nur prüfen, ob ein Prozess läuft, statt die ursprüngliche Benutzerfunktion zu testen. --- **8.5.33 Typische Prüfungsfragen** **Warum beweist ein laufender Prozess noch keine funktionierende Anwendung?** Der Prozess kann blockiert sein, auf eine Ressource warten oder eine benötigte Abhängigkeit nicht erreichen. Entscheidend ist die vollständige Benutzerfunktion. **Was ist der Unterschied zwischen einem LaunchDaemon und einem LaunchAgent?** Ein LaunchDaemon arbeitet systemweit. Ein LaunchAgent arbeitet im Kontext eines Benutzers beziehungsweise einer Benutzeranmeldung. **Warum kann ein registrierter launchd-Dienst keine PID besitzen, ohne fehlerhaft zu sein?** Bedarfsgesteuerte Dienste werden möglicherweise erst gestartet, wenn ein definierter Auslöser eintritt. **Warum ist der Speicherdruck aussagekräftiger als nur der freie Arbeitsspeicher?** macOS nutzt freien Speicher unter anderem für Caches und Komprimierung. Der Speicherdruck zeigt besser, ob die Speicherverwaltung die aktuelle Last noch ausreichend bewältigt. **Warum sollte kill -9 nicht als erste Maßnahme verwendet werden?** Der Prozess erhält keine Möglichkeit, Dateien zu schließen, Daten zu speichern oder seinen Zustand geordnet zu bereinigen. **Warum können korrekte Unix-Berechtigungen trotzdem zu einer Zugriffsverweigerung führen?** Zusätzliche macOS-Schutzmechanismen wie TCC können den Zugriff auf Dateien, Geräte oder geschützte Daten verhindern. **Was bedeutet es, wenn ein Fehler im sicheren Modus nicht auftritt?** Zusätzlich geladene Software, Anmeldeobjekte oder Erweiterungen werden wahrscheinlicher. Eine konkrete Ursache ist dadurch noch nicht bewiesen. **Warum müssen Protokolle zeitlich mit der Störung korreliert werden?** Ein System erzeugt auch im Normalbetrieb Warnungen und Fehler. Erst die zeitliche und funktionale Übereinstimmung macht eine Meldung für den konkreten Vorfall relevant. **Warum ersetzt eine erfolgreiche Erste-Hilfe-Prüfung kein Backup?** Die Prüfung schützt nicht vor späterem Hardwareausfall, versehentlichem Löschen oder bereits beschädigten beziehungsweise fehlenden Benutzerdaten. --- **8.5.34 Checkliste** - [ ] Störung und ursprüngliche Benutzerfunktion dokumentiert - [ ] betroffene App, Benutzer und Geräte bestimmt - [ ] Zeitpunkt und Häufigkeit erfasst - [ ] macOS-Version, Build und Architektur gesichert - [ ] letzte Installationen und Änderungen geprüft - [ ] Systemlaufzeit und Neustarts erfasst - [ ] Prozessstatus und Ressourcen gemessen - [ ] Elternprozess und ausführender Benutzer geprüft - [ ] richtiges `launchd`-Label bestimmt - [ ] richtiger `launchd`-Bereich geprüft - [ ] Protokolle auf den Fehlerzeitraum begrenzt - [ ] Absturz-, Spin- oder Panic-Berichte geprüft - [ ] CPU-Auslastung mehrfach gemessen - [ ] Speicherdruck und Swap geprüft - [ ] Datenträgerspeicher und APFS-Struktur geprüft - [ ] Snapshots und große Verzeichnisse berücksichtigt - [ ] Unix-Berechtigungen und ACLs geprüft - [ ] TCC-Freigaben getrennt geprüft - [ ] App-Signatur bei Startproblemen geprüft - [ ] Anmeldeobjekte und Systemerweiterungen erfasst - [ ] Netzwerk- und externe Abhängigkeiten geprüft - [ ] Kreuztest mit anderem Benutzer durchgeführt - [ ] sicherer Modus bei Bedarf verwendet - [ ] Hardwarediagnose bei entsprechendem Verdacht durchgeführt - [ ] vor Änderung Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Änderung durchgeführt - [ ] ursprüngliche Benutzerfunktion verifiziert - [ ] Protokolle und Ressourcen nachkontrolliert - [ ] temporäre Diagnoseänderungen zurückgenommen - [ ] Ergebnis und Präventionsmaßnahme dokumentiert --- **8.5.35 Schnellreferenz** | Aufgabe | Befehl oder Werkzeug | |---|---| | macOS-Version | `sw_vers` | | Prozessorarchitektur | `uname -m` | | Systemlaufzeit | `uptime` | | Hardware- und Softwarebericht | `system_profiler SPHardwareDataType SPSoftwareDataType` | | Prozesse | `ps -axo pid,ppid,user,state,%cpu,%mem,etime,command` | | Live-Ressourcen | `top` oder Aktivitätsanzeige | | Prozess suchen | `pgrep -fl "Prozessname"` | | offene Dateien eines Prozesses | `lsof -nP -p 1234` | | Prozess analysieren | `sample 1234 10 -file Bericht.txt` | | Systemweite launchd-Dienste | `launchctl print system` | | Benutzer-Agents | `launchctl print gui/$(id -u)` | | Property-List prüfen | `plutil -lint Datei.plist` | | letzte Protokolle | `log show --last 30m` | | Protokolle live | `log stream` | | Arbeitsspeicher | `vm_stat` | | Swap | `sysctl vm.swapusage` | | Speicherbelegung | `df -h` | | Datenträgerstruktur | `diskutil list` | | APFS-Struktur | `diskutil apfs list` | | lokale Snapshots | `tmutil listlocalsnapshots /` | | Datenträger-I/O | `iostat -w 2 -c 5` | | Dateiaktivität | `sudo fs_usage` | | Berechtigungen und ACLs | `ls -ldeO@ Pfad` | | Systemerweiterungen | `systemextensionsctl list` | | MDM-Status | `profiles status -type enrollment` | | App-Signatur | `codesign --verify` | | Gatekeeper-Bewertung | `spctl --assess` | | grafische Protokolle | Konsole | | CPU, Speicher und I/O | Aktivitätsanzeige | | Dateisystemprüfung | Festplattendienstprogramm | | Hardwareprüfung | Apple Diagnose | --- **8.5.36 Quellen** **Offizielle Apple-Dokumentation** - [Aktivitätsanzeige – Benutzerhandbuch](https://support.apple.com/de-de/guide/activity-monitor/welcome/mac) - [Mac-Prozesse in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr1001/mac) - [CPU-Aktivität in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr43452/mac) - [Speichernutzung in der Aktivitätsanzeige anzeigen](https://support.apple.com/de-de/guide/activity-monitor/actmntr1004/mac) - [Systemdiagnose in der Aktivitätsanzeige ausführen](https://support.apple.com/de-de/guide/activity-monitor/actmntr2225/mac) - [Konsole – Benutzerhandbuch](https://support.apple.com/de-de/guide/console/welcome/mac) - [Protokollmeldungen in der App „Konsole“ anzeigen](https://support.apple.com/de-de/guide/console/cnsl1012/mac) - [Berichte in der App „Konsole“ anzeigen](https://support.apple.com/de-de/guide/console/cnsl664be99a/mac) - [Speichermedium mit dem Festplattendienstprogramm reparieren](https://support.apple.com/de-de/guide/disk-utility/dskutl1040/mac) - [Mac im sicheren Modus starten](https://support.apple.com/de-de/guide/mac-help/mh21245/mac) - [Apple Diagnose verwenden](https://support.apple.com/de-de/102550) - [Zugriff auf Dateien und Ordner steuern](https://support.apple.com/de-de/guide/mac-help/mchld5a35146/mac) - [Einstellungen für Datenschutz und Sicherheit](https://support.apple.com/de-de/guide/mac-help/mchl211c911f/mac) - [Anmeldeobjekte und Erweiterungen verwalten](https://support.apple.com/de-de/guide/mac-help/mtusr003/mac) - [Systeminformationen über den Mac abrufen](https://support.apple.com/de-de/guide/mac-help/syspr35536/mac) **Befehlsreferenzen** Die maßgebliche Befehlsreferenz ist die jeweilige lokale macOS-Manpage: ```bash man launchd man launchctl man log man vm_stat man diskutil man fs_usage man system_profiler ``` Der folgende Spiegel stellt aus Xcode extrahierte Manpages bereit, ist jedoch keine offizielle Apple-Supportseite. Bei Abweichungen gilt die lokale Manpage der installierten macOS-Version: - [launchctl(1)](https://keith.github.io/xcode-man-pages/launchctl.1.html) - [launchd(8)](https://keith.github.io/xcode-man-pages/launchd.8.html) - [log(1)](https://keith.github.io/xcode-man-pages/log.1.html) - [vm_stat(1)](https://keith.github.io/xcode-man-pages/vm_stat.1.html) - [diskutil(8)](https://keith.github.io/xcode-man-pages/diskutil.8.html) - [fs_usage(1)](https://keith.github.io/xcode-man-pages/fs_usage.1.html) - [system_profiler(8)](https://keith.github.io/xcode-man-pages/system_profiler.8.html)