Ouvertures de session ayant réussi

Windows 2000 utilise la catégorie Auditer les événements de connexion, lorsqu'un utilisateur se connecte en mode interactif (c'est-à -dire au clavier et à l'écran local) ou à distance (c'est-à -dire par le réseau). La zone Type de connexion, dans la description de l'événement, contient un numéro qui spécifie la nature de la

connexion : interactive (2), réseau (3), batch (4), service (5),
station de travail déverrouillée (7), connexion par mot de passe en texte clair
(8), ou connexions usurpées (9).

Comme dans Windows NT, l’événement n° 528, que montre la Figure 4 décrit une connexion
ayant réussi Mais, tandis que Windows NT utilise l’événement n° 528 pour chaque
type d’ouverture de session, Windows 2000 utilise un identifiant différent pour
les connexions par le réseau. Lorsqu’on mappe une unité à un serveur, qu’on se
connecte au registre du serveur, ou qu’on se connecte au réseau d’une autre manière,
Windows 2000 consigne le nouvel événement sous le numéro 540, que montre la Figure
5. Ce nouvel événement est utile, parce qu’il permet de distinguer les connexions
par le réseau des autres types. (Il faudrait que Microsoft crée un événement distinct
pour l’autre type de connexion important : la connexion interactive).

Windows 2000 consigne un grand nombre d’événements n° 540 sans grande importance.
Pour les distinguer des événements importants, regardez la zone Nom de l’utilisateur
dans l’événement. Il s’agit, soit d’un compte utilisateur normal, soit de SYSTEM,
soit d’un nom d’ordinateur se terminant par le caractère représentant le dollar
($). Un compte utilisateur normal signale qu’un utilisateur s’est connecté au
système par le réseau ; il faut faire attention à ces événements-là . En revanche,
on peut ignorer les événements dans lesquels le Nom d’utilisateur est SYSTEM,
ce qui indique qu’un service du système s’est connecté à un autre service sur
le même système. On peut aussi ne pas tenir compte des événements dans lesquels
le nom d’utilisateur est un ordinateur suivi du caractère $, ce qui signifie que
les services système d’un ordinateur distant se sont connectés aux services système
de ce système. (Par exemple, lorsqu’une station de travail Windows Professionnel
démarre, elle se connecte au contrôleur de domaine pour des informations Active
Directory et d’autres services du domaine. Pour accéder à ces services du domaine,
la station de travail doit d’abord s’authentifier auprès du contrôleur de domaine).

La zone Domaine des événements n° 528 et 540 identifie le domaine sur lequel réside
le compte de l’utilisateur. Cette zone utilise le nom de domaine NetBIOS d’avant
Windows 2000, plutôt que sa version DNS. Si un utilisateur utilise un compte local
dans la base de données SAM locale d’un système, pour se connecter à ce système,
la zone Domaine de l’événement reflètera le nom NetBIOS de l’ordinateur. Vous
ne verrez pas souvent d’ouvertures de session de comptes Utilisateur locaux dans
un environnement de domaine ; mais les pirates aiment cibler les comptes de la
base de données SAM locale – surtout le compte Administrateur – et il faut donc
rester vigilant sur l’événement n° 528 ou 540, dont la zone Domaine correspond
à la zone Ordinateur.

Les zones de processus d’ouverture de session et de paquet d’authentification
de l’événement n° 540 permettent de déterminer le protocole d’authentification
utilisé par Windows 2000, quand l’utilisateur s’est connecté au système. Lorsqu’un
utilisateur se connecte à un système Windows 2000 par le réseau, le système d’exploitation
négocie l’utilisation de l’un de deux protocoles d’authentification possibles
: NT LAN Manager – NTLM – ou Kerberos. L’identification des systèmes qui n’utilisent
pas Kerberos est importante. Ils sont, en effet, plus vulnérables aux attaques,
puisque NTLM est plus faible que Kerberos.

