par Randy Franklin Smith
Une nouvelle catégorie de Windows 2000 donne accès à des informations qui n'existaient
pas dans Windows NTDans l'article " Gérer les fermetures et ouvertures des sessions dans Windows
2000 ", SYSTEMS Journal, mai 2001, j'explique comment utiliser la catégorie d'audit
" Audit Logon Events " de Windows 2000 pour assurer le suivi des connexions locales
sur un serveur ou une station de travail. Ce type d'information concerne tous
les événements de connexion sur le système local où ont lieu les ouvertures de
session. Dans le cas d'une grosse structure, il est donc difficile de gérer un
audit de ce type sur chaque machine.
L'audit des connexions enregistre tous les événements d'authentification de façon
centralisée sur les contrôleurs de domaines (J'aurais préféré que Microsoft donne
à ce type d'audit un nom plus précis, tel que Auditer les événements d'authentification).
Lorsqu'une personne utilise un compte de domaine pour se connecter à une station
de travail, cette dernière entre en relation avec le contrôleur de domaine pour
vérifier l'authenticité de l'utilisateur et pour connaître l'état de son compte
et ses restrictions. Lorsque l'utilisateur se connecte ensuite à un serveur par
le réseau, le contrôleur de domaine fournit à nouveau des services d'authentification.
Pour visualiser ces événements, ouvrez le composant " Stratégie de sécurité du
contrôleur de domaine " de la MMC (Microsoft Management Console) à partir du contrôleur
de domaine. Ce composant est un raccourci vers les paramètres de sécurité du GPO
(Group Policy Object) du contrôleur de domaine par défaut, qui est lié à l'UO
(Unité d'Organisation) des contrôleurs de domaines d'Active Directory. Dans la
fenêtre d'édition du composant MMC, allez sur Stratégies locales, Stratégie d'audit.
Cliquez-droit sur Auditer les événements de connexion aux comptes (Audit account
logon event) dans la sous-fenêtre de droite et sélectionnez Sécurité pour ouvrir
la boîte de dialogue " Paramètre de stratégie de sécurité ". Pour activer la catégorie,
cochez les cases Succès et Echec et sauvegardez les paramètres.
Windows 2000 rend compte de différents événements de connexion, selon le protocole
d'authentification utilisé par les systèmes impliqués pour une demande de connexion
donnée. Comme je l'ai expliqué dans " Gérer les fermetures et ouvertures des sessions
dans Windows 2000 ", Windows 2000 supporte à la fois Kerberos et NTLM (NT LAN
Manager). Lorsqu'un utilisateur ouvre une session sur une station de travail Windows
2000 pour se connecter à un serveur Windows 2000, les systèmes impliqués utilisent
Kerberos et le contrôleur de domaine consigne les événements Kerberos. Mais lorsqu'un
utilisateur ouvre une session sur une station de travail Windows NT ou se connecte
à ou à partir d'un système NT, les systèmes utilisent NTLM et le contrôleur de
domaine consigne un ensemble d'événements différent.
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).
Téléchargez cette ressource
Préparer l’entreprise aux technologies interconnectées
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
