L’audit des événements de connexion

Le protocole d’authentification Kerberos utilise des tickets horodatés
chiffrés pour contrôler les autorisations de connexion aux systèmes. Pour permettre
l’accès à  ces systèmes, y compris la station de travail devant laquelle on se
trouve, Windows 2000 demande d’abord un ticket de service au contrôleur du domaine.
Ce ticket contient les informations qui garantissent l’authenticité de l’utilisateur.
Mais, pour obtenir des tickets de service, il faut d’abord s’authentifier vis-à -vis
du contrôleur de domaine et donc acquérir un ticket d’attribution de ticket (TGT
: Ticket Granting Ticket). Le contrôleur de domaine ne vérifie réellement le mot
de passe qu’une fois, c’est-à -dire lors de l’établissement de la connexion sur
la station de travail, quand celle-ci demande le TGT. Une fois le TGT acquis,
la station de travail l’inclut dans chaque nouvelle demande de ticket de service
pour une connexion à  d’autres services du réseau (par exemple serveurs de fichiers,
Microsoft SQL Server, Microsoft Exchange Server). Windows 2000 consigne tous les
événements de demande de TGT et de tickets de services ayant réussi ou échoué.




Chaque matin, lorsqu’un utilisateur s’assied devant son poste de travail, saisit
son nom d’utilisateur et son mot de passe, la station contacte un contrôleur de
domaine local et demande un TGT. Si le nom d’utilisateur et le mot de passe sont
corrects et que le compte utilisateur est valide (contrôle de l’état, des restrictions,
…), le contrôleur de domaine accorde le TGT et enregistre l’événement 672 (ticket
d’authentification accordé) que montre la figure 1. La zone Utilisateur de cet
événement (et de tous les autres événements de la catégorie Evénement de connexion)
ne sert pas à  déterminer qui était l’utilisateur ; elle indique toujours SYSTEM.
En revanche, l’utilisateur ayant ouvert une session est identifiable avec les
zones Nom d’utilisateur et Nom du domaine ainsi qu’avec le suffixe DNS du compte
d’utilisateur (lors de la création d’un compte, il est possible d’utiliser le
nom DNS entier du domaine ou le nom du domaine racine de l’arborescence dans le
format domaine\nom d’utilisateur de NT). La zone ID de l’utilisateur donne les
mêmes informations mais sous le format NT (c’est-à -dire le nom de domaine NetBIOS
suivi d’un anti-slash et le nom d’utilisateur). La zone Nom du service identifie
le service pour lequel le contrôleur de domaine a accordé un ticket à  l’utilisateur.
Dans le cas d’une ouverture de session initiale sur une station de travail, le
contrôleur de domaine accorde à  l’utilisateur un ticket pour le service krbtgt
(c’est-à -dire celui qui accorde un ticket Kerberos).



La zone suivante est l’adresse du client. Elle identifie l’adresse IP de la station
de travail à  partir de laquelle l’utilisateur a ouvert une session. Tous les événements
Kerberos, y compris les tentatives d’ouverture de session ayant échouées, comportent
l’Adresse du client. Ces informations sont extrêmement précieuses. NT permet de
faire le suivi des tentatives d’ouverture de session ayant échoué pour un système
donné, mais pas de découvrir d’où elles proviennent. Windows 2000, en revanche,
permet non seulement d’enregistrer les demandes d’ouverture de session de façon
centralisée sur les contrôleurs de domaine, mais aussi de savoir d’où proviennent
ces ouvertures de session.



L’événement 672 se présente aussi dans d’autres cas, comme par exemple, lorsqu’un
ordinateur du domaine doit s’authentifier vis-à -vis du contrôleur de domaine.
Cela se produit en principe à  l’initialisation d’une station de travail ou au
redémarrage d’un serveur. En effet, pour qu’un ordinateur puisse accéder aux informations
des Stratégies de groupe ou enregistrer son nom DNS, la machine doit s’authentifier
vis-à -vis du contrôleur de domaine. Dans ce cas, un nom d’ordinateur apparaît
dans les zones Nom d’utilisateur et ID d’utilisateur, comme le montre la figure
2 (Les noms de comptes d’ordinateur dans les événements de connexion aux comptes
se reconnaissent toujours au caractère $ qui les accompagne).



