Udostępnij przez

Sondowanie zmian za pomocą kontrolki DirSync

Kontrolka synchronizacji katalogów Active Directory (DirSync) to rozszerzenie serwera LDAP, które umożliwia aplikacji wyszukiwanie partycji katalogu dla obiektów, które uległy zmianie od poprzedniego stanu.

Użyj kontrolki DirSync za pomocą interfejsu ADSI, określając preferencję wyszukiwania ADS_SEARCHPREF_DIRSYNC podczas korzystania z IDirectorySearch. Aby uzyskać więcej informacji i przykład kodu, zobacz przykład kodu używającego ADS_SEARCHPREF_DIRSYNC . Możesz również przeprowadzić wyszukiwanie DirSync przy użyciu interfejsu API LDAP. Poniżej opisano implementację interfejsu ADSI, z których większość ma zastosowanie również do bezpośredniego używania protokołu LDAP, z wyjątkiem opisanych na końcu tego tematu.

Podczas wyszukiwania dirSync przekazujesz element danych specyficzny dla dostawcy (cookie), który identyfikuje stan katalogu w momencie poprzedniego wyszukiwania DirSync. W przypadku pierwszego wyszukiwania przekazujesz plik cookie o wartości null, a wyszukiwanie zwraca wszystkie obiekty zgodne z filtrem. Wyszukiwanie zwraca również prawidłowy plik cookie. Zapisz plik cookie w tym samym magazynie, który jest synchronizowany z serwerem Active Directory. Podczas kolejnych wyszukiwań pobierz plik cookie z magazynu i przekaż go za pomocą żądania wyszukiwania. Wyniki wyszukiwania zawierają teraz tylko obiekty i atrybuty, które uległy zmianie od poprzedniego stanu zidentyfikowane przez plik cookie. Wyszukiwanie zwraca również nowy plik cookie do przechowywania na potrzeby następnego wyszukiwania.

W poniższej tabeli wymieniono parametry wyszukiwania, które może określić żądanie wyszukiwania klienta.

Parametr Opis
Podstawa wyszukiwania Podstawa wyszukiwania DirSync musi być korzeniem partycji katalogu, która może być partycją domeny, partycją konfiguracji lub partycją schematu.
Zakres Zakres wyszukiwania DirSync musi być ADS_SCOPE_SUBTREE, czyli całego poddrzewa partycji. Należy pamiętać, że w przypadku wyszukiwania partycji domeny poddrzewo obejmuje nagłówki, ale nie zawartość, partycji konfiguracji i schematu. Aby monitorować zmiany w mniejszym zakresie, użyj techniki USNChanged zamiast narzędzia DirSync.
Filtr Można określić dowolny prawidłowy filtr wyszukiwania. W przypadku początkowego wyszukiwania z plikiem cookie o wartości null wyniki obejmują wszystkie obiekty zgodne z filtrem. W przypadku kolejnych wyszukiwań z prawidłowym plikiem cookie wyniki wyszukiwania zawierają dane tylko dla obiektów, które pasują do filtru i zostały zmienione od stanu wskazanego przez plik cookie. Aby uzyskać więcej informacji na temat filtrów wyszukiwania, zobacz Tworzenie filtru zapytania.
Atrybuty Można określić listę atrybutów, które mają być zwracane po zmianie. Dla każdego obiektu początkowe wyniki obejmują wszystkie żądane atrybuty ustawione na obiekcie. Kolejne wyniki wyszukiwania obejmują tylko określone atrybuty, które uległy zmianie. Niezmienione atrybuty nie są uwzględniane w wynikach wyszukiwania. W implementacji ADSI wyniki wyszukiwania zawsze zawierają objectGUID i instanceType każdego obiektu. Ponadto określona lista atrybutów działa jako dodatkowy filtr: początkowe wyniki wyszukiwania obejmują tylko obiekty, które mają co najmniej jeden z określonych atrybutów zestawu; kolejne wyszukiwania obejmują tylko obiekty, na których zmieniono co najmniej jeden atrybut (dodane lub usunięte wartości).

 

