Fizyczna architektura Active Directory

7 stycznia 2015 at 09:26

Czym jest Active Directory? – Empirycznie wie niemal każdy. Na to pytanie z pewnością łatwo można uzyskać poprawne odpowiedzi co do pełnionych funkcji, przeznaczenia, obsługi oraz codziennych zadań administracyjnych. Nie każdy jednak wie – jak działa Active Directory od środka, z czego się składa w rzeczywistości, jak przechowuje informacje oraz jak komunikuje się z klientami.

Active Directory w dużym uproszczeniu i ogólności, jest to jedna z ról systemu operacyjnego, która może być świadczona przez serwerowe systemy firmy Microsoft. Usługi katalogowe zapewniają możliwość utrzymywania wielkiej ilości danych dotyczących użytkowników, urządzeń, podsieci, lokacji, grup oraz innych zasobów mogących podlegać katalogowaniu. Oferują przy tym możliwość uwierzytelniania z wykorzystaniem pojedynczego punktu logowania (ang. Single Sign-On) oraz łatwego przeszukiwania struktur katalogowych, które zwracają w odpowiedzi czytelne i usystematyzowane dane.

Wydawać mogłoby się, że Active Directory po zainstalowaniu jest całkowicie odrębną i wy-separowaną rolą w systemie Windows mającą bezpośredni dostęp do jądra systemowego. Nic bardziej mylnego! Z perspektywy systemu operacyjnego Active Directory jest częścią systemu zabezpieczeń, który dodatkowo nie działa w trybie jądra (ang. Kernel mode), lecz w trybie użytkownika (ang. User mode). Co to oznacza? Oznacza to mniej więcej tyle, że proces, rola czy aplikacja działająca w trybie użytkownika nie ma bezpośredniego dostępu do systemu operacyjnego ani sprzętu, lecz zamiast tego musi „prosić” system o stosowne dostępy do zasobów. Każda taka prośba jest weryfikowana na poziomie warstwy wykonawczej (ang. Executive layer) i dopiero po pomyślnej walidacji zostaje zrealizowana. Aby móc rozważyć operacje odbywające się na tym poziomie abstrakcji w systemie operacyjnym posłużmy się Rys.1, na którym przedstawiona została uproszczona architektura systemu operacyjnego, w którym umieściliśmy Active Directory. Dla bardziej dociekliwych odsyłam chociażby do schematu: http://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/Windows_2000_architecture.svg/468px-Windows_2000_architecture.svg.png – co prawda dotyczy on Windows’a NT, lecz w bardzo intuicyjny sposób przedstawia poszczególne warstwy architektury systemowej Windows.

Rys.1 Umiejscowienie Active Directory w architekturze systemu operacyjnego

Rys.1 Umiejscowienie Active Directory w architekturze systemu operacyjnego

Dla niektórych czytelników powyższa informacja jest pewnie lekkim zaskoczeniem. Nasuwają się pewnie również pytania dotyczące celowości takiego umiejscowienia Active Directory w architekturze systemowej, wydajności takiego rozwiązania, generowanych opóźnień podczas weryfikacji żądań itd.

Spiesząc z wyjaśnieniem powyższych kwestii – takie umiejscowienie usług katalogowych jest jak najbardziej celowe i ma wbrew pozorom sens. W związku z tym, że Active Directory jest częścią systemu zabezpieczeń Windows, staje się ono również częścią systemu kontroli dostępu (ang. Access-control system) oraz wbudowanych mechanizmów autoryzacji oferowanych przez system operacyjny. Dzięki temu dane przechowywane w usłudze katalogowej są chronione już w najniższych warstwach systemu operacyjnego.

