Sophos Device Encryption: BitLocker- und FileVault-Fehler beheben

Sophos Fusion (ehemals Sophos Central) steuert Device Encryption, verschlüsselt aber nicht selbst: Unter Windows arbeitet BitLocker, unter macOS FileVault. Ein Fehler kann deshalb in vier verschiedenen Ebenen liegen: Policy und Benutzerzuweisung, Sophos-Agent und Synchronisation, Betriebssystem oder Recovery-Key-Verwaltung.

Sicherer Kurzweg: Den Central-Status und den Wortlaut des Alerts festhalten, den lokalen BitLocker- oder FileVault-Zustand nur lesend prüfen und bestätigen, dass ein gültiger Recovery-Weg vorhanden ist. Erst danach wird genau der betroffene Zweig bearbeitet. Die Policy wiederholt aus- und einzuschalten ist keine Diagnose und kann Status, Schlüsselverwaltung oder eine laufende Ver- beziehungsweise Entschlüsselung verändern.

Normalen Recovery-Fall weitergeben

Dieses Runbook diagnostiziert Abweichungen, ruft aber keinen Recovery Key ab und legt keinen offen. Eine normale Recovery-Anfrage geht an Sophos Device Encryption: Wiederherstellungsschlüssel sicher abrufen.

Nach der autorisierten Übergabe des eindeutig zugeordneten Keys erfolgt das Entsperren auf der jeweiligen Plattform: unter Windows im Artikel BitLocker mit Sophos Fusion verwalten, unter macOS im FileVault-Verwaltungsablauf. Die Abruf-, Offenlegungs- und Entsperrschritte werden hier nicht dupliziert.

Central-Status und Alert nicht verwechseln

Der Verschlüsselungsstatus beschreibt den zuletzt an Central gemeldeten Zustand des Geräts. Ein Alert meldet dagegen eine konkrete Abweichung. Ein alter Status bei gleichzeitig aktueller lokaler Anzeige deutet deshalb zuerst auf Kommunikation oder Synchronisation hin, nicht automatisch auf eine defekte Verschlüsselung.

Die sieben Statuswerte

Pending bedeutet somit nicht «Policy wartet grundsätzlich auf Anwendung», und Suspended bedeutet nicht «Datenträger ist entschlüsselt». Für die Abnahme reicht auch Encrypted allein nicht: Der Recovery Key muss beim zuständigen Recovery-Prozess verfügbar sein.

Die drei Device-Encryption-Alerts

Device is not encrypted bedeutet, dass ein Volume nicht verschlüsselt ist, obwohl es laut Policy verschlüsselt sein sollte. Ein möglicher Grund ist, dass der Benutzer die Verschlüsselung nach der Policy-Zuweisung aufgeschoben hat. Als Nächstes werden das betroffene Volume, ein offener Benutzer-Prompt und der lokale Verschlüsselungsfortschritt geprüft.

Recovery key is missing bedeutet, dass Central in seiner Datenbank keinen Recovery Key für ein verschlüsseltes Volume findet. Das ist ein Recovery-Risiko, kein Beweis für ein unverschlüsseltes Laufwerk. Man prüft Kommunikation, letzte Synchronisation und den zuständigen Recovery-Key-Bestand, ohne den Key in den Fallnotizen zu erfassen.

Device Encryption is suspended meldet eine ausgesetzte BitLocker-Verschlüsselung. Wenn dies nicht absichtlich geschehen ist, nennt Sophos drei typische Gründe:

• Der Recovery Key wurde noch nicht in Central gespeichert. Der Endpoint benötigt eine funktionierende Internetverbindung.
• Vorab bereitgestelltes BitLocker ist noch nicht aktiviert. Der Benutzer muss je nach vorgesehenem Modus PIN, Passwort oder USB Key definieren.
• Windows-Updates werden installiert. BitLocker hebt die Suspension nach dem nächsten Neustart automatisch auf.

