Ś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

• Przyklad: https://msdn.microsoft.com/en-us/library/ms676895(v=VS.85).aspx

• 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

• Przyklad: https://msdn.microsoft.com/en-us/library/ms676896(v=VS.85).aspx

• 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

• Przyklad: https://msdn.microsoft.com/en-us/library/ms676877(v=VS.85).aspx

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

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  @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.

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

• Anonymous
  January 01, 2003
  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.

• Anonymous
  September 06, 2010
  Temat jakis czas temu zagoscil na forum wss: wss.pl/frmThread.aspx m.g.

• Anonymous
  September 06, 2010
  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.

• Anonymous
  September 06, 2010
  @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

• Anonymous
  September 06, 2010
  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