Konfigurationsdrift: OSConfig, DSC und Compliance-Berichte

Eine Baseline anzuwenden ist eine Momentaufnahme. Danach lockern Software-Installer Einstellungen, die ihnen nicht gefallen, Administratoren nehmen während eines Vorfalls „vorübergehende“ Änderungen vor, Skripte eines Herstellers kippen einen Registrierungswert, und bei einer Umstrukturierung wird die Verknüpfung eines GPOs aufgehoben. Sechs Monate später entspricht der Rechner nicht mehr der Baseline, die Sie dem Prüfer gezeigt haben. Diese Lücke ist Konfigurationsdrift.

Der Grundlagenartikel zu Sicherheitsbaselines hat OSConfig als eine Möglichkeit vorgestellt, eine Baseline dauerhaft durchzusetzen. Dieser Leitfaden behandelt Drift als Ganzes: die unter Windows verfügbaren Korrektur-Engines (OSConfig, Gruppenrichtlinie, PowerShell DSC, Intune), wie Sie Änderungen in dem Moment erkennen, in dem sie geschehen, und wie Sie über die gesamte Flotte über die Compliance berichten.

Woher Drift kommt und was sie korrigiert

Jede Geräteklasse sollte genau eine Engine haben, die für ihre Sicherheitskonfiguration zuständig ist, plus ein unabhängiges Reporting, um die Fälle zu erkennen, in denen die Engine selbst defekt ist oder umgangen wird.

Schritt 1: die Gruppenrichtlinie erneut anwenden lassen, wofür sie zuständig ist

Ist die Gruppenrichtlinie zuständig, schließen Sie die Lücke bei der Neuverarbeitung. Unter Computer Configuration > Policies > Administrative Templates > System > Group Policy:

• Configure registry policy processing (Verarbeitung der Registrierungsrichtlinie konfigurieren): Enabled, Process even if the Group Policy objects have not changed aktivieren.
• Configure security policy processing: Enabled, gleiche Option.

Damit wird eine lokale Änderung an einer Einstellung aus administrativen Vorlagen bei der nächsten Hintergrundaktualisierung überschrieben (standardmäßig 90 Minuten plus zufälliger Versatz), statt zu überdauern, bis jemand das GPO bearbeitet. Die Microsoft-Baseline aktiviert die Neuverarbeitung der Registrierungsrichtlinie bereits; bestätigen Sie, dass sie nicht entfernt wurde.

Das hilft nicht bei Einstellungen, die kein GPO definiert, bei Rechnern außerhalb der Domäne oder bei GPOs, die nicht mehr greifen. Dafür gibt es das Reporting.

Schritt 2: OSConfig unter Windows Server 2025

OSConfig wendet Microsofts Sicherheitsbaselines für Windows Server 2025 als benannte Szenarien an, erzwingt sie und berichtet darüber. Installieren Sie das Modul aus der PowerShell Gallery und wenden Sie das Szenario an, das zur Rolle des Servers passt:

Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force

# Eines von: SecurityBaseline/WindowsServer/2025/MemberServer, /DomainController, /WorkgroupMember
Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer -Default
Restart-Computer

Ergänzende Szenarien werden genauso angewendet: SecuredCore, Defender/Antivirus/WindowsServer/2025 und, nur auf Mitgliedsservern, LAPS/WindowsServer/2025/MemberServer. OSConfig hat außerdem ein Szenario für App Control for Business. Das Anwenden oder Entfernen einer Baseline erfordert einen Neustart. Die Baseline-Version ist im Modul enthalten; Update-Module Microsoft.OSConfig mit anschließender erneuter Anwendung des Szenarios hebt einen Server auf die neue Baseline.