Erst wenn diese drei Fälle ausgeschlossen sind, wird nach einem ungeplanten administrativen Eingriff oder einem tieferen Windows-Fehler gesucht.

Ein Ablauf für jedes Fehlerbild

1. Zustand einfrieren und Recovery absichern

Vor der ersten Änderung werden notiert:

• Gerätename und Central-Geräte-ID;
• Betriebssystem, Build und Zeitpunkt des Problems;
• zugewiesene Policy und betroffener Benutzer;
• exakter Status, Alert-Text, Fehlercode und Zeitstempel;
• betroffenes Volume und ob gerade ver- oder entschlüsselt wird;
• ob der Recovery-Verantwortliche einen passenden, aktuellen Key bestätigt hat.

Im Arbeitsprotokoll steht nur Key vorhanden, Key fehlt oder noch ungeklärt. Der Schlüssel selbst und vollständige Key-IDs werden nicht übernommen.

2. Central und lokalen Zustand vergleichen

Vier Ergebnisse führen in unterschiedliche Richtungen:

1. Beide Seiten melden denselben Zustand: Das lokale Fehlerbild bearbeiten.
2. Lokal korrekt, Central veraltet: Agent-Kommunikation, Policy-Zeitstempel und letzte Synchronisation prüfen.
3. Central korrekt, lokal widersprüchlich: Das konkrete Volume und die native Betriebssystemanzeige prüfen; nicht von einem Gesamtstatus auf alle Volumes schliessen.
4. Beide Seiten unbekannt oder widersprüchlich: Keine zustandsändernde Reparatur. Diagnosepaket erstellen und eskalieren.

3. Policy-Anwendung prüfen

Eine installierte Komponente beweist nicht, dass eine Policy greift. Kontrolliert werden:

• Policy ist eingeschaltet und dem vorgesehenen Benutzer oder seiner Gruppe zugewiesen;
• der am Gerät angemeldete Benutzer ist in Central dem richtigen Gerät zugeordnet;
• keine höher priorisierte oder globale Vorgabe erklärt die sichtbare Einstellung;
• Zeitpunkt der letzten Policy-Anwendung ist neuer als die letzte Änderung;
• keine GPO, MDM-Policy oder frühere Verschlüsselungsverwaltung erzwingt einen anderen Zustand.

Eine Zuweisung wird an ihrer Quelle korrigiert. Lokale Richtlinien pauschal auf Not configured zu setzen oder eine Central-Policy mehrfach zu toggeln verschleiert nur, welche Verwaltung tatsächlich gewonnen hat.

Windows: BitLocker startet nicht oder bleibt ausstehend

Erst lokal und nur lesend prüfen

In einer administrativen Eingabeaufforderung zeigt Windows den Zustand aller BitLocker-Volumes:

manage-bde -status

Wichtig sind pro Volume Conversion Status, Percentage Encrypted, Protection Status, Lock Status und die vorhandenen Key Protectors. Die Ausgabe darf für den Support bereinigt werden; Recovery Passwords oder andere Geheimnisse werden entfernt.

Das wichtigste Sophos-Protokoll liegt hier:

C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log

Zusätzlich werden der passende Zeitraum im Windows Event Viewer, der TPM-Zustand und die tatsächlich wirksamen BitLocker-Gruppenrichtlinien betrachtet. Nicht die Zahl der Warnungen, sondern der erste reproduzierbare Fehler nach Policy-Anwendung oder Neustart führt zum nächsten Schritt.

Der Benutzer sieht keinen Aktivierungsdialog

Fehlt der erwartete Dialog, werden Sitzungsart, angemeldeter Benutzer, exakter Logtext, Zeitpunkt und ausstehende Neustarts nur dokumentiert. Aus einem einzelnen Logeintrag wird weder eine bestimmte Sitzungsursache noch ein Dienstdefekt abgeleitet. Ein Wechsel der Sitzungsart oder Neustart erfolgt nur nach aktueller, für die installierte Version geltender Sophos-Anweisung; danach werden manage-bde -status, der neue CDE.log-Zeitstempel und Central erneut verglichen.

