BitLocker aktivieren mit manage-bde, PowerShell oder WMI

BitLocker kennt zwar eine automatische Verschlüsselung, aber diese greift nur unter ganz bestimmten Voraussetzungen. Dazu gehört eine moderne Hardware mit TPM (1.2 oder 2.0), auf der UEFI Secure Boot, Platform Secure Boot und DMA aktiviert sind.

Die Verschlüsselung startet aber erst dann, wenn sich der User an seinem Microsoft-Konto oder an Azure AD anmeldet. Arbeitet man jedoch mit lokalen oder Domänen-Accounts, dann funktioniert die automatische Verschlüsselung nicht.

In on-prem-Umgebungen muss man BitLocker daher auf andere Weise in Gang setzen. Dies kann man über das Dienstprogramm manage-bde oder ein PowerShell-Script mit den nativen BitLocker-Cmdlets oder WMI tun.

Protectors als Voraussetzung

BitLocker unterstützt eine ganze Reihe von Protectors, deren Aufgabe es ist, den Volume Encryption Key zu schützen bzw. freizugeben, wenn die Integrität des Systems oder die Legitimität des Benutzers bewiesen ist.

Daher kann die Verschlüsselung nicht starten, bevor nicht zumindest ein Protector konfiguriert wurde. Versucht man es trotzdem, etwa über die WMI-Funktion encrypt(), dann erhält man den Fehler 0x8031002E (2150694958).

Sowohl manage-bde als auch Enable-BitLocker bieten die Möglichkeit, beim Aktivieren der Ver­schlüsselung auch gleich die Protectors einzurichten. Bei WMI sind dies getrennte Prozesse.

Eine solche Trennung zwischen dem Anlegen von Protectors und dem Aktivieren der Verschlüsselung ist unumgänglich, wenn man die Protectors bereits während des OS-Deployment erzeugen möchte. Die Hürden dafür sind indes sehr hoch, weil BitLocker keine Möglichkeit bietet, Benutzer nachträglich zu zwingen, eine beim Deployment vergebene Standard-PIN zu ändern.

Zulässige Protectors

Egal welche Methode man wählt, sie kann nur Protectors erzeugen, die nicht im Widerspruch zu den Gruppenrichtlinien stehen. Hat man etwa über die Einstellung Zusätzliche Authentifizierung beim Start anfordern den TPM-Protector oder bestimmte Kombinationen mit TPM ausgeschlossen, dann liegt es auf der Hand, dass man sie nachher auch auf der Kommandozeile nicht erstellen kann.

Bestimmte Protectors scheitern beim Versuch ihrer Einrichtung, ohne dass man sie über Gruppenrichtlinien ausgeschlossen hat, weil sie über die Default-Einstellungen nicht zulässig sind. Das gilt besonders für den Schutz von Systemlaufwerken durch ein Passwort alleine. Für diesen Versuch kassiert man den Fehler 0x8031006A (2150695018).

Die Konfiguration von TPM und PIN verhält sich hingegen umgekehrt. Wenn man diesen Protector nicht ausdrücklich über eine Gruppenrichtlinie zulässt, dann scheitert der Vorgang mit dem Fehler 0x80310060 (2150695008). Für TPM alleine gilt das hingegen nicht.

Schließlich gilt es noch zu bedenken, dass nicht alle Protectors für alle Laufwerke geeignet sind. TPM und Kombinationen mit TPM bleiben für Systemlaufwerke vorbehalten, während etwa Auto-Unlock nur bei Datenlaufwerken funktioniert.

Verschlüsselung aktivieren

Der dafür nötige Aufruf sieht mit manage-bde so aus:

manage-bde -on <Laufwerk:>

Wenn noch keine Protectors existieren, dann versucht dieser Aufruf, automatisch einen TPM-Protector einzurichten. Ist das etwa wegen einer Gruppenrichtlinie nicht möglich, dann scheitert der Befehl.

Alternativ kann man Protectors gleich an Ort und Stelle erzeugen, indem man dem Kommando die entsprechenden Parameter mitgibt:

• RecoveryPassword oder -rp
• RecoveryKey oder -rk
• StartupKey oder -sk
• Certificate oder -cert
• TPMAndPIN oder -tp
• TPMAndStartupKey oder -tsk
• TPMAndPINAndStartupKey oder -tpsk
• tpm
• Password oder -pw
• ADAccountOrGroup oder -sid

Ein Beispiel für das Systemlaufwerk könnte so aussehen:

manage-bde -on C: -RecoveryPassword -UsedSpaceOnly

Als zusätzliche Optionen stehen UsedSpaceOnly und SkipHardwareTest zur Verfügung, um nur den mit Daten belegten Plattenplatz zu verschlüsseln bzw. den Hardware-Test zu überspringen. Mit dem Parameter ComputerName bzw. cn kann man BitLocker auch remote auf anderen PCs aktivieren.

PowerShell

Bevorzugt man PowerShell, um BitLocker zu starten, dann ist das Cmdlet Enable-BitLocker dafür zuständig. Auch damit kann man gleich Protectors einrichten, die Parameter dafür sind gleich wie bei Add-BitLockerKeyProtector:

Enable-BitLocker -MountPoint c: -TpmAndPinProtector

Auch hier kann man den Aufruf um die Schalter SkipHardwareTest und UsedSpaceOnly ergänzen.

Für das Remote-Management fehlt der Parameter ComputerName, so dass man eine Session auf dem Ziel-PC öffnen und den Befehl dort ausführen müsste.

WMI

Die WMI-Klasse Win32_EncryptableVolume bietet für diesen Zweck die Funktionen Encrypt() und EncryptAfterHardwareTest(). Letztere erfordert einen Neustart des Rechners. Beide setzen voraus, dass die benötigten Protectors existieren, sie lassen sich mit diesen Methoden nicht erstellen.

Hier ein Beispielaufruf:

$bl = Get-WmiObject `
-Namespace "Root\cimv2\security\MicrosoftVolumeEncryption" `
-ClassName Win32_EncryptableVolume -Filter 'DriveLetter="c:"' `
-ComputerName win11-vm1-l1

$bl.Encrypt()

Wie man am Parameter ComputerName erkennt, aktiviert dieses Kommando die Verschlüsselung auf einem Remote-PC. Beide Funktionen sind nur über GetWmiObject, aber nicht mit Get-CimInstance verfügbar.

Zusammenfassung

Über Gruppenrichtlinien legt man zwar die Einstellungen für BitLocker fest, aber damit lassen sich weder die erforderlichen Protectors anlegen noch die Verschlüsselung starten. Manage-bde und Enable-BitLocker können beide Aufgaben in einem Durchgang erledigen, während die WMI-Klasse Win32_EncryptableVolume dafür separate Funktionen vorsieht.

Die Cmdlets für das BitLocker-Management lassen sich auf Remote-PCs nicht anwenden. Alternativ kann man daher die WMI-Funktionen verwenden, aber auch manage-bde unterstützt den Parameter ComputerName.