Thursday, September 21st, 2006...10:35 pm

Śledzenie zmian na obiektach katalogu, czyli "Kto skasował ten obiekt?"

Jump to Comments

Od czasu do czasu zdarza siÄ™ że na grupie dyskusyjnej pada pytanie “Jak sprawdzić kto usunÄ…Å‚ obiekt użytkownika z katalogu?”. Jako że pada pytanie, to postanowiÅ‚em udzielić w ramach tego blogu przynajmniej częściowej na nie odpowiedzi – może przyda siÄ™ komuÅ› zaczynajÄ…cemu pracÄ™ z katalogiem Active Directory (w zasadzie też ADAM).

Systemy z rodziny Windows 2000\2003 posiadają wbudowane mechanizmy inspekcji zdarzeń, które mogą być również użyte do śledzenia zmian na obiektach w ramach katalogu Active Directory. Nie jest to może idealny mechanizm jeżeli popatrzymy na niego z punktu widzenia wygody używania, w szczególności analizy danych zgromadzonych w dziennikach zdarzeń, ale jego zaletą jest napewno to że jest dostępny w systemie i pozwola nam na zbieranie danych o tym kto dokonywał zmian w katalogu. W połączeniu z oprogramowaniem monitorującym dzienniki zdarzeń pozwala na wychwycenie tego typu zdarzeń i prześledzenie zmian na obiekcie. Dla osób wymagających bardziej rozbudowanych funkcji śledzenia zmian, w szczególności dla tych którzy muszą spełniac kryteria zgodności z różnego rodzaju regulacjami, jak chociażby SOX dostępne są rozwiązania komercyjne.

Przejdźmy wiÄ™c do rzeczy – jak można uzyskać dostÄ™p do danych o tym kto modyfikowaÅ‚ dane obiektów w katalogu AD\ADAM. Aby skorzystać z tej możliwoÅ›ci musimy zrobić dwie rzeczy:

  1. Włączyć inspekcje zdarzeń dostępu do obiektów katalogu (directory services access) w ramach Default Domain Controllers policy (inspekcja tych zdarzeń poza DC nie ma raczej sensu).
  2. Skonfigurować odpowiednie SACL na obiektach, dla których chcemy przeprowadzić inspekcję.SACL to skrót od System Access Control List, który oznacza listę składającą się z ACE (Access Control Entries), określającą dla jakiej grup\użytkowników ma być przeprowadzona inspekcja wybranego typu zdarzeń na wskazanych obiektach. SACL można skonfigurować miedyz innymi przy pomocy zakładki Security konsoli Active Directory Users and Computers lub poprzez ldp.exe w wersji pochodzącej z ADAM SP1 (Windows 2003 Server R2). Na SACL każdego obiektu składa się lista ACE, które definiują co i dla kogo będzie w trakcie modyfikacji obiektu poddane inspekcji.Poniżej przedstawiony został rysunek z dialogiem definiującym wpis do SACL z poziomu ADU&C.

Skonfigurowane SACl można zweryfikować z poziomu ldp.exe lub innego narzędzia które pozwala na zrzut skonfigurowanych dla obiektu SACL. Poniżej przedstawiony został zrzut skonfigurowanego w poprzednim oknie dialogowym ustawienia z poziomu LDP.EXE.

Ace[0]
Ace Type: 0x7 – SYSTEM_AUDIT_OBJECT_ACE_TYPE
Ace Size: 56 bytes
Ace Flags: 0xc6
CONTAINER_INHERIT_ACE
NO_PROPAGATE_INHERIT_ACE
Object Ace Mask: 0x00000002
ACTRL_DS_DELETE_CHILD
Object Ace Flags: 0x1
ACE_OBJECT_TYPE_PRESENT
Object Ace Type: user – bf967aba-0de6-11d0-a285-00aa003049e2
Object Ace Sid: W2K\Domain Admins S-1-5-21-1885536488-2434298766-162818185-512

Wyposażeni w mechanizm pozwalający na śledzenie zmian spróbujmy z niego skorzystać w pożytecznym celu. Pytanie: jak możemy określić kto skasował dany obiekt z katalogu w środowisku z wieloma administratorami i wieloma kontrolerami domeny?