Należy również pamiętać, że:

  • W przypadku wyszukiwań przyrostowych najlepszym rozwiązaniem jest powiązanie z tym samym kontrolerem domeny (DC) używanym w poprzednim wyszukiwaniu, czyli kontrolerem domeny, który wygenerował plik cookie. Jeśli ten sam kontroler domeny nie jest dostępny, poczekaj, aż stanie się dostępny, lub połącz się z nowym kontrolerem domeny i wykonaj pełną synchronizację. Zapisz nazwę DNS kontrolera domeny w magazynie pomocniczym za pomocą pliku cookie.

    Plik cookie wygenerowany przez jeden kontroler domeny można przekazać do innego kontrolera domeny hostując replikę tej samej partycji katalogu. Nie ma możliwości, aby klient przegapił zmiany, korzystając z pliku cookie z jednego kontrolera domeny (DC) na innym kontrolerze domeny (DC). Istnieje jednak możliwość, że wyniki wyszukiwania z nowego kontrolera domeny mogą zawierać zgłoszone zmiany przez stary kontroler domeny; w niektórych przypadkach nowy kontroler domeny może zwrócić wszystkie obiekty i atrybuty, tak jak w przypadku pełnej synchronizacji. Klient powinien po prostu zapewnić spójność bazy danych z zgłoszonymi wynikami wyszukiwania dla dowolnego wywołania narzędzia DirSync, czyli obsłużyć wszystkie wyniki przyrostowe tak, jakby były najnowszym stanem. Nie ma znaczenia, czy widziałeś tę zmianę wcześniej, czy nawet wracasz do poprzedniego stanu, ponieważ powtarzające się przyrostowe synchronizacje dążą do osiągnięcia spójności.

  • Istnieje również możliwość, że inny kontroler domeny odrzuca plik cookie zwrócony z oryginalnego kontrolera domeny. Wyszukiwanie generuje błąd LDAP na serwerze, taki jak "0000203D: LdapErr: DSID-xxxxxxxx, comment: Error processing control, data 0", oraz aplikacja kliencka może wygenerować błąd, taki jak "System.DirectoryServices.Protocols.DirectoryOperationException: Wystąpił błąd protokołu". Może się to zdarzyć na przykład wtedy, gdy ciasteczko jest starsze, a oczekiwana wewnętrzna zawartość tego ciasteczka powinna być inna podczas przetwarzania przez serwer LDAP działający na innej wersji systemu Windows. Plik cookie jest nieprzezroczystą strukturą i nie gwarantuje spójności strukturalnej we wszystkich wersjach systemu operacyjnego Windows. Aplikacja kliencka powinna obsługiwać ten przypadek i ponowić próbę z pełną synchronizacją, jeśli wystąpi ten błąd.

  • Jeśli obiekt zostanie zmieniony lub przeniesiony, jego obiekty podrzędne, jeśli istnieją, nie zostaną uwzględnione w wynikach wyszukiwania, mimo że nazwy wyróżniające obiektów podrzędnych uległy zmianie. Podobnie, gdy dziedziczona ACE jest modyfikowana w deskryptorze zabezpieczeń obiektu, obiekty podrzędne obiektu nie są uwzględniane w wynikach wyszukiwania, mimo że deskryptory zabezpieczeń obiektów podrzędnych uległy zmianie.

  • Użyj atrybutu objectGUID, aby zidentyfikować śledzone obiekty. objectGUID każdego obiektu pozostaje niezmieniona niezależnie od tego, gdzie obiekt jest przenoszony w lesie.

  • Należy pamiętać, że wyniki wyszukiwania dirSync wskazują stan obiektów w replice partycji katalogu w czasie wyszukiwania. Oznacza to, że zmiany wprowadzone na innych kontrolerach domeny nie zostaną uwzględnione, jeśli nie zostały zreplikowane do docelowego kontrolera domeny. Oznacza to również, że atrybuty obiektu mogły ulec zmianie kilka razy od poprzedniego wyszukiwania DirSync, ale wyszukiwanie będzie pokazywać tylko stan końcowy, a nie sekwencję zmian.

  • W implementacji ADSI aplikacja musi traktować ciasteczko jako nieprzejrzyste, bez ujawniania szczegółów jego wewnętrznej struktury czy wartości.

  • Należy pamiętać, że klient przechowuje plik cookie, długość pliku cookie oraz nazwę DNS kontrolera domeny w tym samym miejscu, które zawiera dane synchronizowanego obiektu. Dzięki temu plik cookie i inne parametry pozostają zsynchronizowane z danymi obiektu, jeśli magazyn zostanie kiedykolwiek przywrócony z kopii zapasowej.

  • Aby pobrać atrybut parentGUID, który jest skonstruowany dla kontrolki DirSync, należy również zażądać atrybutu nazwy.

