Longueur minimum de mot de passe : contourner la limite de 14 caractères sur Windows Server 2016/2019

Augmenter la longueur minimale de mot de passe au‑delà de 14 caractères sur des contrôleurs de domaine Windows Server 2016 ou 2019 n’est pas possible avec la stratégie classique ; pourtant, il existe plusieurs méthodes fiables pour contourner cette limite ou la lever définitivement.

Sommaire

Impossible de dépasser 14 caractères via la stratégie de mot de passe “classique”

Problème observé

Dans l’Éditeur de gestion des stratégies de groupe (GPMC) fourni avec Windows Server 2016 et 2019, l’entrée Minimum password length reste plafonnée à 14. Les administrateurs qui souhaitent imposer des passphrases de 15 caractères et plus découvrent donc un blocage apparemment insoluble dans la stratégie de domaine par défaut (Default Domain Policy). Résultat : les utilisateurs et les services continuent d’être contraints à d’anciens standards de complexité, alors même que la longueur constitue aujourd’hui l’élément déterminant d’entropie.

Pourquoi cette limite historique ?

Le paramètre « MinimumPasswordLength » est hérité des toutes premières versions d’Active Directory : son schéma autorise seulement les valeurs 0‑14.
La levée explicite de ce plafond — par une nouvelle bascule baptisée Relax minimum password length limits et la création parallèle du compteur Minimum password length audit — n’est arrivée qu’avec Windows Server version 2004 (canal semi‑annuel) puis Windows Server 2022 et les versions ultérieures.
Les éditions basées sur les builds 1607 (Windows Server 2016) et 1809 (Windows Server 2019) ne contiennent tout simplement pas la logique LSASS permettant de dépasser 14 dans la stratégie Default Domain Policy.

À noter : cette restriction ne découle pas d’un choix de sécurité mais d’une contrainte technique ; Microsoft n’a jamais rétroporté le correctif dans les LTS Windows Server 2016/2019.

Solutions pratiques pour imposer > 14 caractères

Méthode	Conditions	Atouts & limites
Mettre à niveau les contrôleurs de domaine (WS 2022, v 2004 ou ultérieur) puis : * Activer Relax minimum password length limits. * Définir Minimum password length audit (phase de test). * Passer Minimum password length à 15 ou plus.	Tous les DC doivent exécuter une version prenant en charge la nouvelle logique.	• Application centralisée, sans délégation supplémentaire. * Support Microsoft pérenne. * Projet potentiellement lourd : licences, compatibilité applicative, plan de reprise.
Fine‑Grained Password Policy (FGPP) : créer un objet Password Settings puis l’associer à des groupes ou utilisateurs spécifiques.	Niveau fonctionnel ≥ Windows Server 2008. Fonctionne même avec des DC 2016/2019.	• Contourne la limite et accepte jusqu’à 255 caractères. * Ciblage granulaire : comptes sensibles, VIP, comptes service, etc. * Ne s’applique pas aux ordinateurs locaux ; plusieurs FGPP supposent de gérer les priorités (msDS‑PasswordSettingsPrecedence).
Outil tiers ou script de rotation (vault, PAM, gestionnaire de secrets) capable d’imposer des passphrases longues puis de les synchroniser dans AD.	Dépendances logicielles, support, coût.	• Liberté totale sur la politique de longueur et de format. * Ajoute un composant externe qui doit être audité et maintenu.

Comprendre le fonctionnement de la bascule « Relax minimum password length limits »

La nouvelle option se trouve sous :
Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy.

Lorsque la valeur est activée :

Le moteur de stratégie LSASS n’applique plus la borne haute de 14 sur le paramètre Minimum password length.
Le journal de sécurité consigne de nouveaux événements ID 16977 (enforcement) et ID 16978 (audit) qui identifient les comptes échouant aux nouvelles règles.
Les postes membres n’ont besoin d’aucun agent ; tout est traité lors de l’échange Kerberos/NTLM contre le DC.

Mettre en place un FGPP : la voie la plus rapide et la moins intrusive

Pré‑requis

Niveau fonctionnel de forêt ≥ Windows Server 2008 (par défaut dans la plupart des environnements actuels).
Droits Domain Admin ou délégation sur le conteneur System où seront stockés les objets Password Settings.
Outils : Active Directory Administrative Center (ADAC) ou PowerShell module ActiveDirectory.

Étapes détaillées

Identifier la cible : groupe Domain Users, comptes administrateurs locaux, groupes à privilège élevé, etc.
Créer la politique :
New-ADFineGrainedPasswordPolicy ` -Name "FGPP‑15Chars" ` -Precedence 1 ` -MinPasswordLength 15 ` -MaxPasswordAge 365.00:00:00 ` -PasswordHistoryCount 24 ` -ComplexityEnabled $true
Lier la politique :
Add-ADFineGrainedPasswordPolicySubject ` -Identity "FGPP‑15Chars" ` -Subjects "Domain Users"
Forcer la réplication (repadmin /syncall) puis exécuter gpupdate /force sur les membres.
Contrôler : vérifier les attributs msDS-ResultantPSO sur un échantillon d’utilisateurs pour confirmer la bonne application.

