Default Domain Policy — Les corrections indispensables
La Default Domain Policy livrée par Microsoft est un point de départ, pas une config de production. Je propose des choses à corriger immédiatement et d’autres qu’il ne faut surtout pas toucher. Cette Default Domain Policy s’applique à tous les objets du domaine. Elle est créée automatiquement et contient par défaut une politique de mots de passe et quelques paramètres Kerberos.
La règle d’or, d’abord : la Default Domain Policy ne doit contenir que la politique de mots de passe et la stratégie de verrouillage des comptes. Tout le reste — pare-feu, paramètres de sécurité spécifiques, configurations applicatives - doit etre configuré avec des GPOs dédiées liées aux OUs appropriées. C’est une convention, pas une contrainte technique, cela simplifie énormément le diagnostic et la maintenance si vous pensez qu’une gpo fou la m…de il suffit de la desactiver, si vous avec tout mis dans une seule et unique gpo ben tant pis pour vous.
Correction 1 — La politique de mots de passe
Les valeurs par défaut de Microsoft sont… no comment. En 2026, une longueur minimale de 7 caractères et un seuil de verrouillage à 0 tentative (désactivé) ne correspondent à aucune recommandation de sécurité sérieuse.
Computer Configuration → Policies → Windows Settings
→ Security Settings → Account Policies → Password Policy
| Paramètre | Défaut Microsoft | Appliqué | Justification |
|---|---|---|---|
| Longueur minimale | 7 caractères | 12 caractères | Compromis praticable / CIS recommande 14 |
| Complexité | Activée | Activée ✅ | OK |
| Antériorité maximale | 42 jours | 42 jours ✅ | Acceptable |
| Antériorité minimale | 1 jour | 1 jour ✅ | OK |
| Historique | 24 mots de passe | 24 ✅ | OK |
| Chiffrement réversible | Désactivé | Désactivé ✅ | Ne jamais activer ça |
Note : le CIS Benchmark 2025 recommande 14 caractères minimum. 12 est un compromis raisonnable pour une infra perso où le confort des utilisateurs compte aussi. Sur une infra de production exposée, aller à 14 minimum.
Les paramètres Kerberos — Ne pas toucher
La Default Domain Policy contient également une politique Kerberos. Les valeurs par défaut sont correctes et n’ont pas besoin d’être modifiées dans la grande majorité des cas :
| Paramètre | Valeur par défaut |
|---|---|
| Appliquer les restrictions pour l’ouverture de session | Activé |
| Durée de vie maximale du ticket utilisateur | 10 heures |
| Durée de vie maximale du ticket de service | 600 minutes |
| Durée de vie pour le renouvellement du ticket utilisateur | 7 jours |
| Tolérance de synchronisation de l’horloge | 5 minutes |
La tolérance d’horloge à 5 minutes est particulièrement importante : si un poste a une horloge décalée de plus de 5 minutes par rapport au DC, Kerberos refusera l’authentification. C’est pour ça qu’un NTP synchronisé sur tous les postes du domaine n’est pas optionnel.
Correction 2 — La stratégie de verrouillage
Le seuil à 0 signifie que le verrouillage de compte est désactivé. Un utilisateur peut tenter un nombre illimité de mots de passe sans jamais être bloqué. C’est une invitation au brute-force.
Computer Configuration → Policies → Windows Settings
→ Security Settings → Account Policies → Account Lockout Policy
| Paramètre | Valeur recommandée |
|---|---|
| Seuil de verrouillage | 5 tentatives |
| Durée de verrouillage | 15 minutes |
| Réinitialisation du compteur | 15 minutes |
5 tentatives est un compromis raisonnable entre sécurité et confort opérationnel. En dessous, le helpdesk croule sous les déverrouillages de comptes. Au dessus, ça laisse trop de marge aux attaques par dictionnaire.
Correction 3 — Interdire l’ajout de machines au domaine
Par défaut, n’importe quel utilisateur authentifié du domaine peut joindre jusqu’à 10 machines au domaine. C’est l’attribut ms-DS-MachineAccountQuota, positionné à 10 à la création de l’AD.
Cette configuration signifie qu’un utilisateur standard, avec uniquement ses credentials de domaine, peut ajouter une machine non maîtrisée au réseau. Dans une infra perso ou en entreprise, c’est un risque inutile.
La correction agit sur deux niveaux complémentaires.
Niveau 1 — Droits utilisateur GPO
Dans la Default Domain Policy :
Computer Configuration → Policies → Windows Settings
→ Security Settings → Local Policies → User Rights Assignment
→ "Ajouter des stations de travail au domaine"
→ Supprimer "Utilisateurs authentifiés"
→ Ajouter uniquement : "Admins du domaine"
Niveau 2 — Attribut AD ms-DS-MachineAccountQuota
La GPO ci-dessus contrôle les droits locaux, mais l’attribut AD contrôle la limite au niveau du domaine. Les deux doivent être configurés.
Dans ADSI Edit (adsiedit.msc) :
Connexion → Default Naming Context
→ DC=mondomaine,DC=lan → Clic droit → Propriétés
→ ms-DS-MachineAccountQuota → Modifier → 0
Valeur 0 = aucun utilisateur non-administrateur ne peut joindre de machine au domaine.
Répéter l’opération sur chaque domaine de la forêt.
Correction bonus — La signature LDAP
ATTENTION, ce paramètre se configure dans la Default Domain Controllers Policy, pas dans la Default Domain Policy. C’est un paramètre spécifique aux contrôleurs de domaine.
Default Domain Controllers Policy → Éditer
→ Computer Configuration → Policies → Windows Settings
→ Security Settings → Local Policies → Security Options
→ "Contrôleur de domaine : conditions requises pour la signature de serveur LDAP"
→ Obliger la signature
Sans signature LDAP, les communications entre les clients et le DC en clair sont vulnérables aux attaques de type LDAP relay — un attaquant positionné sur le réseau peut intercepter et relayer des authentifications LDAP pour usurper des identités.
Point d’attention : ce paramètre peut casser des applications legacy qui font du LDAP non authentifié. Avant d’activer, surveiller les journaux d’événements Windows :
Event ID 2886— LDAP non signé détectéEvent ID 2887— Connexion LDAP non sécurisée refusée