Sécuriser Windows Server 2019/2022 : LAPS, SMB‑Signing, durcissement des GPO et RESTrictions PowerShell

Dans cet article, je décris comment sécuriser des Windows Server 2019/2022, en mettant l’accent sur quatre volets pragmatiques : LAPS (Local Administrator Password Solution), SMB‑Signing (intégrité du protocole), durcissement basé sur GPO et RESTrictions PowerShell incluant la journalisation. Le mot‑clé principal « Windows Server 2019/2022 absichern » est placé volontairement tôt, car ces quatre mesures réduisent conjointement une grande partie de la surface d’attaque dans des environnements de domaine Windows typiques. Le public visé comprend les administrateurs, ingénieurs systèmes et pRESTataires techniques — les instructions sont orientées exploitation : prérequis, risques typiques, contrôles, étapes de mise en œuvre concrètes et stratégies de retour en arrière.

Windows Server 2019/2022 absichern: Pourquoi prioriser ces quatre volets ?

Les mesures mentionnées traitent différents vecteurs d’attaque et exigences opérationnelles :

• LAPS réduit le risque de mots de passe locaux d’administrateur statiques et volés sur des hôtes individuels.
• SMB‑Signing protège le trafic de fichiers et d’impression contre la manipulation et les attaques man‑in‑the‑middle au niveau du protocole.
• Le durcissement via GPO permet des règles centralisées et cohérentes pour les paramètres de sécurité et empêche la dérive de configuration.
• Les RESTrictions PowerShell et la journalisation réduisent les possibilités d’abus de la puissante shell et fournissent de la télémétrie forensique.

L’ensemble des mesures améliore la confidentialité, l’intégrité et la traçabilité — important pour la conformité et la réponse aux incidents.

Plan und Vorgehensweise

Ne durcissez jamais des serveurs en production à l’aveugle. Mon ordre recommandé :

1. Inventaire et analyse de risque : quels serveurs, quels clients, quels services legacy (NAS, imprimantes, appliances de sauvegarde) sont concernés ?
2. Environnement de test : déployez des OU pilotes (Organizational Units) dans lesquelles vous pouvez valider les modifications.
3. Scripting et automatisation : utilisez des scripts PowerShell reproductibles et des sauvegardes de GPO pour les retours en arrière.
4. Surveillance et validation : activez la journalisation et surveillez les impacts avant le déploiement.
5. Déploiement échelonné : par OU, prioriser les rôles serveur (Domain Controller, File‑Server, serveurs applicatifs).

LAPS: Lokale Administratorpasswörter sicher verwalten

Qu’est‑ce que LAPS ? LAPS est la solution de Microsoft pour gérer les mots de passe locaux d’administrateur de manière individuelle, cyclique et sécurisée dans Active Directory. Techniquement, LAPS stocke les mots de passe dans un attribut AD protégé (p. ex. ms‑Mcs‑AdmPwd) et applique des ACL afin que seuls des comptes autorisés puissent les lire. Avantage : plus de mots de passe statiques et partagés, ce qui complique fortement le mouvement latéral.

Voraussetzungen und Risiken

• Active Directory avec droits d’écriture pour la modification du schéma, si vous utilisez l’extension du schéma. (Pour le LAPS classique, une modification du schéma est nécessaire.)
• Côté client : l’agent LAPS ou la CSE (Client Side Extension) doit être installé sur les serveurs/clients.
• Risque : si les ACL sont mal configurées, des comptes non autorisés peuvent lire les mots de passe. Testez les autorisations de façon approfondie.

Implementationsschritte (Praxis)

1. Installer le MSI LAPS (pour la station de gestion) et mettre à jour le schéma AD.

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

2. Étendre le schéma (uniquement avec des droits Schema‑Admin). Cette action est unique et doit être testée.

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

3. Attribuez l’autorisation pour que les ordinateurs puissent définir leur propre mot de passe, afin que les clients puissent écrire leurs mots de passe eux‑mêmes.

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

4. Déléguez des droits de lecture aux groupes Helpdesk/privilégiés.

# 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: configurez la complexité du mot de passe, la longueur et l’intervalle de rotation dans la GPO LAPS.

Étapes de vérification et dépannage

• Vérifiez si l’attribut AD est rempli : utilisez ADSIEdit ou les cmdlets PowerShell du module LAPS.
• Contrôlez les ACL avec Get-AdmPwdReadPasswordPermission.
• Si aucune valeur n’est écrite : vérifiez l’agent client, l’application de la GPO (gpresult) et les permissions.

Retour en arrière et accès d’urgence

Conservez un accès d’urgence documenté (p. ex. compte spécialement délégué ou coffre) pour les serveurs critiques avant de déployer LAPS. Si les GPO échouent, vous pouvez désinstaller LAPS sur le serveur concerné et utiliser temporairement le mot de passe d’un compte de service — documentez chaque exception.