Gestion des priorités

Si plusieurs FGPP s’appliquent à un même utilisateur, l’objet possédant la valeur la plus basse dans Precedence l’emporte. Documentez scrupuleusement vos attributions pour éviter des effets de bord.

Phase d’audit avant imposition globale

Activer le mode audit (Minimum password length audit) pendant 3 à 6 mois.
Analyser les événements 16978 : ils révèlent les applications, scripts, services gérés et utilisateurs qui échouent avec une longueur > 14.
Mettre à jour ou isoler : remédier aux systèmes incompatibles, ou prévoir un FGPP ou un compte de service exempté temporairement.

Tests de compatibilité : points de vigilance

Appliances réseau : certains VPN, pare‑feu ou proxies LDAP embarquent des implémentations obsolètes qui tronquent les champs mot de passe à 16 octets.
Applications héritées : ERP, CRM et environnements Java plus anciens imposent parfois une limite interne de 14 ou 16 caractères.
Tâches planifiées et scripts : vérifiez les fichiers .cmd, .ps1 et .config contenant des credentials codés en dur.
Intégrations SaaS : les connecteurs AD synchronisant des identités vers le cloud doivent être testés après changement de mot de passe.

Adopter les passphrases : plus simples et plus sûres

La NIST recommande des passphrases longues, mémorisables et sans contrainte de composition (majuscule, symbole, chiffre). Un exemple : Mon‑café‑matinal‑préf!. Une phrase de 20 caractères fournit plus d’entropie qu’un mot de 8 caractères complexe, tout en réduisant l’écrit sur post‑it.

Sécurité hybride et pratiques complémentaires

MFA partout : la longueur du mot de passe ne dispense jamais d’un second facteur.
Stockage réversible désactivé : vérifiez qu’aucune unité organisationnelle ne l’ait activé.
Password history ≥ 24 et Maximum password age adapté (180‑365 jours pour une passphrase).
Désactivation de NTLM v1 : évitez les canaux faibles, surtout après l’élévation de la longueur.
Surveillance des comptes à privilèges : audit des groupes Domain Admins, Enterprise Admins, Schema Admins.

Dépannage courant

Symptôme : création d’utilisateur impossible, erreur 2245 (The password does not meet the password policy)

Cause probable : la console d’administration cible un DC 2016/2019 alors que la FGPP est en place, mais la longueur saisie ne respecte pas la nouvelle valeur. Vérifiez via Get-ADUser -Identity "samaccount" -Properties * | fl *.

Symptôme : application web ne s’authentifie plus après mise à jour du mot de passe

Pistes de résolution :

Confirmer la longueur maximale supportée par l’API ou le driver JDBC/ODBC.
Si la valeur est ≤ 14, créer un compte de service spécifique assorti d’un FGPP distinct ; n’abaissez pas la politique globale.
Planifier une mise à jour applicative ou le remplacement du composant.

Questions fréquentes (FAQ)

La limite de 14 caractères est‑elle liée au hachage LM ?

Pas directement. LM Hash ne prend en charge que 14 caractères mais il est désactivé par défaut depuis Windows Vista / Server 2008. La borne de GPMC est un reliquat historique non corrélé au stockage LM.
Puis‑je appliquer un FGPP à toute l’organisation pour simuler une politique de domaine ?

Oui, un FGPP peut cibler un groupe contenant tous les utilisateurs. En revanche, l’icône « clé » de la stratégie par défaut continuera d’afficher 14, ce qui peut prêter à confusion pour les administrateurs moins expérimentés.
Une montée de version vers Windows Server 2022 affecte‑t‑elle le niveau fonctionnel ?

Non, la promotion d’un DC 2022 ne modifie pas automatiquement le niveau fonctionnel de forêt ou de domaine. Vous pouvez conserver « Windows Server 2012 R2 Functional Level » et bénéficier quand même de la nouvelle logique de mot de passe.
Les mots de passe d’ordinateur local (SAM) suivent‑ils la même règle ?

Non, la politique de domaine ne s’applique pas aux locaux. Pour les machines autonomes ou en workgroup, configurez la stratégie locale (secpol.msc) ou utilisez Local Security Policy CSP via Intune.

Étapes rapides récapitulatives (FGPP)

Auditer les comptes et applications existants.
Créer un FGPP imposant 15+ caractères et le lier aux groupes souhaités.
Attendre la réplication puis forcer un gpupdate.
Contrôler les journaux d’événements pour détecter d’éventuels échecs.
Communiquer aux utilisateurs des modèles de passphrases faciles à retenir.

Conclusions à retenir

Windows Server 2016/2019 ne permettront jamais d’aller au‑delà de 14 caractères via la Default Domain Policy.
La mise à niveau vers Windows Server 2022 ou plus récent offre la solution la plus propre — à condition d’activer Relax minimum password length limits.
Le FGPP reste cependant la technique la plus légère, rapide et sans impact global pour adopter des mots de passe ou passphrases de 15 caractères et plus.
Toujours auditer d’abord, déployer ensuite : c’est la seule parade aux régressions sur des applications héritées.