Active Directory w ramach systemu zabezpieczeń tworzy trzon lokalnego urzędu zabezpieczeń (ang. Local Security Authority – LSA). Składnikami LSA jest jeszcze wiele dodatkowych komponentów zapewniających bezpieczeństwo funkcji systemu Windows oraz poprawne i bezpieczne funkcjonowanie procesu uwierzytelniania, jak i samego systemu kontroli dostępu. Lokalny urząd zabezpieczeń pełni dodatkowo funkcję miedzy innymi generatora identyfikatorów zabezpieczeń, zapewnia mechanizmy audytowania i zdarzeń bezpieczeństwa oraz umożliwia obsługę logowania interaktywnego. Najistotniejsze składniki systemu zabezpieczeń Windows działającego w oparciu o Active Directory zostały zaprezentowane na Rys.2

Rys.2 Schemat systemu zabezpieczeń Windows działającego w oparciu o Active Directory.

Rys.2 Schemat systemu zabezpieczeń Windows działającego w oparciu o Active Directory.

Z powyższego schematu widać, że Active Directory działające jako integralna część lokalnego systemu zabezpieczeń zapewnia usługi oraz interfejsy umożliwiające dostęp i weryfikację dostępu do zasobów zarówno w trybie jądra systemu, jak i w trybie użytkownika.

Przejdźmy do delikatnego przybliżenia każdego z elementów widocznych na Rys.2. aby nie pozostawiać niedomówień… Elementy te można podzielić na dwie zasadnicze grupy:

1. Elementy obsługujące mechanizmy uwierzytelniania:

  • NTLM (Msv1_0.dll) – protokół uwierzytelniania NTLM będący rozwinięciem protokołu LM. Służy głównie do uwierzytelniania klientów, którzy nie obsługują protokołu Kerberos.
  • KDC (Kdcsvc.dll) – Centrum dystrybucji kluczy (ang. Key Distribution Center) protokołu Kerberos
  • Kerberos (Kerberos.dll) – protokół uwierzytelniania Kerberos v5
  • SSL (Schannel.dll) – protokół uwierzytelniania SSL zapewniający uwierzytelnianie z wykorzystaniem bezpiecznego szyfrowanego połączenia
  • Authentication provider (Secur32.dll) – komponent obsługujący różne protokoły i sposoby uwierzytelniania (przedstawione wcześniej) , który zapewnia ich prawidłowe działanie

2. Elementy obsługujące mechanizmy kontroli dostępu:

  • NETLOGON (Netlogon.dll) – usługa zapewniająca bezpieczne połączenie pomiędzy klientami Active Directory a kontrolerami domeny. Przesyłane są przez nią bezpiecznym kanałem poświadczenia użytkownika do kontrolera domeny, skąd po uwierzytelnieniu zwracane są identyfikatory zabezpieczeń wraz z uprawnieniami klienta.
  • LSA (Lsasrv.dll) – . część lokalnego systemu zabezpieczeń, która wymusza zasady bezpieczeństwa.
  • SAM (Samsrv.dll) – Menedżer kont zabezpieczeń, w którym przechowywane są lokalne konta zabezpieczeń. Wymusza on lokalnie przechowywane zasady bezpieczeństwa.
  • NTDS (Ntdsa.dll) – Moduł usług katalogowych Active Directory, który odpowiada za przechowywane partycji danych katalogowych.

Mając już wiedzę na temat umiejscowienia usług Active Directory w systemie operacyjnym oraz operacji, których staje się integralną częścią po instalacji – możemy odpowiedzieć na pytanie, dlaczego Active Directory jest częścią systemu zabezpieczeń. Dzieje się tak, ponieważ każdy klient Active Directory, zanim uzyska dostęp do zasobów musi zostać uwierzytelniony przez kontroler domeny, który sprawdza poświadczenia klienta i po pomyślnym przejściu procesu uwierzytelniania zwraca mu identyfikator zabezpieczeń wraz z zestawem uprawnień, którymi klient może się posłużyć w celu uzyskania dostępu do zasobów domenowych. W związku z powyższym, ponieważ Active Directory czynnie uczestniczy w procesie uwierzytelniania klientów – musi być częścią systemu zabezpieczeń Windows.