Alors que l’ID d’événement 672 permet de faire le suivi des ouvertures de sessions
initiales grâce à  l’attribution des TGT, l’ID d’événement 673 (ticket de service
accordé) permet de surveiller l’attribution de tickets de service. Ainsi, lorsqu’un
utilisateur travaille sur un serveur de fichier ou se connecte à  une autre ressource
du système (par exemple le registre, le journal des événements, le SAM) sur un
système distant, la demande de ticket de service qui en résulte génère l’événement
673 sur le contrôleur de domaine.



Windows 2000 consigne aussi l’événement 673 dans plusieurs situations de moindre
importance. D’abord, cet événement se produit beaucoup de système à  système. Dans
ce cas, il se reconnaît car le Nom d’utilisateur est un compte d’ordinateur. Cette
situation se produit, par exemple, lorsqu’une station de travail se connecte à 
un contrôleur de domaine pour lire des informations de Stratégies de groupe. On
peut voir aussi quelques exemples occasionnels d’événement 673 dans lesquels le
Nom d’utilisateur est un compte d’utilisateur normal et la zone ID de service
est krbtgt.



Il est indispensable de comprendre les relations entre l’événement 672 et l’événement
673. L’attribution d’un TGT (événement 672) ne donne pas pour autant à  l’utilisateur
l’accès à  un système. Un TGT signifie simplement que l’utilisateur a prouvé son
identité au contrôleur de domaine et peut à  présent lui demander de l’attester
grâce aux tickets de service (événement 673) pour ouvrir une session sur divers
systèmes.



Lorsque l’utilisateur a demandé un TGT, la station de travail demande immédiatement
un ticket de service pour lui permettre d’utiliser la station de travail. Par
exemple, le journal Sécurité que montre la figure 3 révèle qu’un événement 673
a immédiatement suivi un événement 672. L’événement 673, que montre la figure
4, permet de savoir, à  partir des zones Nom d’utilisateur, Nom de service et ID
de service que Maggie a ouvert une session sur une station de travail appelée
W2KPRO-LEFT. Les zones Domaine de l’utilisateur et ID de service indiquent que
l’utilisateur et l’ordinateur sont tous deux dans le domaine MTG.LOCAL.



La figure 5 présente un événement 673. Cet événement montre que Maggie a ouvert
une session à  distance sur le système TECRA à  partir de la station de travail
W2KPRO-LEFT. Nous pouvons dire grâce aux zones Nom de service et ID de service
que Maggie a ouvert une session sur TECRA, mais comment savoir qu’il s’agissait
d’une connexion à  distance à  partir de W2KPRO-LEFT ? Notons que l’Adresse du client
est 10.0.0.81. Le premier événement 673 suivant un événement 672 renseigne toujours
sur l’attribution d’un ticket de service pour accéder à  la station de travail
sur laquelle l’utilisateur a ouvert une session. Comme Maggie a demandé au départ
un TGT pour 10.0.0.81 et ensuite immédiatement demandé un ticket de service pour
W2KPRO-LEFT, nous pouvons en conclure que 10.0.0.81 est l’adresse IP de W2KPRO-LEFT.
Les événements 673 suivants, tels que celui que montre la figure 3, révèlent que
Maggie a ouvert des sessions sur d’autres systèmes à  partir de la même adresse
de client (c’est-à -dire 10.0.0.81), lorsqu’elle utilise le disque d’un serveur
ou utilise d’autres services.



Pour empêcher des attaques basées sur le temps, Kerberos limite la durée de validité
d’un ticket. Si un ticket expire alors que l’utilisateur est encore connecté,
Windows 2000 contacte automatiquement le contrôleur de domaine pour renouveler
le ticket. Lors de ce renouvellement, il consigne également l’événement 674 (renouvellement
d’accord de ticket).