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