Friday, November 3rd, 2006...1:56 am

Linked Value Replication i kilka informacji

Jump to Comments

Hmmm … na poczÄ…tek może pytanie – jak wielu z czytelników jest zaznajomionych z terminem Linked Value Replication (LVR) w odniesieniu do katalogu Active Directory? Odpowiedź bÄ™dzie trudno uzyskać – przydaÅ‚by siÄ™ jakiÅ› mechanizm ankiet.

Pomimo że LVR jest z nami już od dłuższej chwili, Windows 2003 jest już na rynku jakiś czas, to wydaje mi się że wiedza na temat działania i benefitów LVR jest niezbyt szeroko rozpowszechniona. Stąd właśnie ten post.

Active Directory jest to katalog działający w trybie multimaster, czyli zmiany jednocześnie mogą być wykonywane na wielu kontrolerach domeny. W celu zapewnienia spójności danych Active Directory posiada zaimplementowany mechanizm replikacji danych pomiędzy poszczególnymi kontrolerami domeny. Mechanizm ten opiera się na przechowywanych dla każdego z atrybutów obiektu w Active Directory (i samego obiektu) informacjach związanych z replikacją (tak zwanych metadanych replikacji), pozwalających na określenie czy dany atrybut\ obiekt został zmieniony w stosunku do lokalnych informacji i czy musi być zreplikowany. Tak to przedstawia się w bardzo (ale to naprawdę bardzo) dużym uproszczeniu.

Active Directory zostaÅ‚o wprowadzone w Windows 2000, i w tej wersji dane niezbÄ™dne do replikacji byÅ‚y przechowywane tylko na poziomie pojedynczego atrybutu. DziaÅ‚aÅ‚o(Å‚a) to w zasadzie sprawnie z pewnym wyjÄ…tkiem jakim jest replikacja atrybutów wielowartoÅ›ciowych, w szczególnoÅ›ci informacji o czÅ‚onkostwie w grupach Active Directory. Wyobraźmy sobie sytuacjÄ™, w której mamy grupÄ™ AD z 3 tysiÄ…cami użytkowników należących do tej grupy, z której usuwamy jednego użytkownika. Ponieważ metadane replikacji przechowywane sÄ… na poziomie atrybutu potrzebne jest zreplikowanie wartoÅ›ci caÅ‚ego atrybutu, czyli informacji o 2999 użytkownikach pozostajÄ…cych w grupie (czÅ‚onkostwo w grupach przechowywane jest jako atrybut poÅ‚Ä…czony – linked attribute – informacja ta replikowana jest poprzez zawartość atrybutu memeber grupy a nie poprzez obiekt użytkownika). MaÅ‚o efektywny sposób przesyÅ‚ania informacji.

W Windows 2003 wprowadzono więc zmianę, dostępną na poziomie domeny \ lasu Windows 2003, dzięki której metadane dla atrybutów połączonych (jak member w ramach grupy) przechowywane są osobna dla każdej z wartości takiego atrybutu. Pozwala to w opisanym powyżej przypadku przesłać pomiędzy kontrolerami domeny informację tylko o zmianach dotyczących pojedynczych wartości takiego atrybutu. Informacje te przechowywane są w atrybucie msDS-ReplValueMetaData.

Istnienie tego typu wartoÅ›ci możemy obserwować “w naturze” bÄ…dź to poprzez odczyta wartoÅ›ci msDS-ReplValueMetaData poprzez LDAP, bÄ…dź też odczytujÄ…c dane replikacji korzystajÄ…c z repadmin.exe.

Wywołując repadmin.exe z przełącznikiem /showobjmeta możemy podejrzeć dane replikacji dla wybranej grupy:

Jak widać w tym przypadku mamy do czynienia z trzema wartościami atrybutu member wybranej grupy, dla jednej z nich atrybut Type przyjął wartość LEGACY, dla dwóch pozostałych PRESENT. Jako LEGACY oznaczone są wartości które zostały zapisane w tym atrybucie jeszcze przed uruchomieniem mechanizmu LVR, dlatego też przy tej wartości nie widzimy żadnych danych dotyczących replikacji. PRESENT oznacza wartość, dla której dane replikacji już istnieją.

W przypadku atrybutu member grupy oprócz wartości LEGACY oraz PRESENT możliwe jest jeszcze oznaczenie przez system wartości jako ABSENT. Ma to związek z okresem życia obiektu nagrobkowego (tombstone) dla użytkownika. W przypadku usunięcia obiektu użytkownika wpisy dla odpowiednich wartości pól member grup do których należał użytkownika oznaczane są jako ABSENT. Wartości te usuwane są dopiero po upływie czasu życia obiektu tombstone użytkownika (definiowanego przez tombstone lifetime).

