Vérification de la stratégie de mot de passe sur les utilisateurs existants

Je suis récemment entré dans un environnement où de nombreuses connexions aux bases de données n'ont pas le enforce_password_policydrapeau activé.
Un audit à venir nécessite la vérification des mots de passe de ces connexions.

J'ai utilisé la requête suivante pour obtenir une liste des connexions et si les indicateurs sont activés ou désactivés.

select 
    @@SERVERNAME as servername, 
    name, 
    IS_SRVROLEMEMBER('sysadmin', name) as SYSADMIN,
    type_desc,
    create_date,
    is_policy_checked,
    is_disabled,
    password_hash,
    PWDCOMPARE(name, password_hash) as UsernameAsPassword
FROM sys.sql_logins

Cependant, cela ne me dit pas si les mots de passe respectent réellement la politique de mot de passe, car l'indicateur n'est pertinent que lors de la création d'un utilisateur.

Existe-t-il un moyen connu de tester la conformité des stratégies de mot de passe des utilisateurs existants ?
Je n'ai pas accès aux anciens mots de passe et je préférerais une méthode qui n'en a pas besoin.

Cela peut ne pas être populaire auprès de vos utilisateurs, mais je pense que la seule façon dont vous pouvez être sûr est de forcer un changement de mot de passe pour chaque connexion SQL avec CHECK_POLICY = ON. Cela générera un ensemble de ALTER LOGINcommandes avec des mots de passe vides, vous pouvez mettre à jour la requête en leur donnant tous un mot de passe commun ou mettre à jour manuellement chacun avec des mots de passe individuels - assurez-vous simplement qu'ils répondent à votre politique. Bien sûr, vous devez vous assurer que la stratégie de mot de passe est aussi complexe que prévu et qu'elle est activée (Panneau de configuration> Outils d'administration> Stratégie de sécurité locale> Stratégies de compte> Stratégie de mot de passe> Le mot de passe doit répondre aux exigences de complexité).

SELECT N'ALTER LOGIN ' + QUOTENAME(name) 
  + N' WITH PASSWORD = N'''' MUST_CHANGE, CHECK_POLICY = ON;' 
  FROM sys.sql_logins 
  --WHERE is_policy_checked = 0;

Steve Jones a écrit à ce sujet il y a quelque temps. Notez que - en raison de ce que j'ai découvert ci-dessous - vous ne pouvez pas vous fier is_policy_checked = 1à ce que le mot de passe correspond réellement à votre politique actuelle, car la connexion aurait pu être créée avec un mot de passe haché (auquel cas le mot de passe en texte brut ne peut pas être cochée) ou alors que la stratégie de complexité locale était désactivée (ce qui conduit toujours à is_policy_checked = 1).

Une autre approche que je pensais fonctionnerait serait d'essayer de créer une copie de chaque connexion avec leur courant password_hashet avec CHECK_POLICY = ON, et de noter toutes celles qui échouent. Cependant, cela ne peut pas fonctionner - même avec CHECK_POLICY = ON, il n'effectue aucune validation d'un mot de passe déjà haché. Je vais inclure le code pour la postérité - mais, par conception, la politique ne peut tout simplement pas être vérifiée.

SELECT N'BEGIN TRY
  CREATE LOGIN ' + QUOTENAME(N'copy_of_' + name) 
    + N' WITH PASSWORD = ' 
    + CONVERT(NVARCHAR(255), password_hash, 1)
    + ' HASHED, CHECK_POLICY = ON;
  DROP LOGIN ' + QUOTENAME(N'copy_of_' + name) + ';
END TRY
BEGIN CATCH
  IF ERROR_NUMBER() = 15118
    PRINT N''' + REPLACE(name, '''', '''''') 
      + N' was not complex enough.'';
END CATCH'
FROM sys.sql_logins;

Personnellement, je pense que c'est un bug. Si la syntaxe me permet de créer une connexion à l'aide d'un mot de passe haché et que je peux stipuler que ce mot de passe doit répondre à ma politique de complexité, cela devrait générer une erreur ou un avertissement que la politique n'a pas été, en fait, vérifiée.

MISE À JOUR : J'ai déposé un bogue contre ce comportement.

• CHECK_POLICY est un no-op avec CREATE LOGIN ... PASSWORD ... HASHED

Il n'y a aucun moyen d'obtenir cette précision à 100%. Bien que vous puissiez utiliser PWDCOMPAREpour vérifier une liste de mots de passe faibles (vous pouvez ajouter à la liste des mots de passe faibles et faire une comparaison).

J'ai écrit un script similaire qui fait la comparaison et vous donne les résultats. Je l'ai posté sur github .

ÉDITER:

Vous pouvez maintenant avoir une liste de mots de passe faibles dans un csv, puis utiliser dbatools Test-DbaLoginPasswordavec -Dictionaryswitch (spécifie une liste de mots de passe à inclure dans le test des mots de passe faibles.)

La stratégie de mot de passe par connexion SQL n'est qu'un indicateur d'activation ou de désactivation. Si l'indicateur de stratégie de mot de passe est coché, la stratégie de mot de passe Windows du système d'exploitation est appliquée.

Consultez la documentation CREATE LOGIN pour plus de détails sur ce qui se passe lorsque CHECK_POLICY et CHECK_EXPIRATION sont définis.

Vous pouvez voir les paramètres par utilisateur SQL en vérifiant les colonnes is_policy_checked et is_expiration_checked dans sys.sql_logins

quelque chose comme ci-dessous:

SELECT name,
create_date,
modify_date,
LOGINPROPERTY(name, 'DaysUntilExpiration') DaysUntilExpiration,
LOGINPROPERTY(name, 'PasswordLastSetTime') PasswordLastSetTime,
LOGINPROPERTY(name, 'IsExpired') IsExpired,
LOGINPROPERTY(name, 'IsMustChange') IsMustChange
From sys.sql_logins ;

Pour les connexions d'authentification SQL Server:

select * from sys.server_principals where type in ('U','G') - vous montrera les connexions et les groupes qui peuvent accéder à un serveur SQL via l'authentification Windows.