Windows Server 2019/2022 absichern: LAPS, SMB‑Signing, GPO‑Härtung und PowerShell‑Restriktionen

In diesem Beitrag beschreibe ich, wie Sie Windows Server 2019/2022 absichern, mit Fokus auf vier praxisrelevante Bausteine: LAPS (Local Administrator Password Solution), SMB‑Signing (Protokoll‑Integrität), GPO‑basierte Härtung und PowerShell‑Restriktionen inklusive Logging. Das Fokus‑Keyword „Windows Server 2019/2022 absichern“ ist bewusst früh gesetzt, weil diese vier Maßnahmen zusammen einen großen Teil der Angriffsfläche in typischen Windows‑Domain‑Umgebungen reduzieren. Zielgruppe sind Administratoren, System Engineers und technische Dienstleister — die Anleitungen sind betriebsorientiert: Voraussetzungen, typische Risiken, Prüfungen, konkrete Umsetzungsschritte und Rückfallstrategien.

Windows Server 2019/2022 absichern: Warum diese vier Bausteine priorisieren?

Die genannten Maßnahmen adressieren unterschiedliche Angriffsvektoren und Betriebsanforderungen:

• LAPS reduziert das Risiko gestohlener, statischer lokaler Administratorpasswörter auf Einzelhosts.
• SMB‑Signing schützt Datei‑ und Druckverkehr vor Manipulation und Man‑in‑the‑Middle‑Angriffen auf der Protokoll‑Ebene.
• GPO‑Härtung erlaubt zentrale, konsistente Regeln für Sicherheitseinstellungen und verhindert Konfigurationsdrift.
• PowerShell‑Restriktionen und Logging verringern Missbrauchsmöglichkeiten der mächtigen Shell und liefern forensische Telemetrie.

Alle Maßnahmen zusammen verbessern Vertraulichkeit, Integrität und Nachvollziehbarkeit — wichtig für Compliance und Incident Response.

Plan und Vorgehensweise

Härten Sie produktive Server niemals blind. Meine empfohlene Reihenfolge:

1. Inventarisierung und Risikoanalyse: Welche Server, welche Clients, welche Legacy‑Services (NAS, Drucker, Backup‑Appliances) sind betroffen?
2. Testumgebung: Stellen Sie Pilot‑OUs (Organizational Units) bereit, in denen Sie Änderungen prüfen.
3. Scripting und Automation: Nutzen Sie reproduzierbare PowerShell‑Skripte und GPO‑Backups für Rollbacks.
4. Monitor & Validate: Aktivieren Sie Logging und überwachen Sie Auswirkungen vor dem Rollout.
5. Rollout gestaffelt: OU‑weise, Serverrollen priorisieren (Domain Controller, File‑Server, Anwendungsserver).

LAPS: Lokale Administratorpasswörter sicher verwalten

Was ist LAPS? LAPS ist Microsofts Lösung, um lokale Administratorpasswörter individuell, zyklisch und sicher in Active Directory zu verwalten. Technisch speichert LAPS Passwörter in einem geschützten AD‑Attribut (z. B. ms‑Mcs‑AdmPwd) und setzt ACLs, damit nur berechtigte Konten lesen dürfen. Vorteil: Keine statischen, geteilten Kennwörter mehr, wodurch laterale Bewegung deutlich erschwert wird.

Voraussetzungen und Risiken

• Active Directory mit Schreibrechten für Schemaänderung, falls Sie die Schemaerweiterung einsetzen. (Bei klassischen LAPS ist eine Schemaänderung nötig.)
• Client‑Seite: LAPS‑Agent oder CSE (Client Side Extension) muss auf Servern/Clients installiert werden.
• Risiko: Wenn ACLs falsch gesetzt werden, können unberechtigte Konten Passwörter lesen. Testen Sie Berechtigungen gründlich.

Implementationsschritte (Praxis)

1. LAPS‑MSI installieren (für Management‑Workstation) und das AD‑Schema aktualisieren.

# Beispiel: LAPS Modul installieren (Admin-Rechner)
Install-Package -Name LAPS -ProviderName Programs -Scope CurrentUser

2. Schema erweitern (nur mit Schema‑Admin‑Rechten). Diese Aktion ist einmalig und muss getestet werden.

# Schema erweitern (erfordert Schema Admins und entsprechend vorbereitete MSI/Module)
Import-Module AdmPwd.PS
Update-AdmPwdADSchema

3. Setzen Sie die Computer‑Selbstberechtigung, damit Clients ihre Passwörter selbst schreiben können.

# Computer erlauben, ihr eigenes Kennwort zu setzen
Set-AdmPwdComputerSelfPermission -OrgUnit 'OU=Servers,DC=contoso,DC=local'

