Kontrolery tylko do odczytu (Read Only Domain Controler)

Opublikowano: 14 marca 2008

Kontroler domeny tylko do odczytu (Read Only Domain Controler) to nowy rodzaj kontrolera domeny w systemie operacyjnym Windows Server® 2008. Kontroler RODC jest przeznaczony do zastosowania w lokalizacjach, w których nie można zagwarantować fizycznego bezpieczeństwa. RODC służy jako host partycji tylko do odczytu bazy danych Active Directory® Domain Services (AD DS).

Przed wydaniem Windows Server 2008, jeśli użytkownicy musieli uwierzytelniać się na kontrolerze domeny w sieci WAN, nie było żadnej alternatywy w stosunku do zastosowania pełnego kontrolera domeny. W wielu wypadkach nie było to dobre wyjście. Oddziały firmy często nie mogą zapewnić odpowiedniego stopnia bezpieczeństwa fizycznego dla zapisywalnego kontrolera domeny. Oprócz tego oddziały dysponują również często niewielką przepustowością sieci, kiedy są połączone z witryną centralną. Może to zwiększyć ilość czasu potrzebną na zalogowanie. Może to również utrudnić dostęp do zasobów sieciowych.

W Windows Server 2008 organizacja może wdrożyć kontroler RODC, co umożliwia rozwiązanie tego rodzaju problemów. W rezultacie użytkownicy otrzymają następujące korzyści:

• Większe bezpieczeństwo
• Szybsze logowanie
• Wydajniejszy dostęp do zasobów sieciowych

Zawartość strony

	Przeznaczenie RODC?
	Nowa funkcjonalność RODC
	Wymagania dla wdrożenia RODC:

Przeznaczenie RODC?

Niewystarczające zabezpieczenia fizyczne to najczęstszy powód, aby rozważyć wdrożenie kontrolera RODC. RODC pozwala na wdrożenie bezpieczniejszego kontrolera domeny w lokalizacjach wymagających szybkich i niezawodnych usług uwierzytelniania, w których nie można jednak zapewnić pełnego bezpieczeństwa fizycznego.

Dana organizacja może jednak wdrożyć kontroler RODC ze względu na specjalne wymagania administracyjne. Na przykład używana aplikacja LOB może wymagać instalacji na kontrolerze domeny do prawidłowego działania, bądź też kontroler domeny może być jedynym serwerem w danym oddziale firmy i konieczne może być używanie go jako hosta dla aplikacji.

W takich wypadkach właściciel aplikacji LOB musi często logować się interaktywnie na kontrolerze domeny lub używać usług Terminal Services do konfiguracji aplikacji i zarządzania nią. Ta sytuacja tworzy zagrożenie dla bezpieczeństwa, które może być niedopuszczalne na zapisywalnym kontrolerze domeny.

RODC umożliwia bezpieczniejsze wdrożenie kontrolera domeny w takim scenariuszu. Można przydzielić użytkownikowi domeny nie będącemu administratorem uprawnienia do zalogowania się na kontrolerze RODC, minimalizując jednocześnie zagrożenie dla drzewa Active Directory.

Można również wdrożyć RODC w innych scenariuszach, gdzie najbardziej zagrożony jest lokalny magazyn wszystkich haseł użytkowników domeny, na przykład w roli ekstranetowej lub obsługującej aplikacje.

RODC zaprojektowano głównie dla środowisk zdalnych lub oddziałów firmy. Mają one zazwyczaj następujące cechy:

• Stosunkowo niewielu użytkowników
• Słabe bezpieczeństwo fizyczne
• Stosunkowo słaba przepustowość łącza podczas połączenia z witryną centralną
• Niewielkie doświadczenie użytkowników w dziedzinie IT

Ta sekcja i dodatkowa dokumentacja dotycząca RODC przeznaczona jest przede wszystkim dla użytkowników należących do następujących grup:

• Planistów i analityków IT odpowiedzialnych za ocenę techniczną produktu
• Firmowych planistów i projektantów IT
• Osób odpowiedzialnych za bezpieczeństwo IT
• Administratorów AD DS odpowiedzialnych za oddziały firmy