Kolejnym podstawowym aspektem związanym z usługami katalogowymi jest sposób kontaktu. Klient może próbować uzyskać dostęp do usług katalogowych na kilka sposobów. Podstawowym z nich jest wykorzystanie protokołu LDAP (ang. Lightweight Directory Access Protocol). Protokół LDAP jest standardowym protokołem służącym dostępowi do usług katalogowych zarówno Active Directory, jak i również innych producentów. Wpierane są obecnie wersja 2 oraz wersja 3 LDAP, które wykorzystują do komunikacji protokół TCP/IP. Domyślnym portem, na którym kontroler domeny nasłuchuje żądań LDAP jest port 389 TCP, z kolei przy wykorzystaniu bezpiecznych, szyfrowanych połączeń SSL jest to port 636 TCP. Dzięki LDAP-owi klient (posiadający stosowne uprawnienia) może odpytać Active Directory, a także może dzięki niemu zarządzać obiektami, do których posiada uprawnienia. Innym interfejsem, którym usługi katalogowe Active Directory mogą się komunikować z klientami jest REPL, który może wykorzystywać zarówno protokół zdalnego wywoływania procedur RPC (ang. Remote Procedure Call) jak i protokół „SMTP over IP” (ang. Simple Mail Transfer Protocol). Zadaniem interfejsu REPL jest obsługa replikacji Active Directory obejmującej zmiany w usługach katalogowych, które muszą zostać przesłane lub odebrane z/do innych kontrolerów domeny. Oznacza to, że klientami korzystającymi z interfejsu REPL są w zasadzie jedynie kontrolery domen. Dla wstecznej kompatybilności ze starszymi klientami pocztowymi Active Directory udostępnia też interfejs MAPI (ang. Messaging Application Programming Interface), za pomocą którego klienci pocztowi korzystający z MAPI są w stanie uzyskać dostęp do informacji przechowywanych przez np. Exchange w Active Directory. Dzięki MAPI klienci są w stanie odpytywać Active Directory celem odczytu informacji z książki adresowej Exchange. W przypadku takich klientów wykorzystywany jest protokół RPC bazujący na portach – 135 UDP oraz 135 TCP. W przypadku bardziej współczesnych klientów pocztowych wykorzystywany jest protokół LDAP zamiast MAPI. Ostatnim z interfejsów udostępnianych dla klientów Active Directory jest SAM (ang. Security Account Manager). Zdalnie dostępny jest on z wykorzystaniem protokołu RPC i przeznaczony głównie dla zachowania kompatybilności z przestarzałymi dzisiaj systemami operacyjnymi. Zapewnia to możliwość podłączenia takich klientów do Active Directory w sposób zbieżny z ich połączeniami do bazy SAM. Dodatkowo ten interfejs jest sporadycznie wykorzystywany w procesie replikacji zmian między kontrolerami domeny.

Przybliżyliśmy już interfejsy komunikacyjne Active Directory – pora przejść do kolejnego poziomu architektury usług katalogowych widocznej na Rys.3. Jest nim komponent usług katalogowych NTDSA.DLL.

Rys.3. Warstwowa architektura usług katalogowych.

Rys.3. Warstwowa architektura usług katalogowych.

Z abstrakcyjnego punktu widzenia komponent usług katalogowych składa się z dwóch zasadniczych części:

  • Agenta systemu katalogowego – DSA (ang. Directory system Agent) – zapewniającego interfejsy i mechanizmy umożliwiające klientom dostęp do bazy Active Directory
  • Warstwy bazodanowej – zapewniającej interfejs API (ang. application programming interface) umożliwiający obsługę bazy Active Directory.