Um eine Einstellung vom Standard abweichend zu setzen, etwa passend zu einem Eintrag in Ihrem Abweichungsregister, setzen Sie sie per Namen, statt die Registrierung zu bearbeiten, damit die Driftkontrolle Ihren Wert durchsetzt, statt gegen ihn zu arbeiten:

Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
  Where-Object Name -like '*Audit*' | Select-Object Name, Value

Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer `
  -Setting AuditDetailedFileShare -Value 3

Einen einzelnen angepassten Wert prüfen Sie mit Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer -Setting AuditDetailedFileShare.

Die Driftkontrolle läuft als geplante Aktualisierungsaufgabe, die jede Einstellung mit dem Sollwert vergleicht und sie bei einer Änderung zurücksetzt. Die aktuelle Microsoft-Dokumentation nennt das Intervall nicht (frühere Versionen gaben vier Stunden an); messen Sie es daher in Ihrem Pilot, statt es anzunehmen. Das Entfernen eines Szenarios mit Remove-OSConfigDesiredConfiguration beendet die Durchsetzung, und laut Microsoft ist nicht garantiert, dass die Einstellungen zu ihren Werten vor der Baseline zurückkehren; erstellen Sie daher auf Servern, bei denen Sie eventuell zurückrollen müssen, vorher eine Momentaufnahme der ursprünglichen Konfiguration.

Legen Sie auf domänengebundenen Servern fest, wer für die Baseline zuständig ist. Wenden Ihre Domänen-GPOs dieselbe Microsoft-Baseline an, vermeiden Sie eine doppelte Durchsetzung: Behalten Sie entweder die GPOs und nutzen Sie das OSConfig-Reporting nur auf einer Stichprobe, oder verlagern Sie die Baseline zu OSConfig und entfernen diese Einstellungen aus den Server-GPOs. Domänencontroller verdienen besondere Sorgfalt, da eine widersprüchliche Zuweisung von Benutzerrechten Replikation oder Anmeldungen brechen kann; pilotieren Sie zuerst auf einem DC.

Schritt 3: PowerShell DSC für alles andere

Für Einstellungen, die keine Baseline abdeckt, oder für ältere Server kann Desired State Configuration aus Windows PowerShell 5.1 durchsetzen und berichten. Konfigurieren Sie den Local Configuration Manager (LCM) für die Autokorrektur:

[DSCLocalConfigurationManager()]
configuration LcmAutoCorrect {
  Node localhost {
    Settings {
      RefreshMode                    = 'Push'
      ConfigurationMode              = 'ApplyAndAutoCorrect'
      ConfigurationModeFrequencyMins = 30
    }
  }
}
LcmAutoCorrect -OutputPath C:\DSC\Lcm
Set-DscLocalConfigurationManager -Path C:\DSC\Lcm -Verbose

Dann eine Konfiguration mit den Einstellungen, für die Sie zuständig sind. Die integrierte Ressource Registry reicht für viele Härtungswerte:

configuration HardeningExtras {
  Import-DscResource -ModuleName PSDesiredStateConfiguration
  Node localhost {
    Registry DisableLLMNR {
      Key       = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient'
      ValueName = 'EnableMulticast'
      ValueData = '0'
      ValueType = 'Dword'
      Ensure    = 'Present'
    }
  }
}
HardeningExtras -OutputPath C:\DSC\Hardening
Start-DscConfiguration -Path C:\DSC\Hardening -Wait -Verbose

Community-Module wie SecurityPolicyDsc und AuditPolicyDsc decken Benutzerrechte, Sicherheitsoptionen und Überwachungsunterkategorien ab, und das Modul BaselineManagement kann eine GPO-Sicherung in eine DSC-Konfiguration umwandeln. Das neuere Microsoft DSC (Version 3) ist ein separates, plattformübergreifendes Werkzeug mit anderem Modell; bewerten Sie es gesondert, statt es mit dem LCM zu mischen.

Die DSC-Konfigurationsdateien (.mof) können sensible Daten enthalten, und der LCM läuft als SYSTEM; speichern Sie sie daher an einem geschützten Ort und beschränken Sie, wer Konfigurationen verteilen darf, so wie Sie auch die GPO-Bearbeitung beschränken würden (siehe Admin-Tiering).

Schritt 4: Änderungen erkennen, während sie geschehen

Korrektur-Engines verbergen Drift, indem sie sie beheben. Sie wollen aber auch wissen, dass sie passiert ist, denn eine Einstellung, die immer wieder umspringt, bedeutet meist, dass jemand oder etwas gegen Sie arbeitet. Aktivieren Sie die relevanten Überwachungsunterkategorien (siehe Überwachungsrichtlinie und Sysmon) und leiten Sie diese Ereignisse weiter:

Fügen Sie für einige besonders wertvolle Registrierungsschlüssel (zum Beispiel LSA-Einstellungen unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa) eine Überwachungs-SACL hinzu, damit bei Änderungen 4657 ausgelöst wird. Sysmon-Ereignis 13 (Registrierungswert gesetzt) mit einer gezielten Konfiguration ist eine Alternative. Leiten Sie alles per Windows Event Forwarding an Ihr SIEM weiter und alarmieren Sie bei Änderungen außerhalb von Änderungsfenstern.

Schritt 5: Compliance über die gesamte Flotte berichten

Die Durchsetzung sagt jedem Rechner, was er tun soll; das Reporting sagt Ihnen, ob es funktioniert hat. Für Windows Server 2025 mit OSConfig erfassen Sie die Compliance pro Einstellung remote:

$servers = Get-Content C:\Reports\ws2025-servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
  Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
    Select-Object Name,
      @{n='Status';e={$_.Compliance.Status}},
      @{n='Reason';e={$_.Compliance.Reason}}
} | Select-Object PSComputerName, Name, Status, Reason |
  Export-Csv "C:\Reports\osconfig-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

Bei per DSC verwalteten Knoten liefert Test-DscConfiguration -Detailed die Ressourcen im und außerhalb des Sollzustands, und Get-DscConfigurationStatus zeigt den letzten Lauf. Lokale Prüfwerkzeuge wie secedit /analyze /db C:\Temp\bl.sdb /cfg C:\Baseline\GptTmpl.inf /log C:\Temp\analyze.log vergleichen Sicherheitseinstellungen mit einer Vorlage. Der Vergleich des effektiven Zustands in Policy Analyzer (siehe Policy Analyzer und LGPO) deckt Stichproben von Clients ab. Im großen Maßstab liefern die Berichte pro Einstellung in Intune, Azure Machine Configuration für mit Arc verbundene Server und die Bewertung von Sicherheitsbaselines in Defender Vulnerability Management (lizenzabhängig) eine zentrale Sicht.

Verfolgen Sie pro Geräteklasse drei Kennzahlen: Anteil konformer Einstellungen, Anzahl der Geräte mit mindestens einer nicht konformen Hochrisiko-Einstellung und Einstellungen, die wiederholt abweichen.

Überprüfung

Weisen Sie auf einem Pilotserver nach, dass der Korrekturkreislauf funktioniert: Ändern Sie eine durchgesetzte Einstellung von Hand, warten Sie auf die nächste Aktualisierung und bestätigen Sie, dass sie zurückgesetzt wurde.

Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WindowsServer/2025/MemberServer |
  Where-Object { $_.Compliance.Status -ne 'Compliant' } |
  Format-Table Name, @{n='Reason';e={$_.Compliance.Reason}} -Wrap

Test-DscConfiguration -Detailed | Select-Object -ExpandProperty ResourcesNotInDesiredState
Get-WinEvent -LogName 'Microsoft-Windows-DSC/Operational' -MaxEvents 20

Bestätigen Sie auch, dass das Änderungsereignis Ihr SIEM erreicht hat. Eine Driftkorrektur, die niemand gesehen hat, ist trotzdem ein verpasstes Signal.

Was kaputtgeht

• Zwei Engines, eine Einstellung. GPO und OSConfig oder Intune und DSC, die unterschiedliche Werte erzwingen, erzeugen flatternde Einstellungen und verwirrende Berichte.
• Legitime Änderungen zurückgesetzt. Eine von Hand vorgenommene Notfallkorrektur wird bei der nächsten Aktualisierung rückgängig gemacht. Nehmen Sie Änderungen über die Engine vor, nicht an ihr vorbei.
• Verlorene Baseline-Ausnahmen. Außerhalb der Engine vorgenommene Anpassungen verschwinden. Halten Sie sie in der Konfiguration der Engine und im Abweichungsregister fest.
• Veraltete Berichte. Ein Gerät, das keine Berichte mehr sendet, erscheint in manchen Dashboards als konform. Alarmieren Sie bei fehlenden Berichten, nicht nur bei Fehlern.

Checkliste

• Eine Durchsetzungs-Engine pro Geräteklasse gewählt
• Verarbeitung von Registrierungs- und Sicherheitsrichtlinien so eingestellt, dass unveränderte GPOs erneut angewendet werden
• OSConfig-Baseline-Szenario unter Windows Server 2025 nach Rolle angewendet
• Abweichungen über OSConfig oder DSC angewendet, nicht von Hand
• DSC-LCM im Modus ApplyAndAutoCorrect für Einstellungen außerhalb der Baseline
• Änderungsereignisse (4719, 4739, 5136, 4657) weitergeleitet und alarmiert
• Compliance-Bericht für die Flotte erstellt und monatlich geprüft
• Korrekturkreislauf durch bewusste Änderung einer Einstellung getestet

Driftmanagement sorgt dafür, dass eine Baseline auch nach Projektende stimmt. Im gesamten Bereich Sicherheitsbaselines erfahren Sie, wie Sie Baselines überhaupt erst auswählen, testen und verteilen.