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