Z kolei patrząc z fizycznego punktu widzenia – agent systemu katalogowego jest komponentem usług katalogowych, wewnątrz którego działa baza Active Directory. Dzieje się tak dlatego, że w przypadku fizycznej separacji tych części baza zostałaby pozbawiona ochrony dostępu, którą zapewnia jej DSA. Co więcej, niemożliwe byłoby zachowanie obiektowej hierarchii bazy Active Directory (ta tematyka będzie szerzej omówiona w rozdziale poświęconym architekturze bazy Active Directory). Zapewnienie fizycznej ochrony bazy przez DSA odbywa się w oparciu o wymuszanie ograniczeń zabezpieczeń na podstawie SID-ów klienta próbującego wykonywać operacje na bazie oraz samego obiektu w bazie, którego operacja ma dotyczyć. Jeśli walidacja będzie pomyślna dla klienta, to DSA zezwoli na wykonanie operacji, w przeciwnym wypadku odrzuci taką operację z powodu braku uprawnień do jej wykonania. Innym istotnym zadaniem agenta systemu katalogowego jest inicjalizacja replikacji pomiędzy kontrolerami domeny.

Do omówienia została jeszcze najniższa warstwa architektury usług katalogowych, która ma bezpośredni dostęp do magazynu danych – warstwa aparatu magazynu rozszerzalnego ESE (ang. Extensible Storage Engine). Warstwa ESE ma za zadanie odczytywać dane z magazynu danych oraz również zapisywać do niego dane. Warstwa ta stanowi swego rodzaju interfejs, za pomocą którego możliwy jest dostęp do danych katalogowych przechowywanych w formie indeksów oraz danych sekwencyjnych. Zapewnia poprawne dostarczanie spójnych danych do aplikacji oraz mechanizmy obsługi i odzyskiwania magazynu danych w przypadku wystąpienia awarii. Co warte uwagi – aparat mechanizmu rozszerzalnego jest w stanie cache’ować dane w sposób inteligentny, co zapewnia wysoką wydajność dostępu do danych katalogowych. Z drugiej strony dane skatalogowane w takiej bazie w formie płaskich plików zajmują bardzo niewiele miejsca, co czyni ten mechanizm idealnym do zastosowań takich jak baza Active Directory, czy Exchange. Dla osób, które jednak są bardziej przekonane do SQL’a i chciałyby mieć możliwość łączenia się z Active Directory poprzez klienta SQL’a – jak najbardziej mogą mieć taką możliwość – http://www.mssqltips.com/sqlservertip/2580/querying-active-directory-data-from-sql-server/

Przedstawiona została architektura usług katalogowych Active Directory oraz sposób działania i interakcji poszczególnych warstw. Mamy już wiedzę na temat operacji, które odbywają się w systemie operacyjnym, zabezpieczeń dostępu oraz poziomów weryfikacji uprawnień, które musza zostać spełnione przed uzyskaniem dostępu do danych katalogowych. Możemy więc przejść do samej architektury magazynu danych Active Directory.

MAGAZYN DANYCH

Zasadnicza struktura fizyczna magazynu danych Active Directory składa się z trzech głównych części:

  • Głównego pliku bazy danych (Ntds.dit)
  • Dzienników transakcji
  • Plików roboczych

Wszystkie z nich są integralnymi częściami magazynu danych niezbędnymi do prawidłowego działania usług katalogowych. Bardziej szczegółowy schemat magazynu danych Active Directory został przedstawiony na Rys. 4.

Rys.4. Fizyczna architektura magazynu danych Active Directory

Rys.4. Fizyczna architektura magazynu danych Active Directory

