Tym razem trochę bardziej technicznie, chociaż w kategorii rzeczy które można znaleźć na Technet, ale jak znam życie i tak się ludzkość będzie pytała więc nie zaszkodzi napisać.
Jedną ze zmian w zakresie usług katalogowych w Windows 2008 jest wprowadzenie roli Read Only Domain Controller (RODC), czyli kontrolera który może czytać, ale pisać to już nie za bardzo (chyba że lokalnie o czym może niedługo). RODC został pomyślany jako rozwiązanie dla oddziałów i biur, w których niekoniecznie wymagany jest pełny DC a ze względów bezpieczeństwa chcemy ograniczyć zakres danych przechowywanych na DC. Ale ja nie o tym.
Jedną z funkcjonalności RODC jest rozdzielenie roli lokalnego administratora od administratora domeny (yupiii, mam nadzieję że w Win 7 będzie to dotyczyło też pełnych DC). Kto zarządzał większą ilością biur czy oddziałów doceni wygodę takiego rozwiązania. W przypadku stacji roboczej albo serwera nie będącego kontrolerem domeny konta przechowywane są w bazie SAM. W przypadku kontrolera domeny (a więc i RODC) w bazie danych usługi katalogowej NTDS.DIT.
Pytanie gdzie są przechowywane lokalne role na RODC. Odpowiedź łatwa do wykoncypowania … w rejestrze 
. W rejestrze nie są przechowywane konta a tylko członkostwo użytkowników w odpowiednich rolach lokalnych. I tutaj pojawia się kwestia … zarządzania.
Rozwiązanie w tym zakresie może nie jest idealne ale cóż. Nie można mieć wszystkiego. Interfejsem, który pozwala nam na zarządzanie członkostwem w rolach lokalnych na RODC jest znane od dawna narzędzie ntdsutil.exe, które z okazji przejęcia tej zaszczytnej roli zostało rozszerzone o dodatkowe menu Local roles. A ról tych jest kilka:
Cóż, pomimo tego że ntdsutil umożliwa nam zarządzanie tymi rolami na zdalnym serwerze tudzież możemy użyc WinRS do wykonania tego zadania zdalnie nie jest to najwygodniejsze rozwiązanie. Będziemy musieli jakoś z tym żyć.
Oczywiście Ci którzy już pracowali z RODC lub czytali dokumentację wiedzą, że jest w tym całym rozwiązaniu jeden wyjątek, który powoduje że całość nie jest aż tak niemiła jak by się mogło wydawać. Cytując Dmitriego Gavrilowa (jeżeli nie wiecie kto to Dmitri a zajmujecie się AD to warto zapamietać to nazwisko ):
Management from AD: we only had resources to do this for BA, and single principal only (that’s the managedBy thingy). I’d argue that covers 95% of use cases. Doing full local roles management through AD would mean schema changes and quite a bit of work.
Zwrot “managedBy thingy” oznacza tą jedną rzecz która możliwa jest do zrobienia inaczej niż przez ntdsutil. Jeżeli chcemy uzytkownika lub grupę przypisać do roli Administrators na RODC możemy to zrobić poprzez edycje obiektu RODC w katalogu, i przypisanie tego użytkownika lub grupy jako zarządzającej obiektem poprzez managedBy.
Jeżeli chodzi o mnie to zgadzam się z Dmitrim, że takie rozwiązanie załatwia 95% przypadków i w tym przypadku akurat znakomicie się sprawdza.
Jedno co mi się nie podoba w tym wypadku, to fakt że użytkownik lub grupa przypisana poprzez atrybut managedBy jako pełniący rolę lokalnego administratora na RODC nie jest widoczna w ntdsutil po wydaniu polecenia Show role Administrators. Mały brak spójności. Można z tym żyć, ale wolałbym żeby było to spójne.
I tak to oto doszliśmy do końca tego odcinka. Coś jednak czuję, że RODC jeszcze kilka razy wróci jako główny bohater opowiadań na w2k.pl.