Server Core : comment supprimer les restrictions sur les mots de passe
Qui n’a pas utilisé P@ssw0rd comme mot de passe administrateur lorsqu’obligé par la règle de complexité des mots de passe ? Suggérer ou imposer des règles sur les mots de passe est une bonne chose, en production. Sur des plate-formes de démonstration ou de test, on peut préférer que le mot de passe que l’on va taper des dizaines de fois par jour soit simple, voire très simple. Sous Windows Server 2003 et Windows Server 2008 en mode normal, il suffit de modifier la stratégie locale de sécurité en lançant secpol.msc. Sur Windows Server 2008 en mode Core, c’est une autre histoire : pas de mmc.exe, pas d’option utile dans la commande NET ACCOUNTS, bref, pas de moyen direct pour modifier ce paramètre.
La solution consiste à utiliser un modèle de sécurité (security template) et de l’appliquer avec secedit.exe. Le modèle de sécurité est un fichier .inf et voici celui qui convient à notre objectif :
[Unicode] Unicode=yes [System Access] MinimumPasswordAge=0 ;MaximumPasswordAge=42 MinimumPasswordLength=0 PasswordComplexity=0 PasswordHistorySize=0 ClearTextPassword=0 [Version] signature="$CHICAGO$" Revision=1
Le paramètre qui nous intéresse ici est PasswordComplexity=0. Les autres sont ici uniquement pour exemple.
Pour appliquer ce modèle, créez un réperoire, par exemple c:\temp. Sauvegardez le modèle dans un fichier inf, par exemple c:\temp\demo.inf (Note : notepad.exe fonctionne dans Windows Server Core --pas vraiment “Core”, hmm ?). Ensuite, appliquez le modèle :
C:\temp>secedit /configure /db demo.sdb /cfg demo.inf
La solution modèle de sécurité est la seule que j’ai trouvée pour la complexité des mots de passe. Pour ce qui est des autres paramètres à “débloquer”, NET ACCOUNTS peut être utile. Par exemple, la commande suivante débloque l’expiration des mots de passe, ce qui est utile car l’option MaximumPasswordAge=0 n’est pas possible dans un modèle de sécurité :
net accounts /MAXPWAGE:UNLIMITED
Utilisez la commande net accounts /? pour d’autres options.
Et rappelez-vous : ce n’est pas une bonne idée de baisser le niveau de sécurité en production ! Cet article ne concerne que des environnements de test !