Jak widać, na powyższym schemacie – każda z przedstawionych wcześniej głównych części magazynu danych zawiera w sobie kilka komponentów wykorzystywanych podczas działania usług katalogowych. Przestawmy ich główne zadania:

  1. Główny plik bazy danych Ntds.dit– fizyczny plik bazy danych Active Directory, w którym przechowywane są dane skatalogowane. W bazie danych wyróżnić można trzy główne tabele:
    • Tabela danych Active Directory – zawiera rekordy dla każdego obiektu przechowywanego w usługach katalogowych. Poszczególne wiersze w tabeli reprezentują konkretne obiekty Active Directory takie jak użytkownicy, jednostki organizacyjne, grupy itd. Z kolei kolumny reprezentują atrybuty danego obiektu. Komórka leżąca na przecięciu wiersza i kolumny reprezentuje wartość atrybutu przypisanego do danego obiektu Active Directory. Komórka jest uzupełniana wartością jedynie w przypadku, gdy obiekt ma wypełniony dany atrybut.Rekordy tabeli danych są przechowywane w logicznych stronach (ang. Pages), które posiadają stałą wielkość 8 KB. Każda strona składa się z:
      • Nagłówka zajmującego 96 B
      • Wiersza danych o zmiennej długości
      • Wolnego miejsca zawierającego m.in. informację o przesunięciu wiersza. Wykorzystywane są 8 B wskaźniki, gdzie przechowywane są kolejne dane, które mogą lecz nie muszą być zapisywane w sposób ciągły.Powyższy mechanizm zapisu danych zapewnia możliwość przechowywania w bazie Active Directory obiektów zajmujących znacznie więcej niż 8 KB. Z drugiej strony w bazie nie są utrzymywane informacje o wszystkich atrybutach danego konta, a jedynie o tych, które posiadają wypełnioną wartość.
    • Tabela deskryptora zabezpieczeń – tabela ta została wprowadzona od czasów Windows Server 2003 i pozwoliła rozwiązać zjawisko zduplikowanych deskryptorów zabezpieczeń na każdym obiekcie, który dziedziczył dany deskryptor – mające miejsce we wcześniejszych implementacjach Active Directory. Odkąd wprowadzono tę tabelę – deskryptory zabezpieczeń przechowywane są w tabeli jedynie raz a obiekty posiadają odwołania do stosownych deskryptorów.
    • Tabela połączeń – tabela wykorzystywana jest do odczytywania powiązanych atrybutów obiektów Active Directory. Ma to miejsce na przykład podczas odczytu atrybutów dostarczających informacji o członkostwie w grupach oraz o członkostwie w kontenerach Active Directory.

Oraz dodatkowe tabele takie jak tabela quot, czy tabele wykorzystywane przez mechanizm ESE.

  1. Dzienniki transakcji– pliki obsługujące procesy transakcji na bazie danych Active Directory:
    1. Główny dziennik transakcji (Edb.log) – zawiera wszystkie zmiany w usłudze katalogowej, które muszą zostać zapisane do bazy danych. Domyślnym rozmiarem głównego dziennika transakcji jest 10 MB.
    2. Dodatkowe dzienniki transakcji (EdbXXXXX.log) – dzienniki tworzone i wykorzystywane w razie przepełnienia głównego dziennika transakcji. Każdy z nich ma również stały rozmiar 10 MB, po przekroczeniu którego tworzone są kolejne dzienniki z hierarchicznymi numerami.
    3. Rezerwowe dzienniki transakcji (EdbResXXXXX.jrs) – pliki tworzone przez usługi katalogowe w celu rezerwacji miejsca pod dzienniki transakcji, w przypadku zapełniania pierwszego i kolejnych dzienników. Dzięki temu proces tworzenia i obsługi transakcji jest znacznie przyspieszony, ponieważ Active Directory ma miejsce do obsługi kolejnych transakcji natychmiast po wyplenieniu poprzedniego dziennika transakcji.
  2. Pliki robocze – pliki pomocnicze w trakcie obsługi transakcji na bazie danych Actvie Directory:
    1. Plik weryfikacyjny (Edb.chk) – plik przechowujący informację o punkcie, do którego transakcja na bazie Active Directory została potwierdzona.
    2. Plik tymczasowy (Tmp.edb) – miejsce tymczasowe potrzebne do obsługi bieżących operacji na bazie danych.

 

