Śledzenie zmian w AD


Kilka dni temu dostalem od kolegi ciekawe pytanie, doslownie brzmiace "Czy da sie zrobic trigger w AD"? W pytaniu jest oczywista analogia do baz SQL, ale intencja byla taka, zeby w jakis sposób powiadamiac aplikacje, skrypt albo cokolwiek innego, ze bazie danych Active Directory zaszla zmiana. Przydatne to moze byc w wielu scenariuszach. Od zautomatyzowanego zakladania kont w innych systemach az po wysylanie powitalnych maili dla nowych uzytkowników zalozonych w AD. Mozna tez uzyc takiego mechanizmu dla prowadzenia zautomatyzowanego dziennika zmian albo dla tysiaca innych celów.

Zdradzajac puente napisze, ze odpowiedz na powyzsze pytanie to: da sie!
Ale moze lepiej jakos inaczej?

  • Metoda pierwsza: okresowo czytac dane z AD i sprawdzac czy cos sie zmienilo od ostatniego odczytu. Sugeruje tylko odczytywanie atrybutu uSNChanged i sprawdzanie ta metoda, czy warto odczytac cos wiecej. Oszczedzi to troche zasoby AD przed zameczeniem przez zbyt nachalne aplikacje.
  • Wady:
  • duza zwykle ilosc "pustych" przebiegów, kiedy pytajacy stale neka AD, a w odpowiedzi slyszy odpowiedz, ze znowu nie ma zadnych zmian
  • opóznienie wynikajace z faktu, ze pytanie o zmiany zadawane jest tylko co jakis czas
  • marne wykorzystanie potencjalu AD
  • Zalety:
  • prostota koncepcji
  • nie wymaga wysokich uprawnien w AD
  • Metoda druga: DirSync. Tez opiera sie na okresowym odpytywaniu o dane, za to wykorzystanie potencjalu AD pozwala na zadawanie pytan zawierajacych cookie opisujace stan bazy LDAP podczas poprzedniego zapytania. W efekcie to nie aplikacja musi sama wszystkiego pilnowac. Wystarczy, ze powie LDAPowi jaki poprzednio byl wynik zapytania.
  • Wady:
  • opóznienie wynikajace z faktu, ze pytanie o zmiany zadawane jest tylko co jakis czas
  • koniecznosc posiadania uprawnienia SE_SYNC_AGENT_NAME na kontrolerze domeny
  • trudne zawezanie zapytan do malej czesci katalogu
  • Zalety:
  • mniejsze obciazenie AD
  • Metoda trzecia: Change Notifications. Czyli wlasnie cos przypominajacego trigger. Funkcja ldap_search_ext wywolywana w taki sposób, ze aplikacja dostaje wynik wtedy, gdy w katalogu zajdzie zmiana.
  • Wady:
  • wieksza zlozonosc, typowa dla asynchronicznych wywolan
  • mozliwosc zarejestrowania tylko pieciu wlasnych funkcji
  • Zalety:
  • natychmiastowe powiadamianie o zmianach
  • brak zbednego obciazania AD ciaglymi zapytaniami

Która z metod jest najlepsza? To zalezy od scenariusza. Natychmiastowe powiadamianie (opisane w metodzie trzeciej) jest kuszace, ale naprawde bardzo rzadko potrzebne. Czasem prostota jest warta znacznie wiecej. Tak czy inaczej, trzeba znalezc zloty srodek pomiedzy zlozonoscia, szybkoscia powiadamiania i obciazeniem AD zapytaniami.

Troche wyszlo progamistycznie, bo jednak typowy administrator nie zaimplementuje tego w prosty sposób systemowymi narzedziami. Ale tak juz czasem bywa, ze trzeba wspólpracowac. Programisci, sami z siebie zbyt slabo zwykle znaja mechanizmy AD, zeby powiadamianie o zmianach zaimplementowac bez pomocy specjalisty IT.

Autor: Grzegorz Tworek [MVP]

PS Mozna tez powiadamiac o zmianach hasel, ale to juz zupelnie inna historia i pewnie ten temat tez kiedys detalicznie opisze.

Comments (8)

  1. Anonymous says:

    @Tomek: Przejrzałem dokładnie KB i opis na MSDN i

    a) w KB piszą, że można na 3 sposoby, ale opisują tylko dwa. Więc skorzystanie z gotowego KB dałoby mi tylko tą bardziej kulawą część rozwiązania.

    b) w MSDN opisane są już wszystkie trzy sposoby i osobiście nie widzę powodów do obaw. Asynchroniczne wyszukiwanie w AD (a do tego sprowadza się change notification) jest od wielu lat znane i zasadniczo działa, jeżeli tylko nic nie popsuje używający go programista 😉

  2. Anonymous says:

    @mgrzeg: dzięki, na pewno warto jedno z drugim połączyć, żeby mieć pełny obraz

    @Tomek: no ale tylko trzecia metoda jest naprawdę asynchroniczna… a dwie pierwsze to tylko udawanie 😉

    A metoda #1 działa z mniejszymi uprawnieniami. To czasem istotna zaleta.

  3. Anonymous says:

    Kiedyś się nad tym zastanawiałem, ale nie pociągnąłem dalej. Dzięki za nadanie kierunku.

  4. Anonymous says:

    No właśnie starałem się opisać, że nic za darmo i dać do wyboru.

    Pierwsza metoda i tak wymaga samodzielnego porównania jak było i jak jest  w katalogu a uSNChanged to tylko pretekst do głębszego zapytania. Jak dostaniesz "false positive" przez ten atrybut to wiele nie stracisz.

  5. mgrzeg says:

    Temat jakis czas temu zagoscil na forum wss:

    wss.pl/frmThread.aspx

    m.g.

  6. ToMeK says:

    Trzeba się było odpytać 🙂 … tak wiem, sameu fajniej dojść, ale jest na to artykuł KB: support.microsoft.com/…/891995.

    Co do metody #3 to jeszcze nie widziałem jej w implementacji i nie wiem czy byłaby komuś potrzeba + jako że mało używana to może być nieprzestowana. Pozatym nie widzę potrzeby jej używania.

    W praktyce aplikacje w większości korzystają z metody #2. Rzadko kiedy z metody #1.

    Co do implementacji przy użyciu narzędzi – cóż … repadmin /showchanges.

  7. ToMeK says:

    @Grześ

    No tak – ale usnChanged jest lokalny dla DC więc jak DC padnie to i jest problem +nie można filtrować po atrybutach na przykład. NIc za darmo 🙂

    Wszystko pieknie jest opisane na MSDN:
    msdn.microsoft.com/…/ms677974%28v=VS.85%29.aspx

  8. peki says:

    Jeśli chcemy tylko prosty system, który nam pokaże np. zmiany w grupach, czy zmiany w użytkownikach, to jest 4 metoda od win 2k8. Można zastosować audyt AD, a następnie parsować eventlogi z kontrolerów domen.

    Wady:

    -wymaga dużej ilości miejsca na DC, do przechowywania EventLogów Security

    -wymaga instalacji parsera na każdym DC

    Zalety:

    -nie trzeba być programistą – wystarczy stworzyć trigger na EventLog, i podpiąc pod niego akcję

    -można przetwarzać po godzinach

Skip to main content