Przechowywanie metadanych replikacji o czÅ‚onkostwie w grupach w ten sposób (w ogólnoÅ›ci dla wszystkich atrybutów poÅ‚Ä…czonych) okazaÅ‚o siÄ™ też sporym uÅ‚atwieniem w przypadku odtwarzania danych użytkownika po jego usuniÄ™ciu. ArtykuÅ‚ KB 840001 opisujÄ…cy to zagadnienie wyróżnia scenariusz odtworzenia konta użytkownika i jego czÅ‚onkostwa w grupach na serwerze Windows 2003 SP1. W tym przypadku, gdy odtwarzamy usuniety obiekt użytkownika narzÄ™dzie ntdsutil na podstawie informacji o poszczególnych wartoÅ›ciach atrybutu member dla tego użytkownika (patrz wyżej w okolicach sÅ‚owa ABSENT 🙂 ) generuje odpowiednie pliki LDIF, które mogÄ… zostać nastÄ™pnie użyte do odtworzenia czÅ‚onkostwa tego użytkownika w domenie Active Directory.

Na zakoÅ„cznienie jedna uwaga praktyczna – w przypadku domen, które zostaÅ‚y uaktualnione z Windows 2000 do Windows 2003 konwersja zawartoÅ›ci atrybutów poÅ‚Ä…czonych, w szczególnoÅ›ci member do postaci zgodnej z LVR nie jest wykonywana automatycznie. Oznacza to nie mniej ni wiÄ™cej, że wartoÅ›ci atrybut member istniejÄ…ce w chwili uaktualnienia domeny oznaczone sÄ… jako LEGACY i nie jest stosowana dla nich replikacjia z użyciem mechanizmu LVR.

Niestety nie ma magicznego przycisku uaktualnij wartości, i jednym sposobem konwersji takich danych jest usunięcie użytkowników z grupy i ponowne ich do niej dodanie. Brzmi przerażająco :)?, na szczęście z użyciem LDIFDE.EXE sprowadza się to do eksportu danych o członkach grupy, ich usunieciu a następnie ponownego importu.

Użwając LDIFDE.Exe możemy wyeksportować zawartość atrybutu member posługując się następującą składnią:

ldifde.exe -f naza_pliku.ldf -s <DC> -b <DN grupy> -l member

czyli, dla grupy CN=RAS Users,OU=Oddzialy,DC=W2K,DC=PL polecenie to będzie wyglądało nastepująco:

ldifde.exe -f ras_user_member.ldf -s ROOTDC -b “CN=RAS Users,OU=Oddzialy,DC=W2K,DC=PL” -l member

Uzyskaliśmy w ten sposób plik LDIF o następującym formacie:

dn: CN=Domain Admins,CN=Users,DC=w2k,DC=pl
changetype: add
member: CN=jan tomaszewski,CN=Users,DC=w2k,DC=pl
member: CN=jkowalski,CN=Users,DC=w2k,DC=pl
member: CN=Administrator,CN=Users,DC=w2k,DC=pl

Aby był bardziej przydatny do naszych celów musimy go nieznacznie zmodyfikować:

  • zmienić typ operacji na modify
  • dodać linie wskazujÄ…cÄ… że modyfikacja dotyczy pola member
  • dodać terminator LDIF czyli ‘-‘

W całości będzie on wyglądał następująco:

dn: CN=Domain Admins,CN=Users,DC=w2k,DC=pl
changetype: modify
replace: member
member: CN=Administrator,CN=Users,DC=w2k,DC=pl
member: CN=jan tomaszewski,CN=Users,DC=w2k,DC=pl
member: CN=jkowalski,CN=Users,DC=w2k,DC=pl

Zawartość atrybutu member wybranej grupy można łatwo wyczyścić korzystając z admod.exe:

admod -b “CN=RAS Users,OU=Oddzialy,DC=W2K,DC=PL” member:-:

Po wyczyszczeniu zawartości grupy możemy ten plik ponownie zaimportować używając LDIFDE.EXE w następującej składni:

ldifde.exe -i -f ras_user_member.ldf

Korzystając z repadmin.exe można łatwo sprawdzić, że teraz wszystkie wartości w grupie oznaczone są jako PRESENT.

Oczywiście przed wykonaniem tego typu operacji należy pomyśleć o:

  • poprawnej kopii zapasowej
  • poprawnej i zweryfikowanej kopii zapasowej
  • przetestowaniu wszystkiego w Å›rodowisku testowym
  • spokojnej glowie :).

Jeżeli ktoś korzysta jeszcze z Windows 2000 to wydaje mi się, że chociażby korzyści płynące z LVR są warte tego aby przesiąść się na Windows 2003.

P.S. W testach uparcie pojawia sie konto Administrator. Wynika to z tego że testy wykonywaÅ‚em na domenie Windows 2003, która nie byÅ‚a uaktualniana. Pytanie skÄ…d wynikajÄ… takie a nie inne wyniki 🙂 i jaka grupa byÅ‚a tak naprawdÄ™ używana w testach pozostawiam dla dociekliwych :).

Leave a Reply