Aby wdrożyć RODC, przynajmniej jeden zapisywalny kontroler domeny w domenie musi używać systemu operacyjnego Windows Server 2008. Oprócz tego poziom funkcjonalny domeny i drzewa musi być zgodny z Windows Server 2003 lub wyższy.

 Do początku strony

Nowa funkcjonalność RODC

Użycie kontrolera RODC zapobiega niektórym problemom często występujących w oddziałach firmy. Lokalizacje te mogą nie posiadać kontrolera domeny. Mogą też mieć zapisywalny kontroler domeny, ale nie mieć odpowiednich zabezpieczeń fizycznych, przepustowości sieci lub lokalnych ekspertów do jego utrzymania.
Następujące funkcje RODC są odpowiedzią na te problemy:

• Bazy danych AD DS tylko do odczytu
• Jednokierunkowa replikacja
• Buforowanie poświadczeń
• Rozdzielenie ról administratora
• Domain Name System (DNS) tylko do odczytu

Nie licząc haseł do kont, RODC zawiera wszystkie obiekty i atrybuty Active Directory, które zawiera zapisywalny kontroler domeny. Nie można jednak dokonywać zmian w bazie danych przechowywanej na RODC. Zmian należy dokonać na zapisywalnym kontrolerze domeny, a następnie mogą one zostać zreplikowane na RODC.

Lokalne aplikacje, żądające dostępu do odczytu katalogu, mogą go uzyskać. Aplikacje Lightweight Directory Application Protocol (LDAP) żądające dostępu do zapisu otrzymają odpowiedź z poleceniem LDAP. Ta odpowiedź przekieruje je do zapisywalnego kontrolera domeny, znajdującego się zazwyczaj w witrynie centralnej.

Filtrowany zestaw atrybutów RODC

Niektóre aplikacje używające AD DS do przechowywania danych mogą potrzebować danych takich jak hasła, poświadczenia i klucze szyfrowania, które często nie powinny być przechowywane na kontrolerze RODC ze względu na ryzyko naruszenia jego zabezpieczeń.

Dla tego rodzaju aplikacji można dynamicznie skonfigurować zestaw atrybutów w schemacie obiektów domeny, które nie będą replikowane na RODC. Taki zestaw atrybutów zwany jest filtrowanym zestawem atrybutów RODC. Atrybuty definiowane w filtrowanym zestawie atrybutów RODC nie mogą być replikowane na żadnym kontrolerze RODC w drzewie.

Złośliwy użytkownik, który naruszył bezpieczeństwo RODC, może próbować skonfigurować go tak, aby próbował replikować atrybuty zdefiniowane w filtrowanym zestawie atrybutów RODC. Jeśli RODC spróbuje replikować te atrybuty z kontrolera domeny z systemem Windows Server 2008, żądanie replikacji nie zostanie spełnione. Jeśli jednak RODC spróbuje replikować te atrybuty z kontrolera domeny z systemem Windows Server 2003, żądanie replikacji zostanie spełnione.

Dlatego też przed konfiguracją filtrowanego zestawu atrybutów RODC należy upewnić się, że funkcjonalny poziom drzewa to Windows Server 2008. Jeśli poziom funkcjonalny drzewa to Windows Server 2008, w przypadku naruszenia zabezpieczeń RODC nie można wykorzystać go w ten sposób, ponieważ w drzewie nie ma kontrolerów domeny z systemem Windows Server 2003.

Do filtrowanego zestawu atrybutów RODC nie można dodać atrybutów krytycznych dla systemu. Atrybut jest krytyczny dla systemu, jeśli jest wymagany do odpowiedniego działania AD DS, Local Security Authority (LSA), Security Accounts Manager (SAM) lub interfejsów Security Service Provider Interfaces (SSPI) firmy Microsoft, takich jak Kerberos. Atrybut krytyczny dla systemu ma wartość atrybutu schemaFlagsEx równą 1 (wartość atrybutu schemaFlagsEx & 0x1 = TRUE).

