Contrôler les logons des comptes utilisateurs

Les politiques globales permettent
d’appliquer les politiques de mots de
passe et d’évincer des comptes quand
NT détecte que quelqu’un essaie de
deviner un mot de passe. Ces politiques
sont dites globales parce qu’elle
concernent tous les comptes utilisateur
dans le SAM auquel vous êtes
connecté par l’intermédiaire de User
Manager for Domains. Selon le SAM
que vous modifiez, vous pourriez définir
des politiques pour tous les utilisateurs
de votre domaine ou simplement
pour les comptes locaux pour un ordinateur.
Chaque station de travail NT et
serveur membre a un SAM local dans
lequel vous pouvez définir des
comptes utilisateur locaux valides pour ce seul ordinateur.

Pour définir des contrôles de
comptes globaux, ouvrez User
Manager for Domains et sélectionnez
Policy, Account sur la barre de menus.
La figure 1 montre la boîte de dialogue
Account Policy qui apparaît. En haut,
remarquez le mot Computer, qui indique
que vous travaillez avec le SAM
local de l’ordinateur spécifié. Si la boîte
de dialogue indique Domain, vous travaillez
avec un SAM de domaine.
En définissant les options
Password Restrictions dans la boîte de
dialogue Account Policy, vous pouvez
imposer aux utilisateurs les meilleures
pratiques de gestion de mots de passe.
Il est important de comprendre et de
définir les restrictions de mots de
passe parce que les utilisateurs sont
plutôt désinvoltes en la matière. Il y a
trois moyens de protéger les mots de
passe : forcer les utilisateurs à  créer des
mots de passe difficiles à  deviner, demander
aux utilisateurs de changer régulièrement
leurs mots de passe, et
mettre en place des politiques d’éviction
de compte.
Créer des mots de passe difficiles
à  deviner. En activant l’option
Minimum Password Length, on peut
obliger les utilisateurs à  créer des mots
de passe difficiles à  deviner. D’une manière
générale, je recommande une
longueur minimale de 7. En raison
d’une faiblesse dans la manière dont
NT découpe les mots de passe, je ne
recommande pas plus de 7, sauf à  passer
directement à  14. Si vous pouvez
apprendre aux utilisateurs à  créer une
séquence aléatoire de 7 chiffres et symboles,
vous aurez des mots de passe
puissants. Cependant, le fait d’imposer une longueur de mots de passe minimale
ne garantit pas qu’ils seront difficiles
à  deviner, parce que les utilisateurs
peuvent simplement répéter sept
fois la même lettre ou le même chiffre.
Pour obtenir des mots de passe efficaces,
il faut utiliser un filtre comme
l’utilitaire Passfilt ou Passprop dans le
Microsoft Windows NT Server 4.0
Resource Kit. Ces deux utilitaires obligent
à  créer des mots de passe composés
d’une combinaison de lettres,
chiffres, symboles et casse (majuscules/
minuscules).

Demander aux utilisateurs qu’ils
créent des mots de passe difficiles à  deviner
ne suffit pas. Il faut étayer cette
exigence par des règles écrites qui démontrent
la volonté du management
en la matière, des sessions de formation
pour apprendre à  choisir et à  mémoriser
des mots de passe puissants,
et un audit mensuel ou trimestriel des
mots de passe avec un utilitaire du
genre L0phtCrack 4.0 (LC4) de
@stake. Et pourquoi ne pas instaurer
une règle acceptable pour éviter la tentation
bien naturelle de noter les mots
de passe par écrit. Des politiques d’utilisation
acceptables manifestent les attentes
de la société en matière de sécurité.
De telles politiques fournissent
aussi un moyen de recours légal (licenciement,
par exemple) en cas de transgression.

Changer les mots de passe régulièrement.
Imposer des mots de passe
difficiles à  deviner n’est qu’un moyen
de protection. Il faut aussi obliger les
utilisateurs à  changer régulièrement
leurs mots de passe pour en faire une
cible mouvante. C’est important car, au
fil du temps, les mots de passe peuvent être devinés, partagés et inscrits çà  ou
là . De plus, l’employé qui accède à  un
compte partagé peut changer de fonction
ou quitter la société. Un changement
de mot de passe trimestriel me
paraît être une bonne fréquence.

Quand vous cochez l’option
Maximum Password Age dans la boîte
de dialogue Account Policy, NT vérifie
l’âge de chaque mot de passe chaque
fois que les utilisateurs se connectent.
Si la date d’expiration approche, NT
commence à  inviter les utilisateurs à 
changer leurs mots de passe. Par défaut,
NT affiche une notification d’expiration
14 jours avant l’expiration d’un
mot de passe et chaque fois que les utilisateurs
se connectent par la suite, jusqu’à 
ce qu’ils effectuent le changement.
(Vous pouvez contrôler
combien de temps à  l’avance NT commence
à  inviter à  un changement de
mot de passe, par une petite intervention
sur le registre, que nous verrons
plus loin.) Cependant, même si vous
indiquez un âge de mot de passe maximum,
certains utilisateurs peuvent reprendre
le même mot de passe en tant
que nouveau et la règle ne servira alors
à  rien. Vous pouvez éviter cette tentation
en validant l’option Password
Uniqueness dans la boîte de dialogue
Account Policy. Dans ce cas, NT mémorise
les mots de passe précédents et
empêche leur réutilisation. Je recommande
l’option de mémorisation maximum:
24 mots de passe. Et, même
dans ce cas, certains cabochards peuvent
effectuer 24 changements de mot
de passe d’une seule traite, pour que
NT oublie leurs mots de passe favoris,
qu’ils pourront ainsi réutiliser. Pour les
dissuader, définissez l’option
Minimum Password Age de telle sorte
que les utilisateurs ne puissent pas
changer leurs mots de passe pendant
le nombre de jours spécifié. Ainsi, si
vous définissez l’option Password
Uniqueness à  Remember 24 Passwords
et l’option Minimum Password Age à 
Allow Change In 2 Days, les utilisateurs
ne pourront revenir à  leurs mots de
passe favoris qu’après 48 jours.