4. Delegieren Sie Leserechte an Helpdesk/Privilegierte Gruppen.

# Leseberechtigungen für eine Benutzergruppe hinzufügen
Add-AdmPwdReadPasswordPermission -Identity 'OU=Servers,DC=contoso,DC=local' -AllowedPrincipals 'CONTOSOHelpdesk'
# Optionell: Erlauben Password-Expiration-Reset durch Gruppe
Set-AdmPwdPasswordProtection -AllowedPrincipals 'CONTOSOHelpdesk' -PasswordAgeDays 14

5. GPO verteilen: Konfigurieren Sie Passwortkomplexität, Länge und Rotationsintervall in der LAPS‑GPO.

Prüfschritte und Troubleshooting

• Prüfen, ob das AD‑Attribut gefüllt ist: Verwenden Sie ADSIEdit oder PowerShell‑Cmdlets aus dem LAPS‑Modul.
• Überprüfen Sie ACLs mit Get-AdmPwdReadPasswordPermission.
• Falls keine Werte geschrieben werden: Prüfen Sie Client‑Agent, GPO‑Anwendung (gpresult) und Berechtigungen.

Rollback und Notfallzugang

Behalten Sie einen dokumentierten Notfallzugang (z. B. speziell delegiertes Konto oder Vault) für kritische Server, bevor Sie LAPS ausrollen. Wenn GPOs fehlschlagen, können Sie LAPS auf dem betroffenen Server deinstallieren und temporär ein Serviceaccount‑Passwort verwenden — dokumentieren Sie jede Ausnahme.

SMB‑Signing: Integrität für Datei‑ und Druckverkehr

SMB‑Signing sorgt dafür, dass SMB‑Pakete zwischen Client und Server kryptographisch signiert werden. Das schützt vor Manipulation und bestimmten Man‑in‑the‑Middle‑Angriffen. In modernen Umgebungen sollten Sie SMBv1 deaktivieren und SMB‑Signing für SMBv2/v3 verwenden, wo es möglich ist.

Voraussetzungen und Auswirkungen

SMB‑Signing ist größtenteils kompatibel mit Windows Server 2019/2022, kann aber Legacy‑Geräte (ältere NAS, Drucker, Backup‑Appliances) stören. Testen Sie in einer Labor‑OU. Performanceeinbußen sind in der Regel moderat, bei hohem I/O‑Durchsatz oder vielen kleinen Dateien sollten Sie Lasttests durchführen. Wenn Ihre Storage‑Appliances SMB‑Signing nicht unterstützen, planen Sie Ausnahmen oder Firmware‑Updates ein.

Praktische Befehle und GPO‑Einstellungen

GPO‑Pfad (Security Options):

• Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → „Microsoft network client: Digitally sign communications (always)“
• Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → „Microsoft network server: Digitally sign communications (always)“

Über PowerShell prüfen / setzen:

# Prüfen SMB-Serverkonfiguration
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature

# Erforderliche Signatur erzwingen (Server)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# Prüfen SMB-Clientkonfiguration
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature

# Erforderliche Signatur erzwingen (Client)
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

Testen und Rollout

1. Aktivieren Sie zuerst auf Pilot‑File‑Servern und testen Dateizugriffe von verschiedenen Client‑Betriebssystemen.
2. Überwachen Sie Fehlermeldungen in der Ereignisanzeige (System/Application) und auf Clients.
3. Für nicht kompatible Geräte: White‑Listing per IP/Firewall oder spezieller GPO mit Ausnahme‑OU.

Typische Stolperfallen

• Backup‑Software oder Agenten, die SMBv1 nutzen — prüfen und aktualisieren.
• SMB‑Signing und Verschlüsselung (SMB Encryption) sind nicht das gleiche: Signing schützt Integrität, Encryption schützt Vertraulichkeit.

GPO‑Härtung: Baselines, Testing und Policy‑Management

Gruppenrichtlinien (GPO) sind das zentrale Hebelwerkzeug für Windows‑Konfigurationen. Eine saubere GPO‑Strategie verhindert Drift, erleichtert Audits und beschleunigt Incident Response.

Wichtige GPO‑Bausteine

• Sicherheitsoptionen: LM/NTLM deaktivieren wo möglich, SMBv1 deaktivieren, Richtlinien für LAN Manager und NTLM‑Restriktionen.
• Account‑Policies: Komplexität, maximale Passwortdauer, Lockout‑Policy.
• User Rights Assignments: Wer darf sich lokal anmelden, Remote Desktop, Batch‑Jobs, Dienste installieren.
• Administrative Templates: UAC‑Härtung, Windows Update Konfiguration, Telemetrie‑Einstellungen.
• Firewall und Windows Defender ATP / EDR‑Integrationen.