SMB‑Signing : intégrité pour le trafic de fichiers et d’impression

SMB‑Signing garantit que les paquets SMB entre le client et le serveur sont signés cryptographiquement. Cela protège contre la manipulation et certaines attaques man‑in‑the‑middle. Dans des environnements modernes, vous devriez désactiver SMBv1 et utiliser SMB‑Signing pour SMBv2/v3 lorsque cela est possible.

Prérequis et impacts

SMB‑Signing est en grande partie compatible avec Windows Server 2019/2022, mais peut perturber des équipements hérités (NAS plus anciens, imprimantes, appliances de sauvegarde). Testez dans une OU de laboratoire. Les pertes de performance sont généralement modérées ; en cas de fort débit I/O ou de nombreux petits fichiers, effectuez des tests de charge. Si vos appliances de stockage ne prennent pas en charge SMB‑Signing, prévoyez des exceptions ou des mises à jour de firmware.

Commandes pratiques et paramètres GPO

Chemin GPO (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)“

Vérifier / définir via PowerShell :

# 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

Tests et déploiement

1. Activez d’abord sur des serveurs de fichiers pilotes et testez les accès aux fichiers depuis différents systèmes d’exploitation clients.
2. Surveillez les messages d’erreur dans le journal des événements (System/Application) et sur les clients.
3. Pour les appareils non compatibles : mise sur liste blanche par IP/firewall ou GPO spécifique avec OU d’exceptions.

Pièges courants

• Logiciels de sauvegarde ou agents utilisant SMBv1 — vérifier et mettre à jour.
• SMB‑Signing et chiffrement (SMB Encryption) ne sont pas identiques : le signing protège l’intégrité, l’encryption protège la confidentialité.

Durcissement des GPO : lignes de base, tests et gestion des stratégies

Les stratégies de groupe (GPO) sont l’outil central pour les configurations Windows. Une stratégie GPO propre empêche la dérive, facilite les audits et accélère la réponse aux incidents.

Éléments essentiels des GPO

• Options de sécurité : désactiver LM/NTLM lorsque possible, désactiver SMBv1, politiques pour LAN Manager et RESTrictions NTLM.
• Politiques de comptes : complexité, durée maximale des mots de passe, politique de verrouillage.
• Attributions de droits utilisateur : qui peut se connecter localement, Remote Desktop, tâches batch, installation de services.
• Modèles d’administration : durcissement de l’UAC, configuration des mises à jour Windows, paramètres de télémétrie.
• Pare‑feu et Windows Defender ATP / intégrations EDR.

Pratique : désactivation de SMBv1 et RESTrictions NTLM

# 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

Pour NTLM, il est recommandé d’adopter un concept par paliers : Monitoring → Alerte → Blocage. Certaines applications nécessitent encore NTLM ; établissez une cartographie NTLM et une liste d’exceptions.

Gestion, tests et Rollback

Utilisez les outils suivants :

• Group Policy Management Console (GPMC) avec Modeling et Results (gpresult /h report.html).
• Scripts de test automatisés vérifiant les services essentiels après application des GPO (montages SMB, services, tâches planifiées).
• Versioning : exportez les GPO comme sauvegarde avant toute modification.

# 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

RESTrictions PowerShell et journalisation : contrôle et traçabilité

PowerShell est un outil puissant — ce qui en fait aussi un vecteur d’attaque. Les points décisifs sont : des méthodes d’application appropriées (Execution Policy n’est PAS une frontière de sécurité), un contrôle strict par liste blanche (AppLocker/WDAC) et une journalisation étendue (ScriptBlock, ModuleLogging, Transcription).

Pourquoi l’Execution Policy seule ne suffit pas

La PowerShell Execution Policy (Set‑ExecutionPolicy) est une préférence de configuration. Ce n’est pas une frontière de sécurité, car elle peut être contournée par un utilisateur disposant de droits suffisants. Pour une application réelle, utilisez AppLocker (Application Control) ou Windows Defender Application Control (WDAC), qui appliquent des politiques spécifiques aux appareils dans un environnement d’entreprise.

Paramètres concrets : journalisation et vérification

Activez centralement les télémétries suivantes via GPO ou registre, afin d’obtenir des informations médico-légales :

• Script Block Logging : enregistre le contenu des scripts exécutés (important pour la détection).
• Module Logging : journalise les modules chargés et les commandes.
• PowerShell Transcription : transcriptions complètes des sessions.

# Activer ScriptBlockLogging via le Registre (exemple, préférence pour GPO)
New-Item -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging' -Name 'EnableScriptBlockLogging' -Value 1 -Type DWord