Aby użyć kontrolki DirSync, obiekt wywołujący musi mieć uprawnienie "pobieranie zmian katalogu" przypisane do katalogu głównego monitorowanej partycji. Domyślnie to prawo jest przypisywane do kont Administrator i LocalSystem na kontrolerach domeny. Dzwoniący musi również mieć DS-Replication-Get-Changes prawo dostępu do rozszerzonej kontroli. Aby uzyskać więcej informacji na temat implementowania mechanizmu śledzenia zmian dla aplikacji, które muszą być uruchamiane na koncie, które nie ma tego prawa, zobacz Sondowanie zmian przy użyciuUSNChanged. Aby uzyskać więcej informacji na temat uprawnień, zobacz Uprawnienia.

Wyniki wyszukiwania ADS_SEARCHPREF_DIRSYNC automatycznie zawierają usunięte obiekty (grobowce), które pasują do określonego filtru wyszukiwania. Jednak filtr wyszukiwania, który będzie pasował do obiektu, gdy jest aktywny, może nie być zgodny z obiektem po jego usunięciu. Dzieje się tak, ponieważ grobowce zachowują tylko podzbiór atrybutów znajdujących się na oryginalnym obiekcie. Na przykład w przypadku obiektów użytkownika zazwyczaj należy użyć następującego filtru.

(&(objectClass=user)(objectCategory=person))

Atrybut objectCategory jest usuwany po usunięciu obiektu, więc powyższy filtr nie pasuje do żadnych obiektów grobowca. Z drugiej strony atrybut objectClass jest zachowywany na obiektach nagrobkowych, więc filtr "(objectClass=user)" dopasuje się do usuniętych obiektów użytkownika.

Lista atrybutów określona za pomocą wyszukiwania DirSync działa również jako filtr; Wyniki wyszukiwania obejmują tylko obiekty, na których co najmniej jeden z określonych atrybutów uległ zmianie od czasu poprzedniego wyszukiwania DirSync. Jeśli lista atrybutów nie zawiera żadnych atrybutów, które są przechowywane na grobowcach, wyniki wyszukiwania nie będą zawierać grobowce. Aby to obsłużyć, zażądaj wszystkich atrybutów, określając listę atrybutów o wartości null; lub możesz zażądać atrybutu isDeleted ustawionego na wartość TRUE na wszystkich grobowcach. Atrybuty tombstone mają bit 0x8 ustawiony w searchFlags definicji atrybutu atrybutSchema.

Aby uzyskać więcej informacji, zobacz Pobieranie usuniętych obiektów.

Implementacja LDAP kontrolki DirSync

Możesz również przeprowadzić wyszukiwanie dirSync przy użyciu interfejsu API LDAP z kontrolką LDAP_SERVER_DIRSYNC_OID. Jeśli używasz interfejsu API LDAP, określ również kontrolki LDAP_SERVER_EXTENDED_DN_OID i LDAP_SERVER_SHOW_DELETED_OID. Kontrolka LDAP_SERVER_EXTENDED_DN_OID powoduje, że wyszukiwanie LDAP zwraca rozszerzoną formę nazwy wyróżniającej (distinguished name), która zawiera objectGUID i objectSID dla obiektów głównych zabezpieczeń, takich jak użytkownicy, grupy i komputery. Kontrolka LDAP_SERVER_SHOW_DELETED_OID powoduje, że wyniki wyszukiwania zawierają dane dla usuniętych obiektów. Należy pamiętać, że te kontrolki są automatycznie uwzględniane w implementacji ADSI.

 

 

  • Last updated on