Praxis: Deaktivieren von SMBv1 und NTLM‑Einschränkungen

# SMBv1 deaktivieren (remot/auf local machine)
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol -NoRestart

# NTLM-Restriktionen via GPO sind zu bevorzugen; lokal prüfen:
# Zeigt aktuelle NTLM Einstellungen (nur Beispielwert):
Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlLsa' -Name LmCompatibilityLevel

Für NTLM empfiehlt sich ein gestaffeltes Konzept: Monitoring → Warnung → Blocken. Einige Applikationen benötigen NTLM weiterhin; führen Sie eine NTLM‑Map und Ausnahmenliste.

Verwaltung, Testing und Rollback

Nutzen Sie folgende Werkzeuge:

• Group Policy Management Console (GPMC) mit Modeling und Results (gpresult /h report.html).
• Automatisierte Testscripts, die essentielle Dienste nach GPO‑Anwendung prüfen (SMB‑Mounts, Dienste, geplante Tasks).
• Versionierung: Exportieren Sie GPOs als Backup vor Änderungen.

# GPO Backup Beispiel
Import-Module GroupPolicy
Backup-GPO -Name 'Security Baseline - Servers' -Path 'C:GPO-Backups'

# GPO Restore Beispiel
Restore-GPO -Name 'Security Baseline - Servers' -Path 'C:GPO-Backups' -Force

PowerShell‑Restriktionen und Logging: Kontrolle und Nachvollziehbarkeit

PowerShell ist ein mächtiges Werkzeug — das macht es auch zum Angriffsvektor. Entscheidend sind: richtige Durchsetzungsmethoden (Execution Policy ist KEINE Sicherheitsgrenze), strenge Whitelist‑Kontrolle (AppLocker/WDAC) und umfangreiches Logging (ScriptBlock, ModuleLogging, Transcription).

Warum Execution Policy allein nicht reicht

Die PowerShell Execution Policy (Set‑ExecutionPolicy) ist eine Einstellungs‑Präferenz. Sie ist kein Security‑Boundary, weil sie per Benutzer mit ausreichenden Rechten umgangen werden kann. Für echte Durchsetzung verwenden Sie AppLocker (Application Control) oder Windows Defender Application Control (WDAC), die in einer Enterprise‑Umgebung gerätespezifisch Richtlinien erzwingen.

Konkrete Einstellungen: Logging und Prüfung

Aktivieren Sie zentral die folgenden Telemetrien via GPO oder Registry, um forensische Informationen zu erhalten:

• Script Block Logging: zeichnet ausgeführte Skriptinhalte auf (wichtig für Erkennung).
• Module Logging: protokolliert geladene Module und Befehle.
• PowerShell Transcription: vollständige Sitzungsabschriften.

# Aktivieren von ScriptBlockLogging per Registry (Beispiel, via GPO bevorzugt)
New-Item -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging' -Name 'EnableScriptBlockLogging' -Value 1 -Type DWord

# Aktivieren von ModuleLogging
New-Item -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLogging' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLogging' -Name 'EnableModuleLogging' -Value 1 -Type DWord
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLogging' -Name 'ModuleNames' -Value '*' -Type MultiString

# Aktivieren von Transcription
New-Item -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellTranscription' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellTranscription' -Name 'EnableTranscripting' -Value 1 -Type DWord
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellTranscription' -Name 'OutputDirectory' -Value 'C:ProgramDataPowerShellTranscripts' -Type ExpandString

Prüfen der aktuellen Sprachmodus‑Einstellung

# Gibt den aktuellen PowerShell-Sprachmodus zurück (ConstrainedLanguage, FullLanguage, etc.)
$ExecutionContext.SessionState.LanguageMode

AppLocker oder WDAC einsetzen

Für strikte Durchsetzung verwenden Sie AppLocker (filtert nach Publisher, Pfad, Hash) oder WDAC für kernelnah durchgesetzte Policies. Beide Lösungen erfordern Testszenarien, da sie produktive Workloads leicht unterbrechen können. Vorgehen:

1. Audit‑Modus (AppLocker/WDAC) für 2–4 Wochen, Sammeln von Events.
2. Whitelist‑Regeln erstellen (signierte Skripte, Verwaltungstools) und schrittweise in Enforce‑Modus überführen.
3. Fallback‑Plan: GPO mit deaktivierter Regelanwendergruppe oder Boot‑Optionen, wenn kritische Dienste ausfallen.

Hardware: NAS, Backup‑Appliances und Drucker — besondere Vorsicht

