SQL Server 2022 : longueur minimale et maximale des mots de passe (différences avec 2019, diagnostics et solutions)

Après une migration vers SQL Server 2022, des mots de passe courts acceptés en 2019 peuvent être rejetés avec « Password validation failed ». D’où vient cette limite, quelles sont les longueurs minimale et maximale, et comment corriger le problème sans sacrifier la sécurité ? Voici le guide complet.

Sommaire

Exigences de longueur de mot de passe avec SQL Server 2022

Vue d’ensemble de la question

Un développeur observe qu’un mot de passe de 3 à 5 caractères, auparavant accepté sur SQL Server 2019, est désormais refusé sur SQL Server 2022. Le message retourné est du type :

Password validation failed. The password is too short.
-- ou, selon les versions/messages :
Password validation failed. The password does not meet Windows policy requirements because it is too short.

La question posée est double : quelle est la longueur minimale et maximale imposée en 2022 ? et en quoi cela diffère-t-il réellement de 2019 ?

Réponse rapide

SQL Server ne définit pas une longueur minimale propre pour les SQL logins quand CHECK_POLICY = ON : il délègue les règles à la politique de mot de passe Windows (locale ou GPO de domaine).
La longueur minimale effective est donc celle fixée par Windows/AD (ex. : 7, 8, 10, 12 caractères… selon votre stratégie). Des mots de passe 3–5 caractères échoueront si la politique impose un minimum supérieur.
La longueur maximale pour un mot de passe de login SQL reste 128 caractères (inchangé entre 2019 et 2022).
La différence perçue entre 2019 et 2022 provient presque toujours d’un contexte (OS, GPO, configuration CHECK_POLICY) et non d’un changement du moteur.

Tableau de synthèse

Point clé	Détails & justification
Politique déléguée à Windows	Lorsqu’un `CREATE LOGIN` ou `ALTER LOGIN` est exécuté avec `CHECK_POLICY = ON` (valeur par défaut), SQL Server s’appuie sur la stratégie de mot de passe Windows de l’ordinateur hôte (ou la stratégie de domaine si la machine est joint au domaine). Les exigences de complexité, d’historique, de verrouillage et de minimum length proviennent donc de Windows/AD.
Longueur minimale effective	Définie par la stratégie Windows : paramètre « Minimum password length ». Dans de nombreuses organisations, elle est fixée à 8, 10 ou 12 caractères (parfois plus). Si votre ancien environnement tolérait 3–5, c’est qu’il appliquait une politique plus permissive ou que `CHECK_POLICY` était désactivé.
Règle de complexité	La règle « Complexe » (Password must meet complexity requirements) demande des caractères issus d’au moins 3 catégories (majuscule, minuscule, chiffre, symbole) et l’interdiction d’utiliser des fragments du nom de compte. Elle ne fixe pas à elle seule un minimum numérique, qui reste piloté par « Minimum password length ».
Longueur maximale	Jusqu’à 128 caractères pour les mots de passe des SQL logins (constance observée de SQL Server 2012 à 2022). Les mots de passe Unicode sont pris en charge : utiliser `N'…'` en T‑SQL si vous incluez des caractères non ASCII.
2019 vs 2022	Le moteur n’a pas introduit une « nouvelle » limite en 2022. Un rejet apparu après migration s’explique presque toujours par un changement d’OS (ex. Windows Server 2019/2022) ou de GPO plus stricte, ou parce que `CHECK_POLICY` a été activé (volontairement ou par script standardisé) sur des logins qui l’avaient auparavant désactivé.

Pourquoi votre mot de passe court passait en 2019 mais plus en 2022 ?

Quatre scénarios typiques expliquent la différence :

Changement d’OS/GPO : vous avez déplacé l’instance vers un serveur joint au domaine avec une politique plus stricte (par ex. minimum 8+). Le même CREATE LOGIN échoue désormais.
Scripts de déploiement « durcis » : vos scripts récents imposent CHECK_POLICY = ON et/ou CHECK_EXPIRATION = ON alors que des logins historiques avaient CHECK_POLICY = OFF.
Différences d’édition ou d’hébergement : une édition Developer/Express locale avec stratégie minimale a été remplacée par une instance serveur en production avec GPO d’entreprise.
Politique « complexité » activée ajoutée à un minimum de longueur : même avec 6 caractères, un mot de passe qui n’a pas 3 catégories est refusé.

Comment SQL Server valide un mot de passe (mécanique)

