Déployer les bases de sécurité Microsoft par GPO

La plupart des contrôles individuels de cette série (signature SMB, restrictions NTLM, protection LSA, WDigest, UAC pour les comptes locaux distants) sont déjà configurés, avec des valeurs judicieuses, dans les bases de référence de sécurité de Microsoft. Les organisations qui déploient la base de référence dans son ensemble corrigent des dizaines de constats d'un coup et disposent d'une référence documentée et versionnée pour mesurer la dérive. Celles qui s'en dispensent ont tendance à reconstruire les mêmes paramètres un incident à la fois, de manière incohérente d'une UO à l'autre.

Ce guide explique comment déployer les bases de référence par stratégie de groupe de façon à résister à l'épreuve de la production : obtenir le Security Compliance Toolkit, mesurer l'écart avec vos GPO existantes à l'aide de Policy Analyzer, tester sur des machines isolées avec LGPO, déployer par anneaux, gérer les exceptions sans modifier la base de référence, et détecter la dérive. Il s'appuie sur les pratiques de contrôle des changements du pilier Stratégie de groupe et SYSVOL.

Ce que contient le Security Compliance Toolkit

Le Microsoft Security Compliance Toolkit (SCT) est un téléchargement gratuit qui regroupe :

• Des packages de base de référence par produit et par version : versions de Windows 11 et Windows Server, Microsoft Edge, Microsoft 365 Apps. Chaque package contient des sauvegardes de GPO (dans un dossier GPOs), des modèles ADMX personnalisés (SecGuide.admx et MSS-legacy.admx), une feuille de calcul documentant chaque paramètre, et des scripts : Baseline-ADImport.ps1 importe les GPO dans votre domaine, Baseline-LocalInstall.ps1 les applique à une machine autonome.
• Policy Analyzer, qui compare des ensembles de GPO entre eux ou avec l'état effectif d'une machine, et exporte les différences vers Excel.
• LGPO.exe, un outil en ligne de commande pour importer, exporter et analyser la stratégie de groupe locale.

Les bases de référence serveur sont séparées par rôle : des GPO distinctes pour les contrôleurs de domaine et les serveurs membres, plus une GPO de sécurité au niveau du domaine pour les stratégies de comptes. Conservez cette séparation ; les paramètres des DC et des serveurs membres diffèrent sur des points importants (les attributions de droits utilisateur, par exemple).

Choisir les bonnes bases de référence pour votre parc

Téléchargez la base de référence correspondant à chaque version de système d'exploitation que vous exploitez, pas seulement la plus récente. Les bases de référence sont rédigées pour une version précise et configurent parfois des paramètres que les versions plus anciennes n'ont pas ou interprètent différemment. Dans un parc hétérogène, ciblez chaque base de référence sur la version de système correspondante via des UO distinctes (l'option la plus propre) ou via des filtres WMI sur la version du système d'exploitation, qui coûtent un peu de temps de traitement supplémentaire à chaque actualisation. N'appliquez pas la base de référence Windows 11 aux serveurs, ni celle des serveurs membres aux contrôleurs de domaine : les attributions de droits utilisateur et les paramètres de services diffèrent entre eux pour de bonnes raisons.

Déployez aussi les bases de référence Microsoft Edge et Microsoft 365 Apps là où ces produits sont installés, y compris sur les postes d'administration et les serveurs de rebond, où une configuration durcie du navigateur et d'Office compte plus que partout ailleurs. La GPO de sécurité du domaine incluse dans le package serveur définit la stratégie de mots de passe et de verrouillage au niveau du domaine ; comparez-la à votre Default Domain Policy existante plutôt que de lier une seconde GPO qui entrerait en concurrence avec elle.

Mesurer : analyse des écarts avec Policy Analyzer

Avant d'importer quoi que ce soit, déterminez l'écart entre vos GPO actuelles et la base de référence. Sauvegardez vos GPO existantes, puis chargez les deux ensembles dans Policy Analyzer.

# Sauvegarder les GPO actuelles qui s'appliquent aux UO cibles
$backup = 'D:\Baselines\Current-' + (Get-Date -Format yyyyMMdd)
New-Item -ItemType Directory -Path $backup -Force | Out-Null
Get-GPO -All | Where-Object DisplayName -Match 'Server|Workstation|Domain Controller|Default' |
    ForEach-Object { Backup-GPO -Guid $_.Id -Path $backup | Out-Null }

Dans Policy Analyzer, utilisez « Add » pour importer le dossier de sauvegarde de vos GPO actuelles et le dossier GPOs du package de base de référence ; chacun devient un fichier .PolicyRules. Sélectionnez les deux et choisissez « View / Compare ». La comparaison met en évidence les paramètres configurés différemment, ceux qu'un seul côté configure, et les conflits au sein d'un même ensemble (deux de vos propres GPO qui définissent la même valeur différemment). Exportez vers Excel et passez en revue avec les responsables de services ; cette feuille de calcul devient votre registre d'exceptions.

Concentrez la revue sur les paramètres qui ont le plus souvent un impact :

Beaucoup de ces paramètres sont traités individuellement ailleurs : imposer la signature SMB, auditer et restreindre NTLM et la stratégie de mots de passe. Suivez les étapes d'audit de ces guides avant d'accepter la valeur de la base de référence pour les paramètres NTLM et de signature.

Tester sur des machines isolées avec LGPO

Avant tout changement dans le domaine, appliquez la base de référence localement sur une machine de laboratoire identique à une build de production, et capturez l'état initial pour pouvoir revenir en arrière.

# Sauvegarder la stratégie locale actuelle, puis appliquer localement la sauvegarde de GPO de la base de référence
.\LGPO.exe /b C:\Temp\LocalPolicy-Before
.\LGPO.exe /g 'D:\Baselines\Windows Server 2025\GPOs\{GUID-of-member-server-GPO}'

# Afficher un registry.pol sous forme lisible
.\LGPO.exe /parse /m 'D:\Baselines\Windows Server 2025\GPOs\{GUID}\DomainSysvol\GPO\Machine\registry.pol'

Exécutez les tests de fumée de l'application, redémarrez, testez l'administration à distance (RDP, WinRM, agents de sauvegarde, agents de supervision), puis comparez la machine à la base de référence dans Policy Analyzer avec « Compare to Effective State » (exécuté avec élévation) pour confirmer ce qui s'est réellement appliqué.

Imposer : importer, lier par anneaux, ajouter des exceptions

Copiez d'abord les fichiers ADMX et ADML personnalisés dans le magasin central, sinon les paramètres MS Security Guide et MSS apparaissent comme des paramètres de registre supplémentaires dans la GPMC :

$dns = (Get-ADDomain).DNSRoot
$central = "\\$dns\SYSVOL\$dns\Policies\PolicyDefinitions"
Copy-Item '.\Templates\*.admx' $central
Copy-Item '.\Templates\en-US\*.adml' "$central\en-US"

Importez les GPO de la base de référence. Baseline-ADImport.ps1 le fait pour l'ensemble du package ; l'équivalent pour une seule GPO est :

# Utiliser le nom exact de la GPO livrée dans votre package de base de référence (il inclut la version)
Import-GPO -Path 'D:\Baselines\Windows Server 2025\GPOs' `
    -BackupGpoName 'MSFT Windows Server 2025 - Member Server' `
    -TargetName 'SEC-Baseline-WS2025-MemberServer' -CreateIfNeeded

Aucune de ces méthodes ne lie les GPO. Liez-les par anneaux, chaque anneau étant une UO ou un groupe utilisé pour le filtrage de sécurité :

1. Anneau 0 : laboratoire et serveurs de test appartenant à l'IT. Une semaine.
2. Anneau 1 : un échantillon représentatif de la production, un ou deux serveurs par application. Deux semaines.
3. Anneau 2 : le reste du tier, par lots.
4. Les contrôleurs de domaine en dernier, en commençant par un DC par site, après avoir validé la GPO propre aux DC en laboratoire. Coordonnez avec la base de référence des contrôleurs de domaine.

New-GPLink -Name 'SEC-Baseline-WS2025-MemberServer' -Target 'OU=Ring1,OU=Servers,DC=corp,DC=example' `
    -LinkEnabled Yes -Order 2
New-GPLink -Name 'SEC-Baseline-Exceptions-Servers' -Target 'OU=Ring1,OU=Servers,DC=corp,DC=example' `
    -LinkEnabled Yes -Order 1

L'ordre de liaison 1 l'emporte : la GPO d'exceptions prend donc le pas sur la base de référence pour les quelques paramètres pour lesquels vous avez documenté des écarts. Gardez les exceptions ciblées : limitez chacune à l'UO ou au groupe de sécurité des serveurs concernés, consignez la raison et le responsable dans le commentaire de la GPO, et revoyez-les à la sortie de la version suivante de la base de référence. Protégez toutes les GPO de base de référence et d'exceptions comme des éléments Tier 0 si elles sont liées aux DC, en suivant auditer les autorisations des GPO.

Vérifier

Sur une machine de chaque anneau, vérifiez que les GPO se sont appliquées et que les valeurs clés sont effectives :

gpresult /scope computer /r
Get-GPResultantSetOfPolicy -ReportType Html -Path C:\Temp\rsop.html

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel, RunAsPPL
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

Résultat attendu : les deux GPO de base de référence listées comme appliquées, LmCompatibilityLevel à 5, RunAsPPL défini et la signature exigée. Puis continuez à vérifier. Planifiez chaque mois un « Compare to Effective State » dans Policy Analyzer sur un échantillon de machines de chaque tier, et comparez les exports Get-GPOReport -ReportType Xml des GPO de base de référence avec la version importée, afin que toute modification d'une GPO de base de référence apparaisse comme un changement et non comme une surprise lors d'un audit. Une évaluation PingCastle après le déploiement donne une vue indépendante des constats que la base de référence a corrigés.

Lorsque Microsoft publie une nouvelle version de base de référence, importez-la sous un nouveau nom, comparez l'ancienne et la nouvelle dans Policy Analyzer, lisez les notes de version pour repérer les changements intentionnels, et déplacez les liaisons anneau par anneau.

Ce qui casse

• Le niveau d'authentification LAN Manager 5 bloque les clients NTLMv1 et LM : anciens NAS, imprimantes et scanners en « scan vers dossier », et applications héritées. Auditez d'abord NTLMv1 sur les DC.
• La signature SMB exigée casse l'accès depuis et vers les équipements qui ne savent pas signer, typiquement les anciens NAS et les imprimantes multifonctions, et peut réduire le débit sur les serveurs de fichiers à fort volume équipés de processeurs anciens.
• Refuser l'ouverture de session réseau aux comptes locaux empêche l'administration à distance avec des comptes locaux, y compris certains agents de sauvegarde et de supervision configurés avec un compte d'administrateur local. Utilisez des comptes de domaine ou Windows LAPS avec ouverture de session locale uniquement.
• La protection LSA (RunAsPPL) empêche le chargement des plug-ins LSA non signés ou non conformes, comme d'anciens middlewares de cartes à puce, des filtres de mots de passe et certains agents de sécurité. Activez d'abord le mode audit de LSA et vérifiez les événements 3065 et 3066 dans le journal opérationnel CodeIntegrity.
• Credential Guard, présent dans les bases de référence clientes, bloque NTLMv1, la délégation non contrainte et l'authentification unique MS-CHAPv2 pour les identifiants protégés. Microsoft ne recommande pas Credential Guard sur les contrôleurs de domaine.
• Les paramètres de verrouillage de compte peuvent provoquer des verrouillages dus à des identifiants obsolètes sur les appareils mobiles et les lecteurs mappés ; surveillez l'événement 4740 pendant les premières semaines.

Pour aller plus loin : le thème Stratégie de groupe & SYSVOL, le durcissement des contrôleurs de domaine pour les paramètres propres aux DC que la base de référence ne couvre pas, et la liste de contrôle de durcissement pour situer les bases de référence dans un plan à 90 jours.