Windows 2000 préfère utiliser le standard Internet plus fort, Kerberos, mais ne
peut le faire qu’entre deux systèmes Windows 2000 s’approuvant mutuellement (par
exemple les systèmes d’une même forêt, les systèmes appartenant à des domaines
connectés par des approbations unilatérales explicitement définies). S’ils sont
installés correctement, les systèmes Kerberos 5.5 du MIT (Massachusetts Institute
of Technology), autres que Windows 2000, peuvent aussi utiliser Kerberos avec
des systèmes Windows 2000 Dans les autres cas (par exemple quand l’un des deux
ordinateurs est un système Windows 2000 n’appartenant pas à un domaine, ou quand
l’un des deux est un système Windows NT), Windows 2000 rebascule vers le protocole
NTLM plus ancien et plus faible, que les pirates peuvent renifler et cracker relativement
facilement. (On peut, bien entendu, migrer les systèmes à NTLM2, pour assurer
une certaine protection contre l’activité des hackers, mais on aura toujours ces
paquets NTLM à risque sur le réseau, tant que les systèmes n’auront pas été migrés
à Windows 2000.

Une fois que tous les ordinateurs clients devant se connecter à un serveur donné
auront été migrés, vérifiez dans le journal de sécurité du serveur s’il existe
un événement n° 540 dont la valeur dans la zone du paquet d’authentification est
NTLM, et non pas Kerberos. Si vous trouvez des ouvertures de session NTLM, vous
pouvez vérifier la zone de nom de la station de travail, dans l’événement, pour
déterminer le nom NetBIOS de l’ordinateur client. (Cette zone est en blanc lorsque
Windows 2000 utilise Kerberos).

Pour lier un événement d’ouverture de session ayant réussi (c’est-à -dire l’événement
528 ou 540), à l’événement de fermeture de session correspondant (Windows 2000
enregistre, comme Windows NT, les connexions ayant réussi sous le numéro 538),
utilisez le numéro d’ouverture de session qui apparaît dans les deux événements.
Par exemple, supposons que vous voyez un événement d’ouverture de session pour
l’Administrateur à 13 heures 27 et que vous vouliez savoir quand il s’est déconnecté.
Notez le numéro d’ouverture de session dans l’événement n° 528 (c’est-à -dire 0x0,
0xEC87 dans la Figure 4), puis cliquez à droite sur le journal de sécurité dans
l’Observateur d’événements, et cliquez sur Afficher/Rechercher pour rechercher
ce numéro dans le journal des événements. Toutefois, mauvaise nouvelle, Windows
2000 souffre du même étrange bug que Windows NT : le système d’exploitation néglige
occasionnellement de consigner l’événement n° 528. (Jusqu’ici, dans Windows 2000,
je n’ai remarqué ce problème que pour les ouvertures de session interactives).
En d’autres termes, on peut se retrouver avec un événement n° 528 sans événement
n° 538 correspondant).

Les nouvelles catégories d’audit

Lorsqu’on affiche la stratégie d’audit d’un système avec la console
MMC Stratégie de sécurité locale, on remarque deux nouvelles catégories
d’audit s’appliquant aux contrôleurs de domaines : Auditer l’accès au service
d’annuaire et Auditer les événements de connexion des comptes La première
permet de faire le suivi des changements apportés aux objets Active Directory
(par exemple les utilisateurs) en descendant jusqu’au niveau des propriétés.
Par exemple, on peut utiliser cette catégorie pour faire une distinction
entre les redéfinitions de mots de passe et les changements de numéros de
téléphone.

Le nom de la catégorie Auditer les événements de connexion des comptes ressemble
étrangement à celui de la catégorie Auditer les événements de connexion.
La catégorie Auditer les événements de connexion de Windows 2000 est identique
à celle de Windows NT, Auditer les ouvertures et les fermetures de session.
Le problème avec ces deux catégories tient à ce que Windows 2000 et Windows
NT enregistrent ces événements dans le système où a lieu l’ouverture de
session. Lorsqu’un utilisateur se connecte interactivement sur une station
de travail, les deux OS enregistrent l’événement dans le journal de sécurité
de la station de travail locale – si la stratégie d’audit a été activée
sur la station de travail.

L orsqu’un utilisateur se connecte à un serveur par le réseau (par exemple
par un mappage d’unité), Windows 2000 et Windows NT enregistrent la connexion
au réseau dans le journal de sécurité du serveur. Ainsi, les événements
de l’activité d’ouverture et de fermeture de session sont éparpillés entre
tous les systèmes du réseau. Microsoft a entendu les plaintes des utilisateurs
et a ajouté la catégorie Auditer les événements de connexion des comptes,
qui fait le suivi de l’authentification des utilisateurs à des endroits
centralisés : les contrôleurs du domaine.