Stratégie de mot de passe affinée sous Windows Server 2022

I. Présentation

Dans ce tutoriel, nous allons voir comment configurer une stratégie de mots de passe affinée (PSO) sous Windows Server 2022, dans le but d'avoir plusieurs stratégies de mots de passe applicables sur des groupes de sécurité Active Directory.

Par défaut, l’objet de stratégie de groupe (GPO) « Default Domain Policy » contient les paramètres permettant de définir une politique de complexité des mots de passe et des verrouillages de compte sur le domaine Active Directory.

Le mauvais exemple typique : la politique de mots de passe par défaut désactivée.

Toutefois, depuis Windows Server 2008, puis Windows Server 2008 R2 et encore aujourd'hui Windows Server 2022, il est possible de créer ce qu’on appelle une « Stratégie de mot de passe affinée ». L'intérêt de ce système c'est qu'il permet de créer plusieurs politiques de complexité des mots de passe et de verrouillages de compte, puis ensuite de les appliquer uniquement sur certains objets.

Ces stratégies de mot de passe affinées permettent une plus grande flexibilité dans la gestion des mots de passe et du verrouillage de compte puisqu'elles peuvent s'appliquer sur des groupes de sécurité. Ainsi, on peut obliger les comptables de l'entreprise à mettre un mot de passe de 16 caractères minimum et les secrétaires un mot de passe de 10 caractères minimum, par exemple. C'est également une manière de protéger les comptes membres du groupe "Admins du domaine" avec une politique de mots de passe très stricte, dans la limite des possibilités offertes par les stratégies de mots de passe affinées.

Dans cet exemple, nous allons créer une stratégie de mot de passe affinée qui va s'appliquer aux membres du groupe "Comptabilité", mais le processus s'applique à ce que vous voulez ! 😉

II. La notion de stratégie de mot de passe affinée

Les stratégies de mots de passe affinées correspondent à des objets « Paramètres de mots de passe » et sont également appelées « PSO » pour « Password Settings Object ».

PSO (Password Settings Object) : Objet de Paramètres de mot de passe
PSC (Password Settings Container) : Conteneur de paramètres de mot de passe

Un PSO peut être appliqué directement sur un utilisateur, mais également sur un groupe, ce qui sera plus intéressant en termes de souplesse d’administration.

Un utilisateur/groupe peut être lié à plusieurs PSO, mais en cas de conflit de PSO, un attribut de priorité nommé « valeur de précédence » permet de définir une priorité quant à l’application de la stratégie.

En l’absence d’une politique PSO, la stratégie de mots de passe du domaine s’applique.

Pour utiliser cette fonctionnalité, le niveau fonctionnel de votre domaine et de la forêt doit être au minimum « Windows Server 2008 ». La bonne nouvelle c'est que depuis Windows Server 2012, Microsoft a simplifié la gestion des stratégies de mots de passe affinées.

III. Créer une politique de mot de passe affinée

Sur votre contrôleur de domaine, ouvrez le « Centre d’administration Active Directory » qui est accessible dans les Outils d’administration ou via « dsac.exe ».

Choisissez la vue arborescence sur la gauche, déroulez l’arborescence au niveau de votre nom de domaine, puis « System » et « Password Settings Container ».

Accéder aux politiques de mot de passe affinées
Accéder aux politiques de mot de passe affinées

Dans le volet de droite, cliquez sur « Nouveau » puis « Paramètres de mot de passe » comme ceci :

Créer une nouvelle politique de mot de passe affinée
Créer une nouvelle politique de mot de passe affinée

Un formulaire complet s’affiche à l’écran : attelez-vous il va falloir le compléter. Comme je fais les choses bien, voici quelques indications pour vous aider :

- Nom : Nom de la politique, pour ma part "PSO_Comptabilite"

- Priorité : Valeur supérieure à 0 qui servira à faire l’arbitrage en cas de conflit entre deux PSO qui s’appliquent sur un même objet. Pensez à espacer les valeurs de vos différents PSO afin de pouvoir jouer sur les priorités facilement.

Pour cela deux règles sont à connaître :

  • La valeur la plus faible sera prioritaire sur la valeur la plus haute.
  • En cas de priorité identique, c'est la politique avec le GUID le plus faible qui sera appliqué
  • Un PSO appliqué au niveau d’un utilisateur sera prioritaire appliqué au niveau du groupe.