Niestety w wiÄ™kszoÅ›ci przypadków, pomimo tego że inspekcja zdarzeÅ„ dostÄ™pu do jest wÅ‚Ä…czona, raczej nie zostaÅ‚y skonfigurowane żadne ustawienia inspekcji na obiektach, w zwiÄ…zku z czym nie zostaÅ‚y zarejestrowane żadne zdarzenia zwiÄ…zane ze zmianami na obiektach (w szczególnoÅ›ci usuniÄ™cia obiektu) w dzienniku zdarzeÅ„ kontrolera domeny. W takim wypadku pozostaje nam jedynie spróbować uzyskać “poÅ›redniÄ…” informacjÄ™ poprzez analize danych o uprawnieniach i zdarzeniach logowania do kontrolera domeny. Jeżeli jesteÅ›my w stanie odtworzyć usuniÄ™ty obiekt, możemy sprawdzić uprawnienia na tym obiekcie i ustalić użytkowników\grupy którzy posiadali wystarczajÄ…ce uprwanienia do tego aby usunąć obiekt z katalogu. W sposób opisany za chwilÄ™, możemy ustalić na którym z kontrolerów domeny i kiedy obiekt zostaÅ‚ usuniety – dysponujÄ…c tÄ… informacjÄ… możemy przeszukać dziennik zdarzeÅ„ kontrolera pod kÄ…tem informacji kto z tej grupy użytkowników byÅ‚ zalogowany na tym kontrolerze domeny w trakcie gdy obiekt zostaÅ‚ usuniety. Nie dostarczy nam to dokÅ‚adnej informacji ale jest to pewne przybliżenie.

W szczęśliwym przypadku gdy posiadaliśmy ustawione odpowiednie opcje inspekcji dla obiektu który został usuniety, jesteśmy w stanie dokładnie określić kto dokonał tej operacji. Na początek musimy ustalić gdzie i kiedy została ona wykonana. W tym celi posłużymy sie danymi związanymi z replikacją, poszukując kontrolera domeny na którym wprowadzona została dla obiektu wartość atrybutu IsDeleted. Atrybut ten ustawiany jest dla obiektów typu tombstone w chwili usunięcia obiektu i zamiany go w tombstone. Aby przejrzeć dane obiektu znajdującego się po usunięciu w kontenerze deleted items potrzebować będziemy jego DN lub GUID, oba łatwe do uzyskania z użyciem ldp.exe lug adfind.exe. Mając DN tego obiektu możemy użyc opcji /showobjmeta narzędzia repadmin w celu wyświetlenia metadanych replikacji dla tego obiektu, uzyskując wynik podobny do przedstawionego poniżej.

Jak widać zmiana która nas interesuje została wprowadzona na kontrolerze ROOTDC o 23:59. To co teraz musimy wkonać to przejrzeć dziennik zabezpieczeń na ROOTDC w poszukiwaniu zdarzenia o ID 630 zapisanego w tych godzinach.
Event Type: Success Audit
Event Source: Security
Event Category: Account Management
Event ID: 630
Date: 9/21/2006 Time: 12:02:16 AM
User: W2KAdministrator
Computer: ROOTDC
Description:User Account Deleted:
Target Account Name: jnowak
Target Domain: W2K
Target Account ID: Jan NowakDEL:0bd8f9df-1586-42cd-9d4e-76d7ae174514
Caller User Name: Administrator
Caller Domain: W2K
Caller Logon ID: (0x0,0x188D2)
Privileges:

Jak widać obiekt ten został usunięty przez użytkownika W2k\Administrator (niedobry admin). Jak widać w tym wypadku rzecz była prosta do wyśledzenia, w innych podobnych możemy posłużyć sie dokładnie taką samą metodą.

To o czym powinniśmy pamietać konfigurując inspekcję zdarzeń (nie tylko dostępu do danych katalogu) to fakt że wprowadza to dodatkowe obciążenie systemu jeżeli chodzi o wydajnośc. Zbyt wiele danych które mają zostać poddane inspekcji może znacząco wpłynąć na wydajność systemu. Tak więc zawsze należy ustalić pewien kompromis pomiędzy informacją\bezpieczeństwem a wydajnością. Może nam w tym pomóc trzymanie się dwóch prostych zasad:

  • Jeżeli jesteÅ›my zainteresowani Å›ledzeniem zdarzeÅ„ okreÅ›lonego typu dla wybranej grupy obiektów ustalmy kto ma prawo do wykonania tej operacji i ustawmy odpowiednie SACL dla tych wybranych użytkowników\grup. Zmniejszy to ilość wpisów o inspekcji które system bÄ™dzie musiaÅ‚ przetwarzać.
  • Unikajmy podejÅ›cia “wszystko o wszystkich”, czyli Å›ledzenia wszystkich możliwych zmian, dla wszystkich użytkowników na wszystkich obiektach. Oprócz tego że prawie napewno wpÅ‚ynie to źle na wydajność naszego kontrolera domeny to zapeÅ‚ni nam dziennik zdarzeÅ„ takÄ… iloÅ›cia informacji że trudno bÄ™dzie nam w niej odnaleźć pożyteczne informacje.

W zasadzie to wszytko w tym temacie na tą chwilę, niedługo postaram się napisać coś o inspekcji zdarzeń w LH.

Comments are closed.