Les mécanismes d’audit permettent à un administrateur de prendre connaissance des événements significatifs observés sur le système, qu'ils soient liés à la sécurité ou non.
L'administrateur définit au préalable une politique d'audit, c'est à dire le type d'événements à surveiller. Lorsque ces événements se produisent, ils sont consignés dans un journal dédié, le journal sécurité (security log).
Sur un système Windows par défaut, aucune politique d'audit n'est définie. Il est préférable de mettre en place une politique d'audit minimale, afin d'avoir un minimum de visibilité sur le fonctionnement du système.
Neuf catégories d'événements sont auditables dans Windows 2000 et Windows XP. Ces catégories regroupent des événements liés à la vie du système (Audit policy change, Audit process tracking, Audit system events), aux connexions au système (Audit logon events, Audit account logon events), à la gestion des comptes utilisateurs (Audit account management) ou encore à l'utilisation des privilèges (Audit privilege use).
Les deux catégories restantes (Audit object access et Audit directory service access) définissent si les accès aux objets (objets classiques ou contenus dans l'annuaire Active Directory) doivent être consignés.
Pour chaque catégorie d'événements peuvent être définis les types d'accès à auditer : accès accordés (Success), refusés (Failure), ou les deux (Success, Failure). Par exemple, pour la catégorie concernant les connexions au système local (Audit logon events), si seuls les accès refusés sont audités, seules les connexions refusées seront journalisées.
L'audit utilise le mécanisme de journalisation standard du système. Chaque entrée du journal sécurité est identifiée par un numéro d'événement et contient diverses informations suivant le type d'événement. En conservant l'exemple précédent, il sera possible de déterminer, en se basant sur le numéro d'événement, la raison pour laquelle une connexion a été refusée (compte désactivé, mot de passe expiré, …).
L'exploitation des événements d'audit n'est cependant pas une tâche simple. Suivant l'étendue de la politique d'audit, le nombre d'événements peut rapidement devenir important. De plus, de nombreux types d'événements existent, les informations associées n'étant pas toujours évidentes à déchiffrer. Il est donc courant d'avoir recours à des outils de traitement des événements d'audit, capables par exemple de classifier les événements par niveau de criticité. Un certain nombre de logiciels commerciaux offrent ce type de fonctionnalités.
Dans le cas d'objets stockés sur disque tels que des fichiers ou des clés de la base de registre, l'administrateur peut aisément configurer les types d'accès à auditer, au même endroit que la configuration du contrôle d'accès. Par exemple, sous l'explorateur de fichiers, dans les propriétés de sécurité avancées d'un fichier, l'onglet Auditing, permet la définition des types d'accès à auditer. La configuration suit le même principe que la définition des permissions sur un fichier, sauf qu'au lieu d'autoriser ou de refuser un accès, il s'agit d'auditer les accès autorisés, refusés ou les deux. De la même façon, les accès à certaines clés de la base de registre peuvent être définis, via les outils regedt32 (Windows NT et 2000) et regedit (Windows XP et ultérieurs).
Il est important de garder à l'esprit que l'audit sert à l'administrateur d'un système et non aux utilisateurs. A l'inverse du contrôle d'accès discrétionnaire, paramétrable par l'utilisateur propriétaire d'un objet, l'audit des accès n'est paramétrable que par un acteur principal possédant un privilège prévu à cet effet (Manage auditing and security log). Ce privilège, accordé par défaut à l'alias « Administrateurs » permet de modifier l'audit sur des objets et d'effacer le journal sécurité.
Au niveau interne, la configuration de l'audit des accès est stockée dans le descripteur de sécurité de chaque objet, dans la liste de contrôle d'accès système (SACL) évoquée plus haut. L'audit se fait en même temps que le contrôle d'accès, c'est-à-dire la DACL et la SACL sont évaluées lors de l’accès à un objet. Pour avoir le droit de générer un événement d'audit dans le journal sécurité, il faut disposer d'un privilège dédié (Generate security audits). Ce privilège est activé dans la session de connexion SYSTEM, de sorte que tout processus fonctionnant dans cette session peut créer des événements d'audit.