Policy und GPO widersprechen sich

Typische Konfliktbereiche sind Startup Authentication, zulässige Protectors, TPM-Anforderungen, FIPS, Verschlüsselungsmethode und Recovery-Key-Backup. Man dokumentiert die wirksame GPO und vergleicht sie mit der Central-Policy. Die fachlich zuständige Verwaltung wird danach korrigiert; der Troubleshooting-Fall ist nicht der Ort, um das Sicherheitskonzept durch einen lokalen Workaround zu umgehen.

Die normale Konfiguration, Protector-Auswahl und GPO-Abstimmung erklärt BitLocker mit Sophos Fusion verwalten.

BitLocker ist Suspended

Suspended lässt keine Entschlüsselung erkennen, sondern einen ausgesetzten Schutz auf mindestens einem Volume. Zuerst werden ein laufendes Windows- oder Firmware-Update, ausstehende Neustarts, Pre-Provisioning und die Central-Ablage des Recovery Keys geprüft.

• Ist ein dokumentierter Updatevorgang noch nicht abgeschlossen, wird dessen vorgesehene Neustartfolge beendet und danach erneut geprüft.
• Hat ein Administrator BitLocker bewusst ausgesetzt, entscheidet der Change-Verantwortliche über die Wiederaufnahme.
• Fehlt eine Erklärung, gilt die Suspension als Sicherheitsabweichung. Man erzwingt die Wiederaufnahme nicht blind, sondern sichert Zeitpunkt, Event und Protector-Zustand für die Eskalation.

Aktivierungsfehler mit TPM-, Firmware- oder DMA-Kontext

Bei einem hardwarebezogenen Aktivierungsfehler werden der exakte Fehlercode, der aktuelle TPM-/UEFI-Zustand, der vorgesehene Authentifizierungsmodus sowie Firmware- und Treiberversionen dokumentiert. Eine Ursache oder Reparatur wird daraus nicht ohne aktuelle, modell-, Windows- und Sophos-versionsspezifische Anweisung abgeleitet. Ältere Signaturen sind deshalb nur im support-gesteuerten historischen Abschnitt eingeordnet.

Bei einer Meldung zu einem ungeschützten DMA-fähigen Gerät muss der Gerätehersteller bestätigen, ob Bus und Gerät intern sowie sicher sind. Ein Registry-Eintrag unter AllowedBuses, Änderungen an ACLs oder die pauschale Freigabe unbekannter Busse sind keine allgemeine Reparatur. Das Verhalten unterscheidet sich zudem zwischen Windows-Versionen. Ohne aktuelle, modell- und versionsspezifische OEM- oder Sophos-Anweisung wird nicht in die Registry eingegriffen.

macOS: FileVault wartet auf Benutzer oder Recovery Key

Benutzerautorisierung eingrenzen

FileVault benötigt einen lokal autorisierten Benutzer. Bei Apple Silicon gehört dazu ein Volume Owner; für die Verwaltung ist ausserdem der passende Secure-Token-Zustand relevant. Geprüft werden deshalb:

• Ist der aktuell lokal angemeldete Benutzer von der Device-Encryption-Policy erfasst?
• Kann dieser Benutzer FileVault beim Start tatsächlich entsperren?
• Ist der erwartete Benutzer in der Sophos Device Encryption App sichtbar?
• Sind Secure Token beziehungsweise Volume-Owner-Berechtigung vorhanden?
• Wartet ein Sophos-Dialog auf das macOS-Anmeldekennwort oder auf Encrypt, Create key beziehungsweise Proceed?