Filtrowany zestaw atrybutów RODC konfigurowany jest na serwerze pełniącym rolę głównego wzorca schematu. Gdy użytkownik spróbuje dodać atrybut krytyczny dla systemu do RODC, jeśli serwer będący wzorcem schematu używa systemu Windows Server 2008, serwer zwraca błąd LDAP „unwillingToPerform”. W przypadku próby dodania krytycznego dla systemu atrybutu do filtrowanego zestawu atrybutów RODC na wzorcu schematu z systemem Windows Server 2003 operacja pozornie zakończona zostanie pomyślnie, ale atrybut nie zostanie w rzeczywistości dodany. Zalecane jest więc, aby przy dodawaniu atrybutów do filtrowanego zestawu RODC serwer będący wzorcem schematu był kontrolerem domeny z systemem Windows Server 2008. Daje to pewność, że krytyczne dla systemu atrybuty nie zostaną dodane do filtrowanego zestawu atrybutów RODC.

Jednokierunkowa replikacja

Ponieważ żadne zmiany nie są zapisywane bezpośrednio na RODC, nie ma żadnych zmian wychodzących z RODC. Dlatego też kontrolery domeny będące partnerami replikacji nie muszą pobierać zmian z RODC. Oznacza to, że zmiany i uszkodzenia wywołane w wypadku naruszenia zabezpieczeń w zdalnej lokalizacji nie będą replikowane z kontrolera RODC do reszty drzewa. Zmniejsza to również obciążenie robocze serwerów czołowych w lokalizacji centralnej i ogranicza potrzebę monitorowania replikacji.

Replikacja jednokierunkowa RODC stosowana jest zarówno do replikacji AD DS, jak i Distributed File System (DFS). RODC wykonuje normalną, przychodzącą replikację dla zmian w AD DS i DFS.

Buforowanie poświadczeń

Buforowanie poświadczeń to przechowywanie poświadczeń komputera lub użytkownika. Poświadczenia składają się z małego zestawu około 10 haseł skojarzonych z zabezpieczeniami głównymi. Domyślnie RODC nie przechowuje poświadczeń komputera ani użytkownika. Wyjątkami są konto komputera RODC i specjalne konto krbtgt, które ma każdy kontroler RODC. Aby możliwe było buforowanie wszelkich innych poświadczeń, trzeba na to wyraźnie zezwolić.

RODC stanowi centrum dystrybucji kluczy (KDC) dla oddziału firmy. RODC używa innego konta i hasła krbtgt niż KDC na zapisywalnym kontrolerze domeny, kiedy podpisuje lub szyfruje żądania biletu TGT.

Po pomyślnym uwierzytelnieniu konta, RODC próbuje skontaktować się z zapisywalnym kontrolerem domeny w lokalizacji centralnej i żąda kopii odpowiednich poświadczeń. Zapisywalny kontroler domeny rozpoznaje, że żądanie przychodzi od kontrolera RODC i konsultuje się z odpowiednią dla niego zasadą Password Replication Policy.

Zasada Password Replication Policy określa, czy poświadczenia użytkownika lub komputera można zreplikować z zapisywalnego kontrolera domeny na kontroler RODC. Jeśli zasada na to pozwala, zapisywalny kontroler domeny replikuje poświadczenia na RODC, a RODC je buforuje.

Po zbuforowaniu poświadczeń na RODC, może on bezpośrednio obsługiwać żądania logowania danego użytkownika aż do zmiany poświadczeń (kiedy bilet TGT podpisywany jest przy użyciu konta krbtgt RODC, RODC rozpoznaje, że ma zbuforowaną kopię poświadczeń; jeśli inny kontroler domeny podpisuje bilet TGT, kontroler RODC przekazuje żądania do zapisywalnego kontrolera domeny).

Ograniczenie buforowania poświadczeń jedynie do użytkowników uwierzytelnionych na kontrolerze RODC sprawia, że ograniczony jest też potencjał nieautoryzowanego dostępu do poświadczeń poprzez naruszenie zabezpieczeń RODC. Zazwyczaj jedynie mała część użytkowników domeny ma poświadczenia zbuforowane na danym RODC. Dlatego też w przypadku kradzieży RODC, jedynie zbuforowane poświadczenia mogą potencjalnie zostać wykorzystane.

Pozostawienie wyłączonego buforowania poświadczeń może jeszcze bardziej ograniczyć ryzyko, ale skutkuje to przekierowaniem wszystkich żądań uwierzytelnienia do zapisywalnego kontrolera domeny. Administrator może zmodyfikować domyślną zasadę Password Replication Policy tak, aby pozwolić na buforowanie poświadczeń użytkowników na RODC.

