Wednesday, February 27th, 2008...10:12 pm

Role lokalne na RODC

Jump to Comments

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.

3 Comments

  • Szczerze mówiąc – czekam na tę funkcjonalność już od momentu usłyszenia o niej (na jednej z sesji MTS’2006), choć nie usłyszałem wtedy (lub nie było dopowiedziane), że dotyczy ona jedynie RODC. Ale przydatne w ‘branch-office’owej’ strukturze tak czy inaczej (pomijając fakt, że przejście na Win2k8 w mojej firmie to pewnie nie tak prędko…).
    Na marginesie zastanawia mnie tylko, czy skutek przypisania użytkownika/grupy do atrybutu ‘managedBy’ obiektu, nadający uprawnienia administracyjne wobec tego obiektu, dotyczy jedynie RODC, wybranej podgrupy obiektów (np. tylko komputerów) czy też po prostu każdego obiektu posiadającego opcję ‘managedBy’?

    z pozdrowieniami

    Jakub

  • AFAIR to nie (chyba że o czymś nie wiem). Możliwe jest takie nadanie uprawnień pośrednio na grupie – to znaczy dla grupy zaznaczasz “Manager can update membership list” i wtedy odpowiednie ACL sa tworzone zeby temu kto jest wskazany jako manager grupy umozliwic zarzadzanie jej czlonkostwem.

  • Z grupą i updatem listy członków to wiem. Zastanawianie wynikało stąd, że samo ‘Managed by’ jest od początku (chyba?) w AD, ale nigdy nic za tym nie szło ‘w tle’, jeśli chodzi o uprawnienia. Stąd i pytanie (oraz z wygodnictwa – że się nie chciało sprawdzić samemu, ale trochę jak zwykle z czasem krucho…).
    A wniosek taki, że to może być trochę mylące, iż w jednym miejscu z wypełnienia tego atrybutu nic nie wynika, a drugim (i to nie tak całkiem mało istotnym) idą za tym jakieś uprawnienia. Jeśli ktoś używał do tej pory tylko i wyłącznie informacyjnie takiego ‘Managed by’, to może się zdziwić 😉

    z pozdrowieniami

    Jakub

Leave a Reply