Man erstellt nicht vorsorglich einen neuen lokalen oder mobilen Account und ändert keine Benutzerberechtigung, bevor die fehlende Voraussetzung eindeutig feststeht. Die unterstützte Autorisierung weiterer Benutzer bleibt beim FileVault-Verwaltungsablauf.

FileVault ist aktiv, Central hat aber keinen Key

«FileVault aktiv» und «Recovery Key in Central verwaltet» sind zwei verschiedene Aussagen. Für jedes von der Policy verlangte Volume werden lokaler Verschlüsselungsstatus, Recovery-Anzeige in der Sophos Device Encryption App und letzter Central-Zeitstempel verglichen.

Die dokumentierten Sophos-Abfragen sind lesend:

/usr/local/bin/seadmin status
/usr/local/bin/seadmin --device-encryption

status hilft beim Vergleich der letzten Synchronisation. --device-encryption zeigt Policy sowie Verschlüsselungs- und Recovery-Status der internen Volumes. Ein verschlüsseltes Volume ohne bestätigte Central-Ablage wird nicht als erfolgreicher Rollout abgenommen.

Zeigt Sophos nach einem fehlgeschlagenen Speichervorgang einen persönlichen Recovery Key an, bleibt die sichere Übergangsverwahrung beim FileVault-Verantwortlichen. Der Schlüssel wird nicht in das Diagnosepaket kopiert. Der unterstützte Umgang mit diesem alleinigen Key und die spätere Central-Bestätigung stehen im verlinkten FileVault-Artikel; dieses Runbook ersetzt den Recovery-Prozess nicht.

Verschlüsselung oder Entschlüsselung bleibt stehen

Ein unveränderter Prozentwert ist noch kein Grund für einen Neustart des Verschlüsselungsmanagements. Zuerst werden über einen ausreichend langen Zeitraum verglichen:

• lokaler Fortschritt des konkreten Volumes;
• Stromversorgung, freier Speicher und anstehender Neustart;
• letzter Policy- und Agent-Zeitstempel;
• Betriebssystemereignisse zum selben Zeitpunkt;
• konkurrierende Verschlüsselungsverwaltung;
• erwarteter Zielzustand: verschlüsseln, übernehmen oder entschlüsseln.

Bei einer geplanten Entschlüsselung bestätigt der Change-Verantwortliche Zielzustand, Zuständigkeit für den Recovery Key und Plattformablauf. Windows-Ausführung gehört in den BitLocker-Artikel, macOS-Ausführung in den FileVault-Artikel. Bei einer unerwarteten Entschlüsselung wird der Vorgang nicht durch hektische Policy-Wechsel übersteuert; Gerät, Policy-Änderung und Ereignisse werden als Sicherheitsabweichung untersucht.

Unmanaged, bestehende Verschlüsselung und Migration

Unmanaged bedeutet nur: Die Device-Encryption-Komponente ist installiert, aber keine Device-Encryption-Policy wird angewendet. Der Datenträger kann verschlüsselt oder unverschlüsselt sein. Das ist keine Aufforderung, sofort eine Policy zuzuweisen.

Vor Adoption oder Migration wird der Quellzustand inventarisiert:

1. Plattform, Volumes und lokaler Verschlüsselungszustand.
2. Aktive Protectors beziehungsweise berechtigte FileVault-Benutzer.
3. Bisheriges Managementsystem und wirksame GPO-/MDM-Vorgaben.
4. Verifizierter Recovery-Weg unter der bisherigen Verwaltung.
5. Vorgesehener Zielzustand und genau ein verantwortliches Zielsystem.

Danach wird genau ein Plattformzweig gewählt. Die Ausführung bleibt bei BitLocker oder FileVault. Solange der neue Recovery Key nicht im Zielsystem bestätigt ist, wird der bisherige Recovery-Weg nicht verworfen und die alte Verwaltung nicht ausser Betrieb genommen.