Passons à la suite.

- Appliquer la longueur minimale du mot de passe : chiffre entier pour définir la longueur minimale que doit faire le mot de passe. Partons sur 16 caractères pour cet exemple.

- Appliquer l’historique des mots de passe : permet de définir le nombre d’anciens mots de passe qu’un utilisateur ne peut pas réutiliser, cela le force à « inventer » un nouveau mot de passe un certain nombre de fois. Par défaut, la valeur est de 24 ce qui me semble très correct.

- Le mot de passe doit respecter des exigences de complexité : indiquez si oui ou non le mot de passe doit respecter ces exigences (conseillé par sécurité).

- Stocker le mot de passe en utilisant un chiffrement réversible : il est préférable de ne pas activer cette option, là aussi par sécurité. Si vous activez cette option, cela signifie que le mot de passe stocké dans l'AD peut être récupéré en clair, ce qui n'est pas souhaitable.

- Protéger contre la suppression accidentelle : permets de se protéger contre une éventuelle suppression involontaire de cet objet PSO.

- Appliquer l’âge minimal de mot de passe : durée de vie minimale d’un mot de passe, ce qui permet d’empêcher un utilisateur de changer successivement plusieurs fois son mot de passe. Cela pourrait lui permettre de dépasser la limite de l’historique des mots de passe et de redéfinir son mot de passe initial…

Cette valeur doit correspondre à un nombre de jours.

- Appliquer l’âge maximal de mot de passe : même principe que le paramètre précédent, mais là pour la durée de vie maximale. Si l'on se réfère aux recommandations de l'ANSSI, il ne faut pas imposer de délai d'expiration sur les mots de passe des comptes non sensibles (sans privilèges élevés), si la politique d'ensemble est assez robuste. Je décoche cette option.

- Nombre de tentatives échouées autorisé : une fois que le nombre de tentatives autorisées sera dépassé, le compte sera verrouillé automatiquement. Cela permet d’éviter les attaques par brute force où de nombreuses tentatives seraient tentées…

- Réinitialiser le nombre de tentatives de connexion échouées après (mins) : une fois ce délai écoulé, le nombre de tentatives échouées est remis zéro.

Prenons un exemple : vous définissez "3" comme valeur pour le paramètre "Nombre de tentatives échouées autorisé" et un délai de 60 minutes sur le paramètre "Réinitialiser le nombre de tentatives de connexion échouées après (mins)". A partir du moment où l'utilisateur va se tromper de mot de passe une fois, un compte à rebours de 60 minutes va s'enclencher, et si dans ce laps de temps de 60 minutes il effectue 2 nouvelles tentatives en échecs (portant le total à 3) alors le compte sera verrouillé. Par contre, si au bout de 60 minutes il n'y a pas eu d'autres tentatives en échec (ou une seule, soit 2), le compteur est remis à zéro. Ce paramètre est indispensable, car sans lui le nombre de tentatives en échec ne serait jamais remis à zéro et donc le compte utilisateur finirait par être bloqué si le compteur s'incrémente tout le temps.

- Le compte va être verrouillé :

Lors du verrouillage d’un compte, ce dernier peut être verrouillé :

  • Pendant une durée de (mins) : définissez une valeur de verrouillage du compte qui sera automatiquement déverrouillé une fois le délai terminé.
  • Jusqu’à ce qu’un administrateur déverrouille manuellement le compte : une action manuelle d’un administrateur est requise pour déverrouiller le compte

Quant à la section « S’applique directement à » vous devez ajouter les utilisateurs et/ou les groupes sur lesquels vous souhaitez appliquer cette stratégie PSO. Pour cela, cliquez sur le bouton « Ajouter » situé en bas à droite. Pour ma part, j'ajoute le groupe nommé "Comptabilité" et je vous recommande d'utiliser une gestion par groupe plutôt que par utilisateurs.

Au final, j'obtiens la configuration suivante :

Exemple d'une politique de mot de passe affinée
Exemple d'une politique de mot de passe affinée

Pour information, chaque objet PSO contient des attributs spécifiques appartenant à la classe msDS-PasswordSettings et qui contiennent les valeurs définit au moment de la création de la politique. Nous avons par exemple : msDS-LockoutDuration, msDS-LockoutThreshold et msDS-MaximumPasswordAge