Rozdzielenie ról administratora

Możliwe jest delegowanie lokalnych zezwoleń administracyjnych kontrolera RODC do każdego użytkownika domeny bez udzielania mu jakichkolwiek praw dotyczących domeny lub innych kontrolerów domeny. Pozwala to lokalnemu użytkownikowi zalogować się na kontrolerze RODC i wykonać prace serwisowe na serwerze, takie jak aktualizacja sterowników. Nie może on jednak zalogować się na żadnym innym kontrolerze domeny ani wykonywać żadnych zadań administracyjnych w domenie. W ten sposób lokalny użytkownik może otrzymać możliwość efektywnego zarządzania kontrolerem RODC w oddziale firmy bez narażania bezpieczeństwa reszty domeny.

DNS tylko do odczytu

Możliwa jest instalacja na kontrolerze RODC usługi DNS Server. RODC jest zdolny do replikacji wszystkich partycji katalogu aplikacji używanych przez DNS, w tym ForestDNSZones i DomainDNSZones. Jeśli na kontrolerze RODC zainstalowany jest serwer DNS, klienci mogą wysyłać do niego zapytania o rozwiązanie konfliktu nazw w taki sam sposób, jak w przypadku każdego serwera DNS.

Serwer DNS na kontrolerze RODC nie obsługuje jednak bezpośrednio aktualizacji klientów. W efekcie RODC nie rejestruje rekordów zasobów nazwy serwera (NS) żadnych stref zintegrowanych z Active Directory, dla których jest hostem. Kiedy klient podejmuje próbę aktualizacji swoich rekordów DNS na RODC, serwer zwraca odwołanie. Klient może następnie spróbować dokonać aktualizacji na serwerze DNS podanym w odwołaniu. W tle serwer DNS na RODC podejmuje próbę replikacji zaktualizowanego rekordu z serwera DNS, który dokonał aktualizacji. To żądanie replikacji dotyczy jedynie pojedynczego obiektu (rekordu DNS). Cała lista zmienionych danych strefy lub domeny nie jest replikowana podczas tego specjalnego żądania replikacji pojedynczego obiektu.

Jakie ustawienia dodano lub zmieniono?

Windows Server 2008 AD DS udostępnia nowe atrybuty, ułatwiające korzystanie z zasady Password Replication Policy kontrolera RODC. Zasada Password Replication Policy to mechanizm określania, czy poświadczenia użytkownika lub komputera mogą być replikowane z zapisywalnego kontrolera domeny na kontrolerze RODC. Zasada ta zawsze ustawiona jest na zapisywalnym kontrolerze domeny z systemem Windows Server 2008.

Wśród atrybutów AD DS dodanych w schemacie Windows Server 2008 Active Directory w celu obsługi RODC są:

• msDS-Reveal-OnDemandGroup
• msDS-NeverRevealGroup
• msDS-RevealedList
• msDS-AuthenticatedToAccountList