W celu przejrzenia i weryfikacji aktualnego stanu bazy ESE skorzystać można z narzędzia linii poleceń esentutl.exe. Dzięki niemu można podejrzeć opisywane wcześniej pliki uczestniczące w transakcjach na bazie danych. Narzędzie to zapewnia również funkcjonalności defragmentacji, weryfikacji integralności, naprawy i przywracania bazy Active Directory. Ponieważ poniższy artykuł tyczy się architektury Active Directory, to zobaczmy przykładowe dane otrzymywane po podejrzeniu plików – UWAGA – wykonanie poniższych czynności wymaga zatrzymania usług katalogowych na kontrolerze domeny. W przeciwnym wypadku polecenie „przywita” nas błędem:

Rys.5. Błąd podczas próby podejrzenia pliku bazy Active Directory w trakcie działających usług katalogowych.

Rys.5. Błąd podczas próby podejrzenia pliku bazy Active Directory w trakcie działających usług katalogowych.

Po zatrzymaniu usług katalogowych podejrzenie bazy staje się możliwe. Korzystając na przykład z przełącznika /mm otrzymujemy informację o tabelach, indeksach

Rys.6. Zrzut metadanych utrzymywanych w bazie Active Directory.

Rys.6. Zrzut metadanych utrzymywanych w bazie Active Directory.

W tym momencie pewnie zrodziło się pytanie „jak to czytać”? – Małe wyjaśnienie. Pole „Name” odpowiada nazwie obiektu, którym może być na przykład tabela czy indeks, pole „Type” odpowiada typowi obiektu, pole „ObjidFDP” oznacza identyfikator obiektu (ang. Object ID Father Data Page) dla każdej tabeli indeksów z kolei pole „PgnoFDP” (ang. Page Number of Father Data Page) zawiera numer strony nadrzędnej w strukturze B-drzewiastej bazy ESE, która zazwyczaj jest korzeniem danego drzewa stron.

Innym przydatnym przełącznikiem jest /mk, którym można podejrzeć stan punktów kontrolnych transakcji – widocznych na Rys.7.

Rys.7. Zrzut metadanych utrzymywanych w plikach kontrolnych transakcji.

Rys.7. Zrzut metadanych utrzymywanych w plikach kontrolnych transakcji.

Z powyższego dowiedzieć można się na przykład czy i kiedy zapisane były punkty kontrolne, pełne i przyrostowe kopie zapasowe. Natomiast najistotniejszym przełącznikiem w tym miejscu jest opcja /ms. Z jej zastosowaniem możemy odczytać statystyki wolnego miejsca w bazie Active Directory, a także wielkość poszczególnych indeksów i tabel, co jest widoczne na Rys.8.

Rys.8. Zrzut informacji o miejscu w bazie NTDS.

Rys.8. Zrzut informacji o miejscu w bazie NTDS.

Na powyższym rysunku mamy informację o tym, jak duże są nasze tabele – Owned(MB), ile zajmują miejsca w bazie NDTS – %ofDB, ile jest wolnego miejsca w tabeli – Avail(MB) oraz ile stanowi to procent tabeli – Avail%Tbl. Oprócz tabeli wyszczególnione są również inne składniki bazy. To, na co powinniśmy zwrócić uwagę, to indeksy [INDEX_ …] – w ich przypadku weryfikujemy jaki procent tabeli – %ofTable oraz jaki procent całej bazy – %ofDb zajmuje dany index. Jeśli jeden index wykorzystuje znaczącą ilość miejsca w całej bazie/tabeli to należy się zastanowić, czy jest on optymalny oraz, czy na pewno taki index wpływa na poprawę wydajności Active Directory. – Więcej o indeksach opowiemy w kolejnych częściach cyklu :) Jako podsumowanie powyższego polecenia dostaniemy zbiorczą informację o ilości wolnego miejsca w całej bazie Active Directory – Rys.9. Na tej podstawie można estymować, że po wykonaniu defragmentacji bazy zostanie zwolnione w przybliżeniu tyle miejsca.

Rys.9. Podsumowanie informacji o wolnym miejscu w bazie Active Directory.

Rys.9. Podsumowanie informacji o wolnym miejscu w bazie Active Directory.

