MBAM Gruppenrichtlinien mit PowerShell auf dem Client überprüfen

Wir erklären, wo sich die MBAM-Registry-Schlüssel verstecken und wie wir sie in unseren Tests für einen stabilen MBAM-Betrieb nutzen können.

Kommen die Gruppenrichtlinien wirklich an?

Auf dem Client kümmert sich MBAM darum, dass Bitlocker entsprechend den Vorgaben aktiviert und verwendet, dass Recovery Keys zur Wiederherstellung im Fehlerfall  übermittelt und Statusmeldungen zur Überwachung an das Backend gesendet werden. Das alles wird über die Gruppenrichtlinien (GPO) gesteuert und gesetzt.

Wie überprüfen wir, ob die gesetzten GPO auch tatsächlich auf dem Client ankommen und Verwendung finden? Mit unserem MBAM Test Automation Package.

Undocumented Features: Registry-Schlüssel, die durch MBAM-Gruppenrichtlinien auf dem Client gesetzt werden

Jede gesetzte Gruppenrichtlinie führt auf Client-Seite zu einem Registry-Schlüssel oder sogar zu mehreren Registry-Schlüsseln. Wo finden sich diese Schlüssel? Und welche Werte sind zulässig?

Für MBAM 2.5 SP1 finden sich die unterschiedlichen Werte in folgenden Zweigen der Registry:

  • HKLM\Software\Policies\Microsoft\FVE
  • HKLM\Software\Policies\Microsoft\FVE\MDOPBitLockerManagement
  • HKLM\Software\Policies\Microsoft\FVE\OSPlatformValidation_BIOS
  • HKLM\Software\Policies\Microsoft\FVE\PlatformValidation
  • HKLM\Software\Policies\Microsoft\FVE\OSPlatformValidation_UEFI
  • HKLM\System\CurrentControlSet\Policies\Microsoft\FVE

Da bei einigen Einstellungen unter Umständen mehrere Registry-Schlüssel erzeugt werden, können so über 150 verschiedene Einträge zusammenkommen, sofern alle Optionen über die MDOP MBAM Admx-Templates gesetzt sind.

Wer sich für die einzelnen Werte interessiert, kann sich die Datei gpo_template.xml in unserem Paket MBAM Test Automation Package ansehen. Dort sind alle möglichen Einträge und deren Werte erfasst.

Mit Hilfe dieser Datei können wir auch überprüfen, ob die als GPO gesetzten Einstellungen tatsächlich auf dem Client ankommen und dort in der Registry landen. Hierzu muss nur der entsprechende Eintrag in der Datei bearbeitet und mit dem korrekten Wert versehen werden. Alle Einträge sind nach identischer Struktur aufgebaut – nämlich so:

Wichtig sind die beiden Knoten <PolicyState> und <PolicyValue>. Setzt man den Wert auf Enabled im Knoten <PolicyState>, wird die entsprechende Regel aktiviert. Das bedeutet, sie wird beim Test berücksichtigt. Bleibt der Wert auf Disabled, wird die Regel bei der Überprüfung ausgelassen.

Mittels <PolicyValue> wird der zu erwartende Wert der Registry-Variable festgelegt. Das kann ein String sein (z.B. für die HTTP-Adresse), unter dieser der Client den Service für die Statusmeldung findet. Es kann sich auch um eine Zahl handeln, beispielsweise für die Länge des TPM Pins. Entsprechend gültige Werte sind in der Templatedatei gpo_template.xml über den jeweiligen Regeln dokumentiert.

Sind alle notwendigen Einstellungen in der Datei erfasst, können wir mit dem PowerShell-Befehl Test-MbamGpos aus dem MBAM Test Automation Package unter Angabe des Speicherorts der XML-Datei über den Parameter -source alle Einstellung der MBAM-GPOs in einem Rutsch überprüfen.

Übrigens: Ist die gpo_template.xml einmal an die unternehmenseigenen Einstellungen angepasst, kann diese auch im Report-Script Get-CompleteClientStatus.ps1 aus dem MBAM Test Automation Package genutzt werden, indem die Funktion im Script freigeschaltet (Tipp: Kommentarzeichen entfernen) und im Konfigurationsabschnitt der Pfad zur XML-Datei eingetragen wird. Damit landen die Ergebnisse des GPO-Tests auch direkt im HTML-Report.

Ähnliche Beiträge:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.