Śledzenie zmian w AD

Śledzenie zmian w AD

  • Comments 8
  • Likes

Kilka dni temu dostałem od kolegi ciekawe pytanie, dosłownie brzmiące "Czy da się zrobić trigger w AD"? W pytaniu jest oczywista analogia do baz SQL, ale intencja była taka, żeby w jakiś sposób powiadamiać aplikację, skrypt albo cokolwiek innego, że bazie danych Active Directory zaszła zmiana. Przydatne to może być w wielu scenariuszach. Od zautomatyzowanego zakładania kont w innych systemach aż po wysyłanie powitalnych maili dla nowych użytkowników założonych w AD. Można też użyć takiego mechanizmu dla prowadzenia zautomatyzowanego dziennika zmian albo dla tysiąca innych celów.

Zdradzając puentę napiszę, że odpowiedź na powyższe pytanie to: da się!
Ale może lepiej jakoś inaczej?

  • Metoda pierwsza: okresowo czytać dane z AD i sprawdzać czy coś się zmieniło od ostatniego odczytu. Sugeruję tylko odczytywanie atrybutu uSNChanged i sprawdzanie tą metodą, czy warto odczytać coś więcej. Oszczędzi to trochę zasoby AD przed zamęczeniem przez zbyt nachalne aplikacje.
  • Wady:
  • duża zwykle ilość "pustych" przebiegów, kiedy pytający stale nęka AD, a w odpowiedzi słyszy odpowiedź, że znowu nie ma żadnych zmian
  • opóźnienie wynikające z faktu, że pytanie o zmiany zadawane jest tylko co jakiś czas
  • marne wykorzystanie potencjału AD
  • Zalety:
  • prostota koncepcji
  • nie wymaga wysokich uprawnień w AD
  • Metoda druga: DirSync. Też opiera się na okresowym odpytywaniu o dane, za to wykorzystanie potencjału AD pozwala na zadawanie pytań zawierających cookie opisujące stan bazy LDAP podczas poprzedniego zapytania. W efekcie to nie aplikacja musi sama wszystkiego pilnować. Wystarczy, że powie LDAPowi jaki poprzednio był wynik zapytania.
  • Wady:
  • opóźnienie wynikające z faktu, że pytanie o zmiany zadawane jest tylko co jakiś czas
  • konieczność posiadania uprawnienia SE_SYNC_AGENT_NAME na kontrolerze domeny
  • trudne zawężanie zapytań do małej części katalogu
  • Zalety:
  • mniejsze obciążenie AD
  • Metoda trzecia: Change Notifications. Czyli właśnie coś przypominającego trigger. Funkcja ldap_search_ext wywoływana w taki sposób, że aplikacja dostaje wynik wtedy, gdy w katalogu zajdzie zmiana.
  • Wady:
  • większa złożoność, typowa dla asynchronicznych wywołań
  • możliwość zarejestrowania tylko pięciu własnych funkcji
  • Zalety:
  • natychmiastowe powiadamianie o zmianach
  • brak zbędnego obciążania AD ciągłymi zapytaniami

Która z metod jest najlepsza? To zależy od scenariusza. Natychmiastowe powiadamianie (opisane w metodzie trzeciej) jest kuszące, ale naprawdę bardzo rzadko potrzebne. Czasem prostota jest warta znacznie więcej. Tak czy inaczej, trzeba znaleźć złoty środek pomiędzy złożonością, szybkością powiadamiania i obciążeniem AD zapytaniami.

Trochę wyszło progamistycznie, bo jednak typowy administrator nie zaimplementuje tego w prosty sposób systemowymi narzędziami. Ale tak już czasem bywa, że trzeba współpracować. Programiści, sami z siebie zbyt słabo zwykle znają mechanizmy AD, żeby powiadamianie o zmianach zaimplementować bez pomocy specjalisty IT.

Autor: Grzegorz Tworek [MVP]

PS Można też powiadamiać o zmianach haseł, ale to już zupełnie inna historia i pewnie ten temat też kiedyś detalicznie opiszę.

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

  • Temat jakis czas temu zagoscil na forum wss:

    wss.pl/frmThread.aspx

    m.g.

  • 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.

  • @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.

  • @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

  • 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.

  • @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 ;)

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment