Festplattenverschlüsselung ist in den meisten Unternehmen beschlossen, aber oft nur halb umgesetzt: Die Notebooks sind verschlüsselt, die Wiederherstellungsschlüssel liegen in einer Excel-Tabelle, auf Servern hat niemand BitLocker aktiviert. Eine Gruppenrichtlinie löst genau dieses Problem: einheitlicher Algorithmus, verbindlicher Escrow ins Active Directory und keine Verschlüsselung ohne hinterlegten Schlüssel.
Warum BitLocker in die GPO gehört
Ohne zentrale Vorgabe entscheidet jedes Gerät selbst über Verschlüsselungsart und Schlüsselablage. Bei einem Diebstahl oder einer entsorgten Serverplatte zählt nur, ob der Schlüssel schnell und vollständig verfügbar ist. Die GPO liefert beides: XTS-AES 256 statt des Standardwerts XTS-AES 128 und einen erzwungenen Escrow in das AD DS.
Voraussetzungen prüfen
Hardware und Firmware
BitLocker braucht ein TPM 2.0, UEFI ohne CSM und für den vollen Funktionsumfang Secure Boot. Drei Befehle genügen für den Check auf jedem Zielgerät.
Get-Tpm | Select-Object TpmPresent, TpmReady, ManufacturerVersion
Confirm-SecureBootUEFI
Get-CimInstance Win32_OperatingSystem | Select-Object Caption, VersionAntwortet Get-Tpm mit TpmPresent: False, ist das Gerät für eine TPM-gebundene Verschlüsselung ungeeignet. Bei TpmReady: False hilft Initialize-Tpm weiter.
Active Directory vorbereiten
Das AD-Schema muss die TPM- und Wiederherstellungsattribute kennen – bei jeder Domäne ab Windows Server 2008 ist das der Fall. Zum Anzeigen der Schlüssel wird zusätzlich das RSAT-Feature BitLocker Recovery Password Viewer installiert; erst damit erscheint in ADUC der Reiter „BitLocker-Wiederherstellung“.
Die Baseline-Gruppenrichtlinie
Alle Einstellungen liegen unter Computerkonfiguration → Richtlinien → Administrative Vorlagen → Windows-Komponenten → BitLocker-Laufwerksverschlüsselung → Betriebssystemlaufwerke.
# Sinnvolle Werte in der Baseline-GPO
Require additional authentication at startup = Enabled
Allow BitLocker without a compatible TPM = deaktiviert
Configure TPM startup = Require TPM
Configure TPM startup PIN = Allow startup PIN with TPM
Choose drive encryption method and cipher strength = XTS-AES 256 Bit
Enforce drive encryption type on OS drives = Full encryption
Configure minimum PIN length for startup = 8
Disable new DMA devices when this computer is locked = EnabledDer Haken bei „Allow BitLocker without a compatible TPM“ ist der wichtigste: Bleibt er gesetzt, wählen Nutzer eine reine USB-Schlüsselvariante, die bei verlorenem Stick zur Datenfalle wird. XTS-AES 256 kostet auf aktuellen CPUs kaum Leistung. Die DMA-Regel blockiert Thunderbolt-Angriffe auf ein gesperrtes Gerät.
Wiederherstellungsschlüssel ins Active Directory
Zwei Einstellungen gehören zwingend zusammen. „Store BitLocker recovery information in Active Directory Domain Services“ wird aktiviert, inklusive „Require BitLocker backup to AD DS“. Zusätzlich wird unter „Choose how BitLocker-protected operating system drives can be recovered“ die Option „Do not enable BitLocker until recovery information is stored to AD DS“ gesetzt.
Diese Sperre ist unbequem, aber richtig: Kann der Rechner seinen Schlüssel nicht ins AD schreiben, startet die Verschlüsselung nicht. Vorher also an einem Pilotrechner testen:
manage-bde -status C:
manage-bde -protectors -get C:
manage-bde -protectors -adbackup C: -id {Schutzvorrichtungs-ID}
$dn = (Get-ADComputer PC01).DistinguishedName
Get-ADObject -SearchBase $dn -Filter * | Where-Object ObjectClass -eq 'msFVE-RecoveryInformation'Der letzte Befehl muss ein Objekt zurückgeben. Kommt nichts zurück, fehlt dem Rechnerkonto das Schreibrecht auf das eigene AD-Objekt – ein Klassiker nach Restores oder manuell angelegten Computerobjekten.
Rollout in Wellen
Die Baseline zunächst per Sicherheitsfilter an eine Pilot-OU verknüpfen, dort gpupdate /force ausführen und mit gpresult /h gpo.html prüfen. Danach die Aktivierung gebündelt auslösen, statt auf den Nutzer zu warten:
Enable-BitLocker -MountPoint C: -EncryptionMethod XtsAes256 -TpmProtector
Get-BitLockerVolume -MountPoint C: | Select-Object VolumeStatus, ProtectionStatus, EncryptionMethodAuf Servern nur das Systemlaufwerk verschlüsseln und Datenvolumes separat behandeln. Cluster Shared Volumes bleiben unverschlüsselt, virtuelle Maschinen benötigen ein virtuelles TPM.
Netzwerkentsperrung für unbeaufsichtigte Systeme
Ein Server mit TPM-PIN bleibt nach einem Neustart stehen, bis jemand die PIN eintippt – bei Patchfenstern in der Nacht ein Problem. Die Netzwerkentsperrung löst das: Der Client holt den Schlüssel beim Start per DHCP aus dem Netz. Nötig sind ein UEFI-DHCP-Treiber im Client, eine TPM-Schutzvorrichtung, ein Server mit der Rolle Windows Deployment Services, ein separater DHCP-Server, das Zertifikat „BitLocker Network Unlock“ und die Richtlinie „Allow network unlock at startup“.
Betrieb: Updates, Recovery, Monitoring
Vor BIOS- oder Firmwareupdates wird BitLocker ausgesetzt, sonst landet das Gerät beim nächsten Start in der Wiederherstellung.
Suspend-BitLocker -MountPoint C: -RebootCount 1
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, KeyProtectorEin Sammellauf über alle Rechner, der Schutzstatus und Schutzvorrichtungen zurückgibt, genügt für den Überblick. Meldungen landen im Ereignisprotokoll Microsoft-Windows-BitLocker/BitLocker Management. Die Richtlinie „Reset platform validation data after BitLocker recovery“ verhindert, dass ein Gerät nach einer Wiederherstellung in der Schleife hängt.
Typische Fehler
Vier Ursachen erklären fast alle Supportfälle: der gesetzte Haken bei „ohne kompatibles TPM“, ein fehlgeschlagener Escrow nach einem AD-Restore, eine PIN-Policy auf Geräten ohne Ziffernblock und BitLocker auf einer VM ohne vTPM. Ein Test an drei unterschiedlichen Geräten findet alle vier rechtzeitig.
Quellen
Microsoft Learn: BitLocker konfigurieren (abgerufen am 01.11.2026)
Microsoft Learn: Netzwerkentsperrung (abgerufen am 01.11.2026)
Microsoft Learn: BitLocker CSP (Referenz der Einstellungswerte) (abgerufen am 01.11.2026)
Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.
No responses yet