Ponieważ wyszliśmy z poziomu warstwy aparatu magazynu rozszerzalnego ESE, to zaprezentowane zostało narzędzie, którym można analizować bazę Active Directory na tym poziomie. Jeżeli natomiast zależy nam aby odwoływać się bezpośrednio do najniższej warstwy architektury, czyli magazynu danych – możemy w tym celu wykorzystać narzędzie ntdsutil.exe.

Przykładowe polecenie zwracające informację o wolnym miejscu w bazie Active Directory na poziomie magazynu danych widoczne jest na Rys. 10.

Rys.10. Informacje o wolnym miejscu w bazie Active Directory na poziomie magazynu danych.

Rys.10. Informacje o wolnym miejscu w bazie Active Directory na poziomie magazynu danych.

W tym wypadku widzimy, że informacje są bardziej szczegółowe, natomiast brak informacji o procentowym wykorzystaniu oraz brak podsumowania końcowego. Jak więc na tym poziomie poznać ilość zajmowanego miejsca? Otóż wielkość strony (domyślnie 8 KB) należy pomnożyć przez wartość z pola „Owned” (dla osób przeliczających na powyższym przykładzie – rysunki odnoszące się do narzędzia na poziomie ESE oraz do narzędzia na poziomie magazynu danych wykonywane były w innych dniach, stąd zauważalne różnice w wielkościach po przeliczeniu.)

Wracając jeszcze na chwilę do tematu transakcji wykonywanej na bazie Active Directory – oprócz wykorzystania omówionych wcześniej plików składających się na całość magazynu danych, usługi katalogowe korzystają także, a może nawet przede wszystkim z pamięci RAM. Każdy rekord transakcji jest w pierwszej kolejności zapisywany do obiektu utrzymywanego w pamięci RAM (aby osiągnąć lepszą wydajność), skąd dopiero trafia do dziennika transakcji na dysku twardym. Miejsce w pamięci RAM, gdzie utrzymywane są obiekty, na których wykonywane będą zmiany nazywa się magazynem wersji (ang. Version store). Jest to miejsce w pamięci RAM przeznaczone do obsługi zmian, które domyślnie zajmuje 25% dostępnej pamięci. Dziennik transakcji służy jako miejsce, gdzie zapisywane są wszystkie zmiany, które następnie muszą zostać zatwierdzone na bazie danych. Ma to na celu zabezpieczenie danych przez utratą w momencie nieplanowanego wyłączenia silnika bazodanowego lub systemu. Dodatkowo, aby zabezpieczyć się przed wprowadzeniem tych samych zmian po raz kolejny – wykorzystywany jest plik, w którym zapisywane są punkty kontrolne, czyli punkty, do których transakcja została potwierdzona na bazie Active Directory. Po całościowym potwierdzeniu transakcji plik na dysku twardym może ulec skasowaniu. Co ważne – zasadnicza część procesu transakcji obsługiwana jest z wykorzystaniem pamięci RAM, a pliki na dysku twardym służą jako swego rodzaju kopia zapasowa. Pozwala to dodatkowo zaoszczędzić na operacjach I/O wykonywanych przez dysk. Jak zwykle jest „jedno małe ale” – mianowicie procent wykorzystania magazynu wersji, który w skrajnych przypadkach może ulec przepełnieniu. Aby temu zapobiec po osiągnięciu 90% wykorzystania magazynu wersji – aparat ESE zatrzymuje tymczasowo wykonywania zadań służących oczyszczaniu bazy danych Active Directory po wykonanych zmianach i usuniętych obiektach, dzięki czemu zazwyczaj udaje się uniknąć przepełnienia magazynu zmian. Co się dzieje w przypadku, gdy jednak magazyn zostanie przepełniony? W dzienniku zdarzeń odnotowany zostanie event 623 z treścią

„…Version Store size has been reached. Write operations to the database will start failing with -1069 (JET_errVersionStoreOutOfMemory) …”

Natomiast po ominięciu zdań oczyszczających widoczne będą eventy 602, które mogą nas ostrzec przed sytuacją w której magazyn zostanie przepełniony.