Auch die Listen in Central haben unterschiedliche Bedeutungen: Computers without Device Encryption installed zeigt verwaltete Geräte ohne Encryption-Komponente. Unmanaged computers kann dagegen aus dem Verzeichnis synchronisierte Computer ohne Sophos-Schutz enthalten. Vor einer Installations- oder Policy-Aktion wird deshalb zuerst geklärt, in welcher Liste und aus welchem Grund das Gerät erscheint.

Historische Signaturen: erkennen, nicht selbst reparieren

Die folgenden Signaturen stammen aus älterer Avanet-Betriebserfahrung. Sie helfen, einen Supportfall einzuordnen, sind aber keine aktuelle Reparaturfreigabe:

• ManagementStatus.InvalidNamespace, 0x8004100E oder 0x80041002 im Zusammenhang mit Win32_EncryptableVolume;
• 0x803100B6 auf als Slate erkannten Geräten;
• System.BadImageFormatException bei Sophos.Encryption.BitLockerService.exe;
• BitLocker-Fehler nach einer MBR-zu-GPT- oder Legacy-BIOS-zu-UEFI-Umstellung;
• Aktivierungsfehler bei eingehängtem bootfähigem ISO oder Datenträger;
• No UI user session available;
• 0x80310048 beziehungsweise FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED;
• ältere DMA-/AllowedBuses-Fehlerbilder;
• Bedarf nach erweitertem DEBUG- oder TRACE-Logging.

Die Microsoft-Klasse Win32_EncryptableVolume erklärt den WMI-Kontext, autorisiert aber weder eine MOF-Neuregistrierung noch eine WMI-Reparatur. Ebenso werden keine DLLs aus Caches kopiert, Registry-Berechtigungen übernommen, BCD-/Recovery-Partitionen verändert oder undokumentierte Logging-Schlüssel gesetzt. Sophos Support muss für die installierte Version, den exakten Build und die vollständige Signatur eine aktuelle Anweisung geben.

Diagnosepaket und Eskalationspunkt

Windows

• Export oder Screenshot des Central-Alerts ohne Secret;
• Geräte-, Policy- und Benutzerzuordnung mit Zeitstempeln;
• bereinigte Ausgabe von manage-bde -status;
• relevanter Ausschnitt aus CDE.log;
• passende Windows-Ereignisse und tatsächlich wirksame BitLocker-GPOs;
• TPM-, UEFI- und Firmwarestand sowie letzter echter Neustart;
• Endpoint Self Help oder Sophos Diagnostic Utility (SDU), sofern im eingesetzten Agent verfügbar;
• kurze Liste der bereits ausgeführten, zustandserhaltenden Prüfungen.

macOS

• Geräte-, Policy- und Benutzerzuordnung mit Zeitstempeln;
• macOS- und Sophos-Komponentenversion;
• bereinigte Ausgaben von seadmin status und seadmin --device-encryption;
• Status der betroffenen Volumes in der Sophos Device Encryption App;
• Information, ob der Benutzer Secure Token/Volume-Owner- und Pre-Boot-Berechtigung besitzt;
• Zeitpunkt der letzten erfolgreichen Central-Kommunikation;
• SDU-Paket und reproduzierbarer Ablauf ohne Recovery Key.

Vor der Weitergabe werden Benutzerdaten auf das Nötige reduziert und Recovery Keys, Passwörter, vollständige Key-IDs sowie andere Secrets entfernt.

An Sophos Support wird eskaliert, wenn Zuständigkeit oder Verfügbarkeit des Recovery Keys ungeklärt bleiben, Central und Betriebssystem nach erfolgreicher Synchronisation widersprüchliche Zustände melden, der Agentdienst wiederholt ausfällt, eine historische Signatur vorliegt oder der nächste Schritt WMI, Registry, Programmdateien, BCD beziehungsweise Partitionen verändern würde. Der Fall nennt die erste beobachtete Abweichung, nicht nur den letzten Folgefehler.

Häufige Fragen