On a observé que 70 à 90 pour cent des opérations effectuées par AD sur ntds.dit sont des lectures. Ces chiffres n'ont rien de surprenant puisque la fonction première d'AD est l'authentification des utilisateurs, qui nécessite de contrôler les mots de passe contenus dans AD en les comparant aux références
Modèles d’E/S et journaux de transactions

fournies par l’utilisateur. Même une application comme Exchange 2000, qui place les informations dans AD, effectue plus de lectures que d’écritures puisqu’elle tend à récupérer beaucoup plus d’informations qu’elle n’en met à jour.
L’accès à ntds.dit est multithread et asynchrone. En d’autres termes, beaucoup de threads s’exécutent en même temps pour prendre en charge les requêtes de différents clients et applications. Les opérations en écriture repassent immédiatement la main à ESE, mais celui-ci peut très bien attendre un peu avant d’appliquer une mise à jour à la base de données.
Le système lit les fichiers-journaux uniquement à l’occasion d’une opération de reprise logicielle ou matérielle, lorsqu’il faut réexécuter les transactions. Les écritures sont mono-thread et synchrones. Un seul thread contrôle toutes les écritures et il ne peut donc y avoir qu’une opération en écriture en cours à la fois. Le thread appelant doit attendre qu’une écriture soit terminée avant de pouvoir avancer. AD accède séquentiellement aux fichiers-journaux et annexe les données à la fin du journal en cours.
Lors de l’ajout, de la modification ou de la suppression d’un objet AD, le moteur de la base de données écrit d’abord la transaction dans une mémoires tampon, formant un cache en mémoire, puis saisit immédiatement la transaction dans le journal de transactions en cours (edb.log). Lorsque les deux opérations sont achevées, le système considère la transaction comme effectuée. Cette implémentation garantit que les données sont récupérables avant que le système ne tente de l’écrire dans ntds.dit.
Le processus LSA (Local Security Authority – lsass.exe) contrôle toutes les transactions d’AD. Lorsque la charge du système le permet, lsass.exe recherche dans le cache de la mémoire les pages non sauvegardées, les sauvegarde dans la base de données et déplace le pointeur du point de reprise pendant que le système sauvegarde les mémoires tampons. Si un système tombait en panne ou si un disque avait une défaillance à ce moment-là , les données pourraient être récupérées dans les journaux de transactions.
Pour écrire dans ses bases de données et dans ses journaux de transactions, AD utilise exactement les mêmes principes qu’Exchange. Tout comme lui, il supporte la consignation circulaire et non-circulaire. Dans la consignation circulaire, le système recycle jusqu’à 20 journaux de transactions dans un jeu pour contenir les transactions. Dans la consignation non-circulaire, Exchange maintient un jeu complet de journaux de transactions jusqu’à la suppression du jeu, une fois qu’une sauvegarde complète a été effectuée (idéalement, il faudrait effectuer des sauvegardes quotidiennement). Mais AD vide automatiquement les journaux de transactions toutes les 12 heures, contrairement à ce qui se passe dans Exchange.
Téléchargez cette ressource

Rapport Forrester sur les solutions de sécurité des charges de travail cloud (CWS)
Dans cette évaluation, basée sur 21 critères, Forrester Consulting étudie, analyse et note les fournisseurs de solutions de sécurité des charges de travail cloud (CWS). Ce rapport détaille le positionnement de chacun de ces fournisseurs pour aider les professionnels de la sécurité et de la gestion des risques (S&R) à adopter les solutions adaptées à leurs besoins.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Le Club EBIOS, une communauté dédiée à la gestion des risques autour de la méthode EBIOS
- La difficile mise en conformité avec les réglementations pour les entreprises françaises
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