Cliquez sur « OK » une fois la configuration terminée.

Vous êtes désormais en mesure de mettre en place une stratégie de mot de passe affinée au sein de votre infrastructure Microsoft. Vous pouvez en créer plusieurs et les appliquer sur différents groupes.

IV. Quelle politique de mot de passe affinée s'applique sur mon utilisateur ?

Si vous désirez voir quelle stratégie s’applique à un utilisateur, toujours dans le « Centre d’administration Active Directory » sélectionnez « Users » dans l’arborescence. Ensuite, recherchez votre utilisateur dans la liste, sélectionnez-le puis sur la droite cliquez sur « Afficher les paramètres de mot de passe ».

Une fenêtre va s'ouvrir et vous aurez la réponse à votre question !

Une autre façon de faire consiste à utiliser la console "Utilisateurs et ordinateurs Active Directory". Ensuite, activez l'affichage avancé pour accéder à l'éditeur d'attributs (Affichage > Fonctionnalités avancées).

Recherchez votre utilisateur, accédez aux propriétés via un clic droit et cliquez sur l'onglet "Éditeur d'attributs". Ensuite, cliquez sur le bouton "Filtrer" et cliquez sur "Construit" afin d'afficher l'attribut msDS-ResultantPSO.

Si vous recherchez cet attribut et que vous regardez sa valeur, vous pouvez voir le nom de la politique qui s'applique. Par exemple, j'obtiens :

CN=PSO_Comptabilite,CN=Password Settings Container,CN=System,DC=it-connect,DC=local

Mais finalement, il y a plus simple avec PowerShell et le cmdlet "Get-ADUserResultantPasswordPolicy" puisqu'il suffit de préciser l'identifiant du user :

 Get-ADUserResultantPasswordPolicy -Identity guy.mauve

La propriété "Name" nous donne directement le nom de la politique.

Continuons sur notre lancée et apprenons à créer une politique de mot de passe affinée avec PowerShell.

V. Créer une politique de mot de passe affinée avec PowerShell

PowerShell dispose d'un set de cmdlet qui vont permettre de gérer les PSO en ligne de commande. Cela peut s'avérer utile si vous avez de nombreuses politiques à créer ou si vous souhaitez avoir un script prêt à l'emploi à déployer chez vos clients.

Il y a plusieurs cmdlets assez cools directement intégrés au module Active Directory de PowerShell :

  • New-ADFineGrainedPasswordPolicy : créer une nouvelle politique de mot de passe affinée
  • Add-ADFineGrainedPasswordPolicySubject : affecter une politique à un groupe ou un utilisateur
  • Set-ADFineGrainedPasswordPolicy : modifier une politique existante
  • Get-ADFineGrainedPasswordPolicy : lister les politiques de mot de passe affinées de votre domaine Active Directory

Pour créer une nouvelle stratégie de mot de passe affinée avec New-ADFineGrainedPasswordPolicy, il va falloir utiliser de nombreux paramètres. Ce n'est pas étonnant, car il y a un paquet de champs lorsqu'on le fait via l'interface graphique.

Avant de commencer, sachez que pour les valeurs temporelles, il faut respecter un format spécifique : D.H:M:S.F, c'est-à-dire : Jour.Heures:Minutes:Secondes:Fractions d'une seconde (facultatif).

La commande ci-dessous permet de créer une politique nommée "PSO_ComptabiliteBis" avec les options suivantes :

  • Une priorité de 10 (-Precedence)
  • Une longueur minimale de 7 caractères pour le mot de passe (-MinPasswordLength)
  • Un historique sur les 24 derniers mots de passe (-PasswordHistoryCount)
  • Le chiffrement réversible désactivé (-ReversibleEncryptionEnabled)
  • La complexité du mot de passe requise (-ComplexityEnabled)
  • Seuil de verrouillage fixé à 3 échecs (-LockoutThreshold)
  • Réinitialiser le nombre de tentatives de connexion échouées au bout de 60 minutes (-LockoutObservationWindow)
  • Verrouiller le compte pour une durée de 60 minutes (-LockoutDuration)
  • Le mot de passe doit être conservé au minimum 1 jour (-MinPasswordAge)
  • Le mot de passe n'expire jamais (-MaxPasswordAge)
  • L'objet PSO est protégé contre les suppressions accidentelles (-ProtectedFromAccidentalDeletion)