# Activer 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

# Activer 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

Vérifier le mode de langue actuel

# Renvoie le mode linguistique PowerShell actuel (ConstrainedLanguage, FullLanguage, etc.)
$ExecutionContext.SessionState.LanguageMode

Utiliser AppLocker ou WDAC

Pour une application stricte, utilisez AppLocker (filtre par éditeur, chemin, hash) ou WDAC pour des politiques appliquées au niveau du noyau. Les deux solutions exigent des scénarios de test, car elles peuvent facilement interrompre des charges de production. Procédure :

1. Mode audit (AppLocker/WDAC) pendant 2–4 semaines, collecte des événements.
2. Créer des règles de liste blanche (scripts signés, outils d’administration) et les basculer progressivement en mode Enforce.
3. Plan de secours : GPO avec groupe d’utilisateurs de règles désactivées ou options de démarrage si des services critiques tombent en panne.

Matériel : NAS, appliances de sauvegarde et imprimantes — prudence particulière

Les périphériques matériels tels que les NAS, les imprimantes anciennes et les appliances de sauvegarde constituent souvent des pièges de compatibilité. De nombreux appareils implémentent SMB de manière incomplète ou utilisent des dialectes obsolètes. Vérifiez et documentez ces appareils avant un projet de durcissement de sécurité à grande échelle.

Checklist : vérifier la compatibilité matérielle

• Consultez la documentation du fabricant : dialectes SMB pris en charge et prise en charge du signing/chiffrement.
• État du firmware : un firmware obsolète est souvent la cause de l’absence de fonctionnalités SMB.
• Clinique de test : connectez un client de test avec le signing activé et vérifiez les transferts de fichiers.
• Option de repli : VLAN ou règle de pare-feu qui maintient les appareils legacy séparés et contrôlés.

Outil pratique de vérification : dialecte SMB et détails de session

# Sur le client : affiche les dialectes SMB négociés
Get-SmbConnection | Select-Object -Property ServerName,ShareName,Dialect

# Sur le serveur : affiche les sessions SMB connectées
Get-SmbSession | Select-Object -Property ClientComputerName,ClientUserName,Dialect

Si un appareil ne propose que SMBv1, prévoyez un remplacement ou une segmentation réseau, car SMBv1 présente activement des risques importants.

Monitoring, SIEM et rétention des journaux

Le durcissement n’a d’effet pratique que si les écarts sont détectés. Configurez l’Event‑Forwarding ou un agent (p. ex. NXLog, Winlogbeat) pour envoyer les événements critiques vers le SIEM.

IDs d’événements et sources importantes

• PowerShell : 4103, 4104 (ScriptBlock Logging), 4105 (Module Logging).
• SMB/Server: Événements sous Microsoft‑Windows‑SMBServer/Operational — erreurs de connexion, violations de signature.
• AD/LAPS: événements d’audit AD lors d’accès en lecture à ms‑Mcs‑AdmPwd (si l’audit AD est activé).

Rétention und Speicher

Les transcriptions PowerShell et les ScriptBlock‑Logs peuvent devenir très volumineux. Prévoyez de l’espace de stockage, des points de collecte (p. ex. partage de logs central ou SIEM) et des politiques de rétention (p. ex. 90 jours actifs, archivage longue durée 1 an). Utilisez la compression et l’indexation dans le SIEM pour réduire les coûts de recherche.

Mini‑runbook concret : si des services tombent après le déploiement d’une GPO

1. Limiter le périmètre : identifier les OU/hôtes affectés (gpresult, journaux d’événements).
2. Mesure immédiate : désactiver temporairement le lien GPO pour l’OU concernée dans la GPMC.
3. Rollback : RESTore‑GPO depuis la sauvegarde ou réappliquer la GPO de sauvegarde précédente.
4. Accès : en cas de problèmes d’authentification, utiliser la console locale ou récupérer le compte de maintenance depuis le Vault.
5. Post‑traitement : analyser la cause, tester le correctif, documenter et réappliquer dans la phase pilote.

Vérifications finales et savoir‑faire opérationnel

Avant le déploiement à grande échelle, vérifiez : GPO‑Backups disponibles ? Délégation LAPS correcte ? Pipelines SIEM actives ? Appliances de sauvegarde compatibles ? Préparez une fenêtre de changement clairement documentée et un plan de communication avec les équipes d’exploitation et applicatives.

Conclusion

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.

Ce guide peut servir de base pour un runbook interne ou une offre ; il contient les principaux mécanismes de vérification et de retour en arrière qui concilient sécurité et disponibilité dans des projets réels.

Pour ce sujet, il est également important d’installer LAPS et d’activer SMB‑Signing. Le texte replace ces aspects de manière compréhensible et montre ce qui compte au quotidien.