Więcej informacji o tych atrybutach można znaleźć w przewodniku Step-by-Step Guide for Planning, Deploying, and Using a Windows Server 2008 Read-Only Domain Controller (j.ang.) (https://go.microsoft.com/fwlink/?LinkId=87001).

Choć zatrzymywanie AD DS jest podobne do logowania się w trybie Directory Services Restore Mode, restartowalne usługi AD DS udostępniają unikatowy stan kontrolera domeny z systemem Windows Server 2008. Stan ten nazywa się AD DS Stopped.

Trzy podstawowe stany kontrolera domeny z systemem Windows Server 2008 to:

• AD DS Started. W tym stanie usługi AD DS są uruchomione. Dla klientów i innych usług działających na serwerze kontroler domeny Windows Server 2008 nie różni się od kontrolera domeny z systemem Windows 2000 Server lub Windows Server 2003.

• AD DS Stopped. W tym stanie usługi AD DS są zatrzymane. Choć ten tryb jest unikatowy, serwer ma pewne cechy zarówno kontrolera domeny w Directory Services Restore Mode, jak i serwera połączonego z domeną.

  Podobnie jak w przypadku Directory Services Restore Mode (DSRM), baza danych Active Directory database (Ntds.dit) na lokalnym kontrolerze domeny pozostaje w trybie offline. Możliwe jest skontaktowanie się z innym kontrolerem domeny w celu zalogowania się, jeśli jakiś jest dostępny. Jeśli nie można się skontaktować z żadnym innym kontrolerem domeny, można użyć hasła DSRM w celu zalogowania się na lokalnym kontrolerze domeny w DSRM.

  Jak w przypadku serwera należącego do domeny, serwer połączony jest z domeną. Oznacza to, że Group Policy i inne ustawienia wciąż stosowane są do komputera. Jednakże kontroler domeny nie powinien znajdować się w tym stanie przez dłuższy czas, jako że nie może on wtedy obsługiwać żądań logowania ani replikować danych z innych kontrolerów domeny.

• Directory Services Restore Mode. Ten tryb (lub stan) nie zmienił się w stosunku do Windows Server 2003.

Poniższy schemat ukazuje, jak kontroler domeny z systemem Windows Server 2008 może przechodzić między tymi trzema stanami.

Rys. 1

 Do początku strony

Wymagania dla wdrożenia RODC:

• RODC musi przekierowywać żądania uwierzytelnienia do zapisywalnego kontrolera domeny z systemem operacyjnym Windows Server 2008. Zasada Password Replication Policy na kontrolerze domeny określa, czy w przypadku przekierowanego żądania z RODC poświadczenia będą replikowane w zdalnej lokacji.
• Funkcjonalność domeny musi być na poziomie Windows Server 2003 lub wyższym, aby dostępne były ograniczone żądania delegowania protokołu Kerberos. Delegowania ograniczonego używa się jedynie dla połączeń bezpieczeństwa wymagających personifikacji w kontekście wywołania.
• Funkcjonalność drzewa musi być na poziomie Windows Server 2003 lub wyższym, aby dostępna była replikacja wartości połączonych. Daje to wyższy poziom spójności replikacji.
• Należy jednorazowo uruchomić polecenie adprep /rodcprep w lesie, aby zaktualizować zezwolenia na wszystkich partycjach katalogu aplikacji DNS w lesie. W ten sposób wszystkie kontrolery RODC będące również serwerami DNS będą mogły pomyślnie replikować zezwolenia.

AD DS: Restartowalne usługi AD DS

Administratorzy mogą zatrzymać i restartować usługi Active Directory® Domain Services (AD DS) w systemie Windows Server® 2008 przy użyciu przystawek Microsoft Management Console (MMC) lub wiersza polecenia.

Restartowalne usługi AD DS zmniejszają czas potrzebny na wykonanie określonych operacji. AD DS można zatrzymać, aby aktualizacje mogły zostać zastosowane na kontrolerze domeny; administratorzy mogą również zatrzymać AD w celu wykonania takich zadań, jak defragmentacja bazy danych Active Directory w trybie offline, bez konieczności restartowania kontrolera domeny. Inne usługi działające na serwerze nie wymagające AD DS do działania, takie jak Dynamic Host Configuration Protocol (DHCP), pozostają dostępne i spełniają żądania klientów, podczas gdy AD DS jest zatrzymane.

Restartowalne usługi AD DS są dostępne domyślnie na wszystkich kontrolerach domeny z systemem Windows Server 2008. Nie ma żadnych wymagań na poziomie funkcjonalnym ani innych warunków potrzebnych do używania tej funkcji.

W Active Directory w systemach operacyjnych Microsoft® Windows® 2000 Server i Windows Server® 2003 defragmentacja bazy danych w trybie offline wymagała restartowania kontrolera domeny w trybie Directory Services Restore Mode. Instalacja aktualizacji zabezpieczeń również często wymagała restartu kontrolera domeny.

W Windows Server 2008 administratorzy mogą zatrzymać i ponownie uruchomić AD DS. Pozwala to na szybsze wykonywanie operacji offline w AD DS.

Restartowalne usługi AD DS wiążą się z niewielkimi zmianami w istniejących przystawkach MMC. Kontroler domeny z Windows Server 2008 AD DS wyświetla pozycję Domain controller w węźle Services (Local) przystawek Component Services i Computer Management. Przy użyciu każdej z tych przystawek administrator może w prosty sposób zatrzymać i ponownie uruchomić AD DS w taki sam sposób, co każdą inną usługę działającą lokalnie na serwerze.

Do początku strony

---