Certes, ces restrictions ne susciteront
généralement pas l’enthousiasme
et inciteront certains utilisateurs peu
coopératifs à  noter leurs mots de passe
par écrit. C’est pourquoi il est important
de mettre en oeuvre des politiques
écrites et de conduire des sessions de
formation aux mots de passe.

Si vous voulez changer les restrictions
de mots de passe dans un domaine
qui contient déjà  de nombreux
utilisateurs, sachez qu’il existe une lacune
importante : NT n’examine l’âge
maximum et la longueur minimale que
quand vous changez votre mot de
passe. Par conséquent, ces deux politiques
n’agissent pas rétroactivement
sur les mots de passe que les utilisateurs
dans le domaine utilisent déjà .
Supposons que vous ayez 100 utilisateurs
et que vous changiez l’âge de
mot de passe maximum de Password
Never Expires à  Expires In 90 Days et
que vous attendiez un an. Aucun des
mots de passe n’expirera pendant ce
temps, sauf pour les utilisateurs qui en
ont changé volontairement ou qui ont
vu un administrateur les redéfinir. Dès
que vous avez défini les politiques
Maximum Password Age et Minimum
Password Length ou employé les utilitaires
Passprop et Passfilt, les utilisateurs
doivent changer leurs mots de
passe pour que ces politiques et utilitaires
soient pris en compte. Dans la
section « Politiques propres aux utilisateurs
», je montre comment imposer les changements de mots de passe en
une seule étape.

Définir les politiques d’éviction
de compte. La troisième manière de
protéger les mots de passe pendant le
processus de logon consiste à  activer
l’option Account Lockout dans la boîte
de dialogue Account Policy. NT évince
un compte utilisateur quand il détecte,
dans un délai de 24 heures, trois tentatives
de logon infructueuses consécutives,
à  cause d’un mauvais mot de
passe. L’adjectif consécutives est important
parce que si un intrus fait deux
tentatives de mot de passe puis si le
vrai possesseur du compte se connecte
normalement, NT remet à  zéro le
compte logon en échec et recommence.
Vous pouvez spécifier que le
compte restera verrouillé jusqu’à  ce
qu’un membre du groupe Administrators
ou Account Operators le déverrouille
manuellement. Autre possibilité
: que NT déverrouille le compte
après X minutes.

Il y a deux cases en bas de la figure
1. La case Forcibly disconnect remote
users from server when logon hours
expires affecte la manière dont NT
traite les utilisateurs qui restent
connectés au-delà  de leurs restrictions
d’heures dans la journée. J’expliquerai
ce point plus loin. Cette case n’est pas
cochée dans la figure 1 parce que User
Manager for Domains accède au SAM
d’un serveur membre au lieu du SAM
du domaine. Les SAM des stations de travail et des serveurs de membres ne
supportent pas les restrictions
d’heures donc, dans ce cas, la case est
inopérante.

La case Users must log on in order
to change password est une description
étrange pour une politique de logon
qui contrôle la manière dont NT
traite les mots de passe expirés. Par défaut,
cette case n’est pas cochée, signifiant
que quand un utilisateur se
connecte avec un mot de passe expiré,
NT lui demande de changer le mot de
passe puis laisse le logon se poursuivre.
Selon le degré de sécurité que
vous attachez aux mots de passe expirés,
cette situation par défaut peut
constituer un risque parce que les utilisateurs
peuvent encore accéder à  un
système longtemps après l’expiration
d’un mot de passe. Si vous cochez la
case Users must log on in order to
change password, NT ne permet pas
aux utilisateurs de se connecter après
l’expiration de leurs mots de passe. Il
faut alors qu’un administrateur ou un
opérateur de compte redéfinisse les
mots de passe des utilisateurs.
Toutefois, n’en concluez pas immédiatement
qu’il faut cocher cette case.
Vous pourriez entrer en conflit avec
une politique de logon propre aux utilisateurs,
bien connue : la case User
Must Change Password at Next Logon
dans les propriétés du compte utilisateur.
Supposez que vous cochiez la
case Users must log on in order to
change password dans la boîte de dialogue
Account Policy. Plus tard, un utilisateur
vous demande de redéfinir son
mot de passe parce qu’il l’a oublié.
Quand vous changez son mot de
passe, vous cochez la case User Must
Change Password at Next Logon dans
les propriétés du compte de l’utilisateur
afin qu’il puisse choisir un nouveau
mot de passe que vous ignorez.
Mais, quand l’utilisateur essaie de se
connecter pour changer son mot de
passe, NT s’y oppose sous prétexte que
le mot de passe est expiré. Il est donc
clair que les deux options s’excluent
mutuellement.

Il faut rappeler que les politiques
de restriction et de verrouillage des
mots de passe de la figure 1 sont globales,
signifiant que tous les utilisateurs
de votre domaine sont soumis
aux mêmes règles. Ainsi, vous ne pouvez
pas exiger des mots de passe plus
puissants uniquement pour vos administrateurs
sans créer un nouveau domaine.
Dans de tels cas, vous pouvez
appliquer des politiques propres aux
utilisateurs.