Ce qui donne la commande suivante :

New-ADFineGrainedPasswordPolicy -Name "PSO_ComptabiliteBis" -DisplayName "PSO_ComptabiliteBis" `
   -Precedence 10 -MinPasswordLength 7 -PasswordHistoryCount 24 `
   -ReversibleEncryptionEnabled $false -ComplexityEnabled $true `
   -LockoutThreshold 3 -LockoutObservationWindow "0.01:00:00" `
   -LockoutDuration "0.01:00:00" -MinPasswordAge "1.00:00:00" `
   -MaxPasswordAge "0.00:00:00" -ProtectedFromAccidentalDeletion $true

Si vous souhaitez activer l'option "Le compte va être verrouillé jusqu'à ce qu'un administrateur déverrouille manuellement le compte" via PowerShell, c'est un peu compliqué (pour ne pas dire impossible). Pour faire ça, il faut positionner "-LockoutDuration" à "0.00:00:00" sauf que paramètre ne peut pas avoir une valeur inférieure à "-LockoutObservationWindow" donc forcément cela pose problème ! Le problème est le même si l'on crée la politique et que l'on essaie de la modifier ensuite, on obtient l'erreur "New-ADFineGrainedPasswordPolicy : La modification n’a pas été autorisée pour des raisons de sécurité".

Note : pour modifier une politique existe, on utilisera la commande "Set-ADFineGrainedPasswordPolicy -Identity <nom-PSO>" suivie du ou des paramètres à modifier.

Pour obtenir des informations précises sur chaque paramètre de la commande New-ADFineGrainedPasswordPolicy, rendez-vous sur cette page :

Ensuite, pour attribuer la nouvelle politique "PSO_ComptabiliteBis" à notre groupe "Comptabilité", on effectuera la commande suivante :

Add-ADFineGrainedPasswordPolicySubject "PSO_ComptabiliteBis" -Subjects "Comptabilité"

Enfin, à tout moment vous pouvez lister vos PSO grâce à cette commande :

Get-ADFineGrainedPasswordPolicy -Filter *

Par exemple :

Exemple - Get-ADFineGrainedPasswordPolicy
Exemple - Get-ADFineGrainedPasswordPolicy

Avec ces quelques commandes, vous êtes en mesure de gérer vos politiques de mot de passe affinées avec PowerShell !

VI. Pour aller plus loin

Pour aller plus loin que ce que propose Microsoft nativement avec l'Active Directory, il existe des outils tiers, notamment chez Specops. J'ai eu l'occasion d'utiliser de logiciels de chez Specops :

Un outil gratuit qui permet d'analyser les mots de passe de votre Active Directory (via le hash) afin de détecter les mots de passe vulnérables et de vérifier le niveau de conformité de vos politiques de mots de passe vis-à-vis des bonnes pratiques.

Plus d'infos en regardant la vidéo ci-dessous ou en lisant mon tutoriel dédié à ce logiciel.

Specops propose également un outil payant qui va permettre de mettre en place des politiques de mots de passe très affinées, en allant beaucoup plus loin que ce que propose Microsoft nativement.

À découvrir au sein de la vidéo ci-dessous ou par l'intermédiaire de mon tutoriel sur ce logiciel.

Sachez également que l'ANSSI a publié récemment un guide sur les bonnes pratiques pour la gestion des mots de passe et l'authentification multifacteurs. Plus d'informations ici : Guide ANSSI sur les mots de passe.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Florian BURNEL

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

Nombre de posts de cet auteur : 5470.Voir tous les posts

27 thoughts on “Stratégie de mot de passe affinée sous Windows Server 2022

  • Merci pour ce magnifique travail, vous avez la maîtrise de l’explication et une très bonne méthode. bravo 1000x, (Allah te protège (incha Allah)

    Répondre
  • Bonjour merci pour ce tuto, jaimerais savoir si l’on applique se pso sur un domaine, est ce que sela s’applique automatiquement sur les utilisateurs, cad sil leur ai demande automatiquement de changer leur mot de passe

    Répondre
    • Bonjour,

      Oui la politique s’appliquera aux utilisateurs, et ils devront changer le mot de passe s’il est nécessaire qu’ils le changent (selon ce qui est définit dans la stratégie).

      Bonne journée
      Florian

      Répondre
      • Merci Florian, mais la j’ai un probleme; j’ai applique mon PSO a un seul utilisateur de mon domaine, mais rien, on ne lui demande pas de changer son mot de passe, il conserve toujours celui qui ne respecte pas les regles.

        Répondre
  • Peut-on également empêcher les usagers de réutiliser toujours et encore le même mot clé dans leurs mots de passe?

    Ex: Soleil01! Soleil02! Soleil03!

    Répondre
    • Bonjour Patrick,

      Oui il faut jouer sur l’historique des mots de passe, et si mes souvenirs sont bons on peut indiquer qu’un nouveau mot de passe ne contienne pas la valeur du mot de passe actuel. La stratégie peut être définie de façon avancée pour répondre à un maximum de besoins.

      Florian

      Répondre
  • Rebonjour Florian, mon problème persiste toujours; Ce que je voudrais, c’est quand l’utilisateur cherche a se connecter on lui notifie automatiquement de changer son mot de passe. la même avec la PSO, rien ne lui ai demande, et pourtant la PSO est attribue a cet utilisateur car quand il cherche de lui même a changer son mot de passe; on lui notifie les règles de la politique.

    Donc ma question est pourquoi on ne lui demande pas automatiquement de changer son mot de passe????

    Répondre
  • je crois qu’il n’y a pas de demande de changement de mot de passe suite a l’application de la PSO

    Répondre
  • Bonjour Florian,
    merci pour vos tutos qui sont très simples et claires.
    Moi j’ai un problème concernant la réinitialisation des mot de passes
    des users. A chaque changement de mot de passe sur le serveur (pour un user),
    l’utilisateur ne peut se connecter, ou soit il se reconnecte avec l’ancien mot de passe (qui fonctionne) malgré qu’il a été réinitialisé.

    Répondre
  • Bonjour Florian et bravo pour ce site et les conseils !

    Dans notre AD, nous avons créé une UO où tous les utilisateurs ne devraient pas avoir la possibilité de modifier leur mot de passe.
    Ma question : Est-il possible de modifier en une fois l’attribut mot de passe des users d’une UO ou même du domaine c’est – à – dire mettre Ne peut pas modifier le mot de passe à la place des habituels …Doit modifier …etc. ? Par GPO, je n’ai pas trouvé. Peut-être par script Powershell ? Bref, que cette action soit automatisée si possible car il y’aura environ 2000 users dans ce cas !
    Ou encore, est-il possible de déléguer cette opération (de changer cet attribut voir aussi la possibilité de modifier l’onglet Membre de) à un user afin qu’il aide les admins mais sans pouvoir faire quoi que ce soit d’autre ? (sachant que l’ad n’est accessible que par bureau à distance, tse)
    Par avance merci à tous,

    JC

    Répondre
  • Wow! Merci beaucoup! Grâce à vous, je comprend tout super facilement! Si seulement mes livres d’études étaient aussi efficaces que vos tutos…Encore merci!

    Répondre
  • je ne vois pas applique la stratégie a une forêt pourriz-vous m’expliquer ?
    merci

    Répondre
  • Note : Je m’immisce dans ces échanges pour signaler / rappeler qu’ils ne faut pas confondre les PSO et les GPO
    – Les PSO ne s’appliquent que lorsqu’un mot de passe doit être changé. (non concerné par gpupdate)
    – Les stratégies GPO de mot de passe, ne sont prises en compte que localement ou au niveau d’un domaine. Autrement dit, un GPO de mot de passe lié au niveau d’un OU ne sera jamais pris en compte.
    – la durée de vie d’un mot de passe est défini via la GPO de domaine (45j par défaut, avec notification 14 j avant) à moins que le compte d’utilisateur ait la case « le mot de passe n’expire jamais ».
    – un PSO appliqué à un utilisateur est prioritaire, à un PSO appliqué à un groupe (de ce même utilisateur) et supplante toujours un GPO (local ou de domaine.)
    Donc pour la question de JCD, à mon avis, pour éviter de diminuer la durée de vie de mot de passe dans le GPO de domaine, le plus simple est de sélectionner tous les users concernés dans la console ADUC, puis propriétés (communes) et sous l’onglet « compte », cocher la case « l’utilisateur devra changer son mot de passe ».
    Sinon il faut effectivement écrire un script, et modifier l’attribut UserAccountControl (même résultat, mais plus complexe 🙂 )
    Cordialement,

    Répondre
  • Hello, je voudrais forcer le changement un jour précis de la semaine exemple : un jeudi

    Répondre
  • Je l’ai trouvé sous labo.local –> system –> password setting container.

    Répondre
  • Bonjour, très bon article et toujours aussi clair dans l’ensemble.

    Toutefois, il y a quelque chose que je trouve contradictoire, que je n’ai en fait pas compris :

    « – Réinitialiser le nombre de tentatives de connexion échouées après (mins) : Une fois ce délai écoulé, le nombre de tentatives échouées est remis zéro.

    – Le compte va être verrouillé :

    Lors du verrouillage d’un compte, ce dernier peut être verrouillé :

    Pendant une durée de (mins) : Définissez une valeur de verrouillage du compte qui sera automatiquement déverrouillé une fois le délai terminé.

    Jusqu’à ce qu’un administrateur déverrouille manuellement le compte : Une action d’un administrateur est requise pour déverrouiller le compte »

    Comment est-ce possible de choisir « jusqu’à ce que l’administrateur déverrouille » et en même temps « après tel nombre de tentatives » ??

    Merci beaucoup d’avance !

    Répondre
  • J’ai une autre question :

    Quelle différence entre cette procédure et celle consistant à passer par :

    – Éditeur de gestion de stratégie de groupe -> Domaines -> domaine.local -> Default Domain Policy -> Modifier -> Stratégie Default Domain Policy -> Configuration ordinateur -> Stratégies -> Paramètres Windows Paramètres de sécurité -> Stratégie de comptes -> « Stratégie de mot de passe » et « Stratégie de verrouillage du compte » ?

    Merci beaucoup d’avance d’éclairer ma lanterne.

    Répondre
  • Bonjour , je veux savoir lorsqu’un utilisateur est invité à changer de mot de passe est ce que l’on peut indiquer à l’utilisateur quelles sont les règles à respecter afin qu’il puisse définir son nouveau mot de passe .

    Répondre
  • bonjour
    je voudrais savoir s’il y’a une solution (non payante) pour renforcer le mot de passe active directory avec les 4 critéres ensemble : majuscule – miniscule – chiffre – caractéres speciaux
    mes salutations

    Répondre
  • Compliqué oui… Impossible non !

    New-ADFineGrainedPasswordPolicy -Name « PSO Admins du domaine » -DisplayName « PSO Admins du domaine » `
    -Precedence 10 -MinPasswordLength 16 `
    -ReversibleEncryptionEnabled $false -ComplexityEnabled $true `
    -LockoutThreshold 10 -LockoutDuration « 01:00:00 » -LockoutObservationWindow « 00:30:00 » `
    -MinPasswordAge « 0.00:00:00 » -MaxPasswordAge « 0.00:00:00 » -PasswordHistoryCount 0 `
    -ProtectedFromAccidentalDeletion $false
    Set-ADObject « CN=PSO Admins du domaine,CN=Password Settings Container,CN=System,DC=domaine,DC=local » -Replace @{‘msDS-LockoutDuration’=’-9223372036854775808′}
    Add-ADFineGrainedPasswordPolicySubject « PSO Admins du domaine » -Subjects « Admins du domaine »

    Répondre
  • Super document en effet, bravo et merci
    Je cherche de mon coté a affiner encore plus dans ce que propose l’interface Password Settings container
    Une fois activées les exigences de complexités imposer sur un mot de passe nb1 majuscules – nb2 minuscules – nb3 chiffres – nb3 caractères speciaux par exemple imposer 2x chaque type de caractères ( caractères speciaux, maj min etc…. ).

    Répondre
    • Bonjour Philippe et merci !
      Avec les fonctions natives de l’Active Directory, ce ne sera pas possible d’affiner les exigences de complexité malheureusement… Par contre, vous pouvez utiliser une solution tierce pour répondre à ce besoin. Par exemple, il y a Specops Password Policy dont j’ai déjà parlé dans un autre article et qui permet d’aller beaucoup plus loin.
      A+
      Florian

      Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.