Hardware‑Geräte wie NAS, ältere Drucker und Backup‑Appliances sind häufig Kompatibilitätsfallen. Viele Geräte implementieren SMB unvollständig oder nutzen veraltete Dialekte. Prüfen und dokumentieren Sie diese Geräte vor einem großflächigen Sicherheitshärtungsprojekt.

Checklist: Hardware‑Kompatibilität prüfen

• Herstellerdokumentation prüfen: Unterstützte SMB‑Dialekte und Signing/Encryption‑Support.
• Firmware‑Stand: Veraltete Firmware ist häufig die Ursache für fehlende SMB‑Features.
• Testklinik: Verbinden Sie ein Test‑Client mit Signing aktiviert und prüfen Sie Dateitransfers.
• Fallback‑Option: VLAN oder Firewall‑Regel, die Legacy‑Geräte separat und kontrolliert weiterbetreibt.

Praktisches Prüftool: SMB‑Dialekt und Session‑Details

# Auf dem Client: zeigt verhandelte SMB-Dialekte
Get-SmbConnection | Select-Object -Property ServerName,ShareName,Dialect

# Auf dem Server: zeigt angemeldete SMB Sessions
Get-SmbSession | Select-Object -Property ClientComputerName,ClientUserName,Dialect

Wenn ein Gerät nur SMBv1 anbietet, planen Sie Austausch oder Netzwerkslicing, da SMBv1 aktiv erhebliche Risiken bringt.

Monitoring, SIEM und Log‑Retention

Härtung hat nur dann praktische Wirkung, wenn Abweichungen erkannt werden. Richten Sie Event‑Forwarding oder einen Agenten (z. B. NXLog, Winlogbeat) ein, um kritische Events an SIEM zu senden.

Wichtige Event‑IDs und Quellen

• PowerShell: 4103, 4104 (ScriptBlock Logging), 4105 (Module Logging).
• SMB/Server: Ereignisse unter Microsoft‑Windows‑SMBServer/Operational — Verbindungsfehler, Signatur‑Verletzungen.
• AD/LAPS: AD‑Audit‑Events bei Lesezugriffen auf ms‑Mcs‑AdmPwd (wenn AD‑Auditing aktiviert ist).

Retention und Speicher

PowerShell‑Transkripte und ScriptBlock‑Logs können sehr groß werden. Planen Sie Speicherplatz, Drehscheiben (z. B. zentraler Log‑Share oder SIEM), und Retention‑Policies (z. B. 90 Tage aktiv, Langzeitarchiv 1 Jahr). Nutzen Sie Komprimierung und Indexierung im SIEM, um Suchkosten zu reduzieren.

Konkretes Mini‑Runbook: Wenn nach GPO‑Rollout Dienste ausfallen

1. Scope eingrenzen: Identifizieren Sie betroffene OU/Hosts (gpresult, Eventlogs).
2. Sofortmaßnahme: GPO‑Link temporär deaktivieren für die betroffene OU in der GPMC.
3. Rollback: Restore‑GPO aus Backup oder reapply vorherige Backup‑GPO.
4. Zugriff: Bei Authentifizierungsproblemen lokale Konsole nutzen oder Wartungs‑Account aus Vault abrufen.
5. Nachbearbeitung: Ursache analysieren, Fix testen, dokumentieren und erneut in Pilot einspielen.

Letzte Prüfungen und Betriebswissen

Vor dem großflächigen Rollout prüfen Sie: GPO‑Backups vorhanden? LAPS‑Delegation korrekt? SIEM‑Pipelines aktiv? Backup‑Appliances kompatibel? Halten Sie ein klar dokumentiertes Change‑Fenster und einen Kommunikationsplan mit Betrieb und Applikationsteams bereit.

Fazit

Windows Server 2019/2022 absichern ist kein einzelner Schalter, sondern ein abgestuftes Projekt: LAPS reduziert Credential‑Risiko, SMB‑Signing erhöht Protokoll‑Integrität, GPO‑Härtung schafft zentrale Konsistenz, und PowerShell‑Restriktionen plus Logging ermöglichen Kontrolle und Forensik. In der Praxis zahlen sich strukturierte Tests, Pilot‑Rollouts und ein klarer Rollback‑Plan aus. Implementieren Sie die Maßnahmen schrittweise, messen Sie Auswirkungen und automatisieren Sie Prüfungen. So erreichen Sie langfristig sicheren Betrieb ohne unnötige Serviceausfälle.

Diese Anleitung lässt sich als Basis für ein internes Runbook oder Angebot nutzen; sie enthält die wichtigsten Prüf‑ und Rückfallmechanismen, die in realen Projekten Sicherheit und Verfügbarkeit in Einklang bringen.

Für dieses Thema sind auch Laps Installieren und Smb Signing Aktivieren wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.