Pour les SQL logins avec CHECK_POLICY = ON, SQL Server interroge l’API Windows qui évalue la politique effective (locale ou de domaine). C’est cette API qui renvoie « trop court », « pas assez complexe », « réutilisé », etc.
Pour les SQL logins avec CHECK_POLICY = OFF, l’OS n’est pas consulté : SQL Server autorise la création tant que d’autres contrôles internes (ex. must not be equal to login name) sont respectés. Attention : sécurité affaiblie.
Pour les utilisateurs de base contenue (CREATE USER … WITH PASSWORD), vous pouvez également spécifier CHECK_POLICY et CHECK_EXPIRATION. Même implications que pour les logins serveur.
Pour les Windows logins (domain\user), la vérification du mot de passe se fait côté Active Directory ; le mot de passe n’est pas géré dans SQL Server.

Longueurs minimales et maximales : valeurs pratiques

Paramètre	Valeur / réalité terrain	Remarques
Longueur minimale (effective)	Dépend de Windows/AD : souvent 8, 10, 12+ dans les entreprises	Paramètre « Minimum password length ». La règle « complexité » ne fixe pas, à elle seule, la longueur minimale.
Longueur maximale (SQL login)	128 caractères	Constante entre SQL Server 2019 et 2022. Comptez en « caractères », pas en octets.
Longueur minimale (désactivation)	Aucune (si `CHECK_POLICY = OFF`)	Non recommandé en production : non‑conformité potentielle et exposition aux attaques.

Procédure de diagnostic pas à pas

1) Vérifier la configuration des logins dans SQL Server

SELECT
    name,
    is_policy_checked  AS CHECK_POLICY_ON,
    is_expiration_checked AS CHECK_EXPIRATION_ON,
    is_disabled
FROM sys.sql_logins
ORDER BY name;

Interprétation : si CHECK_POLICY_ON = 1, la politique Windows s’applique. Un login dont la création échoue pour « trop court » doit respecter la longueur minimale de l’OS.

2) Reproduire l’erreur et capturer le code

BEGIN TRY
    CREATE LOGIN TestCourt WITH PASSWORD = 'abc', CHECK_POLICY = ON;
END TRY
BEGIN CATCH
    SELECT ERROR_NUMBER() AS Err, ERROR_MESSAGE() AS Msg;
END CATCH;

Vous verrez un message de type « Password validation failed … too short ». Le code d’erreur associé aux validations de politique est souvent 15118 (le libellé peut varier selon la cause exacte : trop court, pas assez complexe, etc.).

3) Contrôler la stratégie Windows (poste local)

Interface : secpol.msc → Account Policies ▸ Password Policy → « Minimum password length », « Password must meet complexity requirements ».
Invite de commandes : net accounts affiche notamment « Longueur minimale du mot de passe ».

4) Contrôler la stratégie de domaine (AD)

Si le serveur est joint au domaine :

Consultez la Default Domain Policy dans la console GPMC (ou demandez à l’équipe AD).
En PowerShell (avec les outils AD) : Get-ADDefaultDomainPasswordPolicy retourne MinPasswordLength, PasswordHistoryCount, etc.
Vérifiez s’il existe une standardisation récente vers 8, 10 ou 12 caractères (ou plus) qui expliquerait l’échec des mots de passe « 3–5 ».

Solutions recommandées (du plus sûr au plus tolérant)

Adopter un mot de passe plus long et plus robuste

CREATE LOGIN MonLogin
WITH PASSWORD = N'Larpege-du-Matin 2025!',
     CHECK_POLICY = ON,
     CHECK_EXPIRATION = ON;

Privilégiez les passphrases (ex. quatre mots inattendus + séparateurs). C’est plus mémorisable et plus sûr qu’un « P@ssw0rd » court.
Visez 12 à 16 caractères minimum pour les comptes humains, davantage pour les comptes de service s’ils ne sont pas gérés par coffre/rotation.

Ajuster la politique Windows/AD (si justifié)

Si l’exigence actuelle est trop restrictive pour un environnement de test ou de formation :

Sur un poste isolé : ajustez « Minimum password length » et/ou la règle de complexité via secpol.msc.
Sur un domaine : modifiez la GPO (ou appliquez une GPO dédiée au labo). Documentez le risque et conservez une trace de décision.

Désactiver la politique (`CHECK_POLICY = OFF`) – réservé au non‑prod

CREATE LOGIN MonLogin
WITH PASSWORD = 'abc',
     CHECK_POLICY = OFF,
     CHECK_EXPIRATION = OFF;

Attention : cette option désactive les vérifications OS (longueur, complexité, historique, verrouillage). À éviter en production et en environnements soumis à des exigences de conformité.

Utilisateurs de base contenue : même logique

USE MaBase;
CREATE USER U_Interne WITH PASSWORD = N'Une-Phrase de passe+1',
    CHECK_POLICY = ON, CHECK_EXPIRATION = ON;

Vous pouvez, là aussi, basculer CHECK_POLICY à OFF pour un labo — en gardant les mêmes réserves de sécurité.

Playbook d’investigation en 10 minutes

Lister les logins problématiques avec sys.sql_logins (colonnes is_policy_checked, is_expiration_checked).
Reproduire l’erreur avec un mot de passe volontairement court et capturer ERROR_NUMBER().
Vérifier côté OS : net accounts et secpol.msc pour « Minimum password length ».
Confirmer côté AD : Get-ADDefaultDomainPasswordPolicy (si accessible) et changement récent de GPO.
Décider la remédiation : allonger les mots de passe (préféré) ou modifier temporairement la politique dans un périmètre contrôlé.
Automatiser les contrôles dans vos pipelines (pré‑création de logins et TRY…CATCH).

Bonnes pratiques complémentaires

Longueur ≥ 12 par défaut pour les comptes humains ; 16–24 pour des comptes de service statiques si vous ne disposez pas d’une rotation automatique.
Complexité : au moins trois catégories (majuscule, minuscule, chiffre, symbole). Les passphrases avec espaces sont acceptées (privilégiez N'…' en T‑SQL).
Expiration : activez CHECK_EXPIRATION = ON si votre politique l’exige, mais privilégiez désormais l’authentification forte et la rotation automatisée des secrets pour les comptes applicatifs.
Éviter les mots de passe compromis : intégrez des filtres/bannis de mots de passe ou une vérification contre des listes de fuites (côté Windows/AD ou via un coffre).
Journalisation : surveillez l’ERRORLOG (échecs 15118/18456) et LOGINPROPERTY(name,'IsLocked') si vous utilisez le verrouillage de compte.
Quoting correct : pour inclure une apostrophe dans un mot de passe T‑SQL, doublez-la : 'L''été-2025!'. Pour Unicode, préfixez par N.

Exemples concrets

Créer un login robuste respectant la politique Windows

CREATE LOGIN app_reader
WITH PASSWORD = N'Voie-Lactee Lointaine 9?',
     CHECK_POLICY = ON,
     CHECK_EXPIRATION = ON,
     DEFAULT_DATABASE = MaBase;

Tenter un mot de passe trop court et gérer l’erreur

BEGIN TRY
    CREATE LOGIN demo_short WITH PASSWORD = 'abc', CHECK_POLICY = ON;
END TRY
BEGIN CATCH
    RAISERROR('Creation refusée : %s (Err=%d)',
              16, 1, ERROR_MESSAGE(), ERROR_NUMBER());
END CATCH;

Vérifier le statut des logins déjà présents

SELECT
    name,
    LOGINPROPERTY(name,'IsLocked') AS IsLocked,
    is_policy_checked, is_expiration_checked, is_disabled
FROM sys.sql_logins
ORDER BY name;

Connaître rapidement la longueur minimale locale (ligne de commande)

REM À exécuter sur l'hôte Windows : 
net accounts

La sortie indique, entre autres, la Longueur minimale du mot de passe, utile pour expliquer les refus côté SQL Server avec CHECK_POLICY = ON.

FAQ

La longueur minimale a‑t‑elle changé entre SQL Server 2019 et 2022 ?
Non, pas dans le moteur SQL lui‑même. Ce qui peut avoir changé, c’est l’environnement Windows/AD (ou la configuration CHECK_POLICY) qui définit la longueur minimale effective.

Quelle est la longueur maximale d’un mot de passe pour un SQL login ?
128 caractères. Cette limite reste valable en 2022.

Puis‑je imposer une longueur minimale spécifique directement dans SQL Server ?
Pas pour les SQL logins avec CHECK_POLICY = ON : SQL Server déléguera aux règles Windows/AD. Vous pouvez seulement activer/désactiver la délégation (CHECK_POLICY) et l’expiration (CHECK_EXPIRATION).

Pourquoi un mot de passe très court fonctionnait‑il avant ?
Soit la machine/instance ne recevait pas de GPO stricte, soit CHECK_POLICY = OFF était utilisé, soit la politique locale permettait un minimum faible.

Et pour les utilisateurs de base contenue ?
Même logique : CHECK_POLICY et CHECK_EXPIRATION peuvent être ON ou OFF. Par défaut, il est préférable de rester ON pour bénéficier de la politique Windows.

Dois‑je viser 8, 10 ou 12 caractères ?
Pour des comptes humains, 12–16 est aujourd’hui un bon minimum. Beaucoup d’entreprises fixent 12+ avec complexité. Pour des comptes applicatifs, privilégiez des secrets plus longs et la rotation automatique par coffre (plutôt qu’une expiration manuelle).

Les espaces, accents ou caractères non latins sont‑ils autorisés ?
Oui. En T‑SQL, utilisez le préfixe N pour des mots de passe Unicode : N'Frère Jacques 2025!'.

Erreurs courantes et messages associés

Symptôme	Message/Code typique	Cause probable	Remède
Refus à la création	« Password validation failed … too short » (souvent 15118)	Longueur minimale Windows > longueur proposée	Allonger le mot de passe ou baisser la politique (non‑prod)
Refus pour complexité	« Password … does not meet complexity requirements »	Manque de catégories (maj/min/chiffre/symbole), ou nom de login inclus	Recomposer le mot de passe (3 catégories min., éviter noms évidents)
Échecs d’authentification répétés	Erreur 18456 (State variable)	Mauvais mot de passe, compte verrouillé/disabled, ou `CHECK_POLICY` ON avec verrouillage	Vérifier `LOGINPROPERTY`, débloquer, réinitialiser selon la politique

Modèles de scripts prêts à l’emploi

Contrôle qualité des logins (policy/expiration)

/* Liste des logins avec leur respect de politique */
SELECT
    name,
    is_policy_checked  AS CHECK_POLICY_ON,
    is_expiration_checked AS CHECK_EXPIRATION_ON,
    create_date,
    modify_date
FROM sys.sql_logins
ORDER BY CHECK_POLICY_ON DESC, name;

Création sécurisée avec contraintes explicites

/* Paramétrer explicitement pour éviter les surprises */
CREATE LOGIN [svc_app_xyz]
WITH PASSWORD = N'Constellation_Invisible-19!',
     CHECK_POLICY = ON,
     CHECK_EXPIRATION = ON,
     DEFAULT_DATABASE = [AppDb];

Capture élégante de l’erreur de politique dans un déploiement

DECLARE @sql nvarchar(max) = N'CREATE LOGIN [tmp_test] WITH PASSWORD = N''abc'', CHECK_POLICY = ON;';
BEGIN TRY
    EXEC(@sql);
    DROP LOGIN [tmp_test];
END TRY
BEGIN CATCH
    PRINT CONCAT('Validation de mot de passe refusée : ', ERROR_MESSAGE(), ' (Err=', ERROR_NUMBER(), ')');
END CATCH;

Sécurité et conformité : recommandations modernes

Privilégiez l’authentification intégrée (Windows/AD, identités fédérées) quand c’est possible, pour éviter le stockage et la rotation de mots de passe applicatifs.
Coffre de secrets : stockez et faites tourner automatiquement les secrets des comptes de service (plutôt que des mots de passe statiques hardcodés).
Blocage des mots de passe faibles : activez des listes bannies côté AD/Windows pour empêcher les « P@ssw0rd1! » et variantes connues.
Observabilité : alertez sur l’augmentation des erreurs 15118/18456 pour repérer une GPO devenue trop restrictive ou un déploiement qui force CHECK_POLICY = OFF.

Cas particuliers et limites à connaître

Environnements hétérogènes : entre un serveur de développement autonome et une production jointe au domaine, les politiques peuvent diverger fortement. Évitez de déplacer des scripts de l’un à l’autre sans garde-fous.
Chaînes de connexion et caractères spéciaux : des symboles comme ; ou & peuvent perturber certaines chaînes de connexion ou outils s’ils ne sont pas échappés. Testez bout‑en‑bout.
Longueurs extrêmes : même si 128 est autorisé, vérifiez que les outils de déploiement, vaults ou variables d’environnement acceptent bien cette longueur et l’Unicode.
Focus de cet article : il se concentre sur SQL Server sous Windows. D’autres plateformes/hébergements peuvent appliquer des règles spécifiques.

Conclusion

Si un mot de passe court est refusé sur SQL Server 2022 avec « Password validation failed », la cause n’est quasiment jamais un « durcissement » interne du moteur par rapport à 2019, mais l’effet d’une politique Windows/AD plus stricte (ou réactivée). La longueur minimale « effective » est donc celle de votre environnement, tandis que la longueur maximale des SQL logins demeure 128 caractères. Pour corriger, privilégiez l’allongement et la modernisation de vos secrets, conservez CHECK_POLICY = ON en production, et limitez les assouplissements aux environnements de test dûment isolés.