Audit TLS Faible LDAPS, Spouleur Impression, Synchronisation Horaire du Contrôleur de Domaine : Checklist d'Hygiène Réseau

Voici un audit TLS faible LDAPS, Spouleur d'Impression et synchronisation horaire du contrôleur de domaine : une checklist pratique pour trois réglages réseau que les revues Active Directory construites autour des ACL et de l'imbrication des groupes manquent systématiquement. Chacun se vérifie rapidement, et chacun compromet silencieusement une garantie de sécurité différente dès qu'un contrôleur de domaine dérive de sa configuration de référence.

Audit TLS Faible LDAPS, Spouleur d'Impression, Synchronisation Horaire du Contrôleur de Domaine

La plupart des revues de durcissement Active Directory traquent les ACL, l'imbrication des groupes et les chemins de délégation — et laissent de côté la surface réseau propre au contrôleur de domaine. Si vous partez d'une liste de priorités plus large, Durcissement Active Directory : quoi verrouiller d'abord situe où s'inscrit ce type de durcissement protocolaire par rapport aux accès privilégiés et aux secrets réutilisables. Les trois constats ci-dessous apparaissent rarement dans un rapport de permissions, mais chacun est peu coûteux à vérifier et à corriger une fois qu'on sait où regarder :

Aucun de ces trois points n'est nouveau. Ce qui justifie de les regrouper dans une même passe de revue, c'est qu'ils échouent silencieusement — un DC avec un écouteur LDAPS rétrogradé, un spouleur actif ou quelques minutes de dérive d'horloge paraît parfaitement sain dans un contrôle de santé standard, jusqu'à ce que quelque chose force la situation.

TLS Faible sur LDAPS

Installer un certificat valide dans le magasin Personnel de l'ordinateur local du DC active automatiquement LDAPS sur le port 636 (et 3269 pour le Global Catalog) — la documentation Microsoft sur la configuration des certificats LDAP over SSL confirme qu'aucune configuration de service supplémentaire n'est nécessaire une fois le certificat approuvé par le DC et ses clients. Le problème, c'est que « LDAPS est actif » ne dit rien des versions TLS et des suites de chiffrement qu'il continuera d'accepter. Un DC dont Schannel n'a jamais été durci négociera TLS 1.0 ou 1.1, ainsi que des suites de chiffrement CBC/SHA1 faibles, avec n'importe quel client prêt à les proposer — comme le détaille le guide de DSInternals sur l'application de TLS 1.2+ pour LDAPS sur les contrôleurs de domaine. Cela compte, car les liaisons simples LDAP transportent des identifiants sur le réseau ; un chiffrement rétrogradé sur le canal chiffré censé les protéger annule l'intérêt même de faire tourner LDAPS.

Détection

Activez la journalisation de diagnostic Schannel avant de toucher à quoi que ce soit — vous voulez des preuves de ce qui se connecte réellement avant de désactiver une version de protocole :

# Journalisation détaillée des événements Schannel (détail protocole/suite par connexion via l'Event ID 36880)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" `
  -Name "EventLogging" -Value 7 -PropertyType DWord -Force

# Énumérer les suites de chiffrement actuellement activées pour TLS sur ce DC
Get-TlsCipherSuite | Select-Object Name, Certificate, Exchange, Cipher, Hash

Get-TlsCipherSuite renvoie la liste ordonnée des suites de chiffrement que Windows négociera — Microsoft documente la référence complète de la cmdlet sur Get-TlsCipherSuite (TLS). Une fois EventLogging activé, chaque négociation Schannel vers et depuis le DC est consignée dans le journal Système sous l'Event ID 36880, avec la version de protocole et la suite de chiffrement négociées explicitement mentionnées — c'est votre preuve de quels clients ou outils forcent encore une rétrogradation avant de désactiver quoi que ce soit.

Remédiation

1. Confirmez qu'aucun client légitime n'a encore besoin de TLS 1.0/1.1, à l'aide des preuves de l'Event ID 36880 ci-dessus.
2. Désactivez TLS 1.0 et TLS 1.1 côté serveur via les clés de registre Protocols de Schannel, ou utilisez Disable-TlsCipherSuite pour retirer les suites CBC/SHA1 faibles tout en laissant actives les suites de la classe TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
3. Redémarrez le DC — les changements de protocole Schannel ne prennent effet qu'après redémarrage.
4. Relancez Get-TlsCipherSuite et revérifiez l'Event ID 36880 pour confirmer que seules les suites fortes sont négociées.

Spouleur d'Impression Actif sur un Contrôleur de Domaine

Les contrôleurs de domaine n'impriment rien pour eux-mêmes, donc le service Spouleur d'Impression n'a aucune raison opérationnelle de tourner sur l'un d'eux — pourtant il est activé par défaut. L'avis PrintNightmare de la CISA (CVE-2021-34527, CVSS 8.8) a transformé ce réglage par défaut en un chemin d'exécution de code à distance authentifié et à faible privilège — le scoring du NVD (PR:L) confirme qu'il ne faut rien de plus qu'un compte de domaine standard, pas de droits admin — et la Directive d'Urgence 21-04 de la CISA a demandé aux agences fédérales de désactiver le spouleur sur chaque DC — pas seulement de le corriger.

Corriger ne retire pas non plus le problème de conception sous-jacent. Depuis 2018, le « Printer Bug » (un abus de l'appel RpcRemoteFindFirstPrinterChangeNotification dans MS-RPRN) permet à n'importe quel utilisateur authentifié de forcer un DC dont le spouleur tourne à s'authentifier auprès d'un hôte contrôlé par l'attaquant — documenté dans l'article de Sean Metcalf Domain Controller Print Server + Unconstrained Kerberos Delegation. Enchaîné avec un compte disposant d'une délégation non contrainte, cette coercition livre le matériel d'authentification du DC lui-même ; enchaîné avec un relais, cela alimente directement une attaque NTLM relay — la même famille d'exposition couverte dans Signature SMB désactivée : pourquoi cela permet encore le NTLM relay. Microsoft Defender for Identity propose désormais cela comme une évaluation de sécurité permanente recommandant de désactiver le Spouleur d'Impression sur les DC.

Détection

Vérifiez chaque DC du domaine en une seule passe — ne vous fiez pas au seul DC dont vous vous souvenez avoir configuré :

$dcs = Get-ADDomainController -Filter * | Sort-Object HostName
foreach ($dc in $dcs) {
    Get-Service -Name Spooler -ComputerName $dc.HostName |
        Select-Object @{N='DC';E={$dc.HostName}}, Status, StartType
}

Confirmez aussi qu'aucune file d'impression publiée ne dépend d'un DC avant d'y toucher :

Get-ADObject -Filter "ObjectCategory -eq 'printQueue'"

Remédiation

1. Pour chaque DC où Status vaut Running ou où StartType n'est pas Disabled, arrêtez et désactivez le service :

Set-Service -Name Spooler -StartupType Disabled -ComputerName $dc.HostName
Stop-Service -Name Spooler -ComputerName $dc.HostName

2. Appliquez-le à l'échelle du domaine via une GPO liée à l'UO Domain Controllers (Computer Configuration > Preferences > Control Panel Settings > Services, Spooler réglé sur Stopped/Disabled) pour qu'un redémarrage ou un relancement manuel ne le réactive pas silencieusement.
3. Relancez la boucle de détection après le prochain cycle de rafraîchissement GPO pour confirmer que le réglage a tenu sur tous les DC, y compris ceux nouvellement promus — un DC fraîchement promu redémarre avec le service Spouleur revenu à son état par défaut (actif).

Dérive d'Horloge que Personne ne Surveille

Kerberos horodate ses tickets pour bloquer les attaques par rejeu, ce qui signifie que l'authentification dépend du maintien de l'horloge de chaque DC proche de la source de temps du domaine. La tolérance est régie par la stratégie Kerberos Maximum tolerance for computer clock synchronization — 5 minutes par défaut, définie sous Default Domain Policy > Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy, selon la référence des stratégies de sécurité de Microsoft. Au-delà de cette tolérance, l'authentification Kerberos échoue purement et simplement avec une réponse KRB_AP_ERR_SKEW — qui est bien plus souvent interprétée à tort comme un problème applicatif ou réseau que correctement diagnostiquée comme une dérive d'horloge.

La hiérarchie horaire du domaine n'a qu'une seule racine faisant autorité : l'émulateur PDC. Chaque autre DC se synchronise sur un pair de la hiérarchie du domaine, et les postes de travail se synchronisent sur le DC qui les authentifie. Si l'émulateur PDC lui-même n'est pas pointé vers une source externe fiable, tout le domaine peut dériver ensemble sans rien pour s'en apercevoir — c'est exactement le mode de défaillance que le guide Microsoft sur la configuration du PDC racine avec une source de temps faisant autorité vise à prévenir. Un DC discrètement pointé vers sa propre source NTP indépendante plutôt que vers la hiérarchie du domaine pose tout autant problème : il devient une seconde autorité de temps concurrente, que les autres DC n'ont aucune raison de privilégier par rapport à l'émulateur PDC, et diagnostiquer les échecs Kerberos intermittents qui en résultent sans ce contexte peut faire perdre des heures avant que quiconque songe à vérifier w32tm.

Détection

# État et source de synchronisation actuels sur ce DC
w32tm /query /status

# Comparer les écarts sur tous les DC du domaine en une seule passe
w32tm /monitor

Surveillez le journal Système pour l'Event ID 4713 (stratégie Kerberos modifiée — DC uniquement, mérite une alerte si inattendu) ainsi que les échecs d'authentification référençant KRB_AP_ERR_SKEW ; corrélés, ils pointent directement vers un problème de synchronisation horaire plutôt qu'une relation d'approbation cassée ou des identifiants expirés.

Remédiation

1. Identifiez quel DC détient le rôle d'émulateur PDC et confirmez qu'il est configuré — et non un DC pair — sur une source NTP externe fiable plutôt que sur l'horloge matérielle interne.
2. Si l'émulateur PDC dérive ou est mal configuré, le guide de remédiation des grands écarts de temps de Microsoft couvre la correction sûre des grands décalages — un saut de temps brutal sur un DC peut lui-même casser des tickets Kerberos en cours.
3. Confirmez que chaque autre DC hérite bien du temps depuis la hiérarchie du domaine (NT5DS) plutôt que d'une source indépendante qui lui serait propre.
4. Relancez w32tm /monitor après convergence et confirmez que tous les écarts se situent confortablement sous la tolérance Kerberos de 5 minutes, pas juste en dessous.

Faire de Ceci un Contrôle Répétable, Pas une Correction Ponctuelle

Les trois constats ci-dessus ont l'habitude de régresser silencieusement : un DC fraîchement promu restaure le service Spouleur à son état par défaut (actif), un certificat remplacé peut réintroduire silencieusement un repli vers un chiffrement faible, et une appliance NTP mise hors service peut laisser l'émulateur PDC sans avertissement. Rien de tout cela n'est détecté à moins que les catégories d'audit qui l'enregistreraient soient réellement activées — voir Lacunes de Configuration de la Politique d'Audit Active Directory si les événements de stratégie Schannel ou Kerberos n'apparaissent pas là où vous les attendez.

Traitez cette checklist comme n'importe quel autre contrôle sujet à dérive : relancez-la sur un calendrier, pas seulement après la première correction. Une passe trimestrielle sur les trois contrôles — suites de chiffrement, statut du spouleur et écarts de temps — rattrape la régression avant qu'elle ne devienne un incident, pour une fraction de l'effort de la remédiation initiale. Les trois extraits PowerShell ci-dessus sont assez courts pour être encapsulés dans une tâche planifiée ou un job CI plutôt que lancés à la main à chaque fois.

Comment EtcSec Détecte Cela

La catégorie Réseau d'EtcSec vérifie ces trois constats à chaque audit AD : DC_LDAPS_WEAK_TLS signale les contrôleurs de domaine dont l'écouteur LDAPS négocie encore une version TLS faible, DC_SPOOLER_ACCESSIBLE signale tout contrôleur de domaine avec le service Spouleur d'Impression accessible, et DC_TIME_SYNC_ISSUE (associé à NTP_NOT_CONFIGURED) signale les DC qui dérivent de la source de temps faisant autorité du domaine ou auxquels il manque un pair NTP configuré.