Kontroler domeny tylko do odczytu (RODC) – jak działa, kiedy go użyć i jak wdrożyć

Kontroler domeny tylko do odczytu (RODC, Read-Only Domain Controller) to kontroler domeny Active Directory, który ma pełną kopię katalogu, ale nie pozwala niczego w niej zmienić i domyślnie nie przechowuje haseł użytkowników. Stawia się go tam, gdzie potrzebne jest lokalne logowanie i szybki dostęp do AD, ale nie da się zagwarantować fizycznego bezpieczeństwa serwera – najczęściej w oddziałach firmy.

Funkcja pojawiła się w Windows Server 2008 i jest dostępna we wszystkich kolejnych wersjach, łącznie z Windows Server 2025. Poniżej wyjaśniam, jak RODC działa, jak skonfigurować buforowanie haseł, jak go zainstalować i co sprawdzić, gdy klienci w oddziale nie mogą skontaktować się z kontrolerem domeny.

Jak działa kontroler domeny tylko do odczytu

Zwykły (zapisywalny) kontroler domeny przyjmuje zmiany i replikuje je do pozostałych kontrolerów w obie strony. RODC różni się w kilku istotnych miejscach:

• Replikacja jednokierunkowa. RODC tylko pobiera zmiany z zapisywalnego kontrolera domeny. Nawet jeśli ktoś zmodyfikuje bazę na RODC (np. po fizycznym przejęciu dysku), zmiana nie rozejdzie się po domenie.
• Brak haseł w bazie. Domyślnie RODC nie ma skrótów haseł użytkowników ani komputerów – poza własnym kontem komputera i własnym kontem krbtgt. Hasła trafiają do niego tylko dla kont dopuszczonych w zasadach replikacji haseł.
• Własne konto krbtgt. Każdy RODC ma osobne konto krbtgt_XXXXX i podpisuje bilety Kerberos własnym kluczem. Przejęcie RODC nie daje więc możliwości fałszowania biletów dla całej domeny. Szczegóły mechanizmu opisujemy w artykule o Kerberos.
• Przekazywanie żądań zapisu. Gdy klient chce coś zapisać (np. zmienić hasło), RODC odsyła go do zapisywalnego kontrolera domeny albo przekazuje operację dalej.
• DNS tylko do odczytu. Jeśli na RODC zainstalujesz DNS, strefy zintegrowane z AD są na nim tylko do odczytu, a dynamiczne rejestracje klientów trafiają na zapisywalny serwer DNS.
• Filtrowany zestaw atrybutów (FAS). Możesz oznaczyć wybrane atrybuty (np. przechowywane przez aplikacje dane poufne) tak, by w ogóle nie replikowały się na RODC.

Co się dzieje przy logowaniu w oddziale

Użytkownik loguje się na komputerze w oddziale, a jego żądanie trafia do lokalnego RODC. Jeśli hasło tego użytkownika jest zbuforowane, RODC uwierzytelnia go lokalnie. Jeśli nie – przekazuje żądanie do zapisywalnego kontrolera domeny w centrali, a po udanym logowaniu (gdy zasady na to pozwalają) pobiera i zapisuje hasło. Kolejne logowanie odbędzie się już lokalnie, także przy awarii łącza WAN.

Ogólne zasady działania katalogu, lasów i replikacji znajdziesz w tekstach jak działa Active Directory i czym jest AD DS.

Kiedy warto wdrożyć RODC, a kiedy nie

RODC rozwiązuje konkretny problem: lokalny kontroler domeny w miejscu, któremu nie ufasz w pełni. Typowe scenariusze:

• oddział lub sklep bez zamykanej serwerowni, gdzie serwer stoi w szafce na zapleczu,
• lokalizacja z wolnym lub zawodnym łączem do centrali, w której ludzie muszą logować się także przy jego awarii,
• strefa DMZ lub sieć przemysłowa, gdzie aplikacje potrzebują odczytu z AD, ale nie powinny mieć dostępu do pełnej bazy,
• oddział z lokalnym informatykiem, który ma administrować serwerem, ale nie powinien być administratorem domeny.

Z drugiej strony RODC to dodatkowy serwer do aktualizowania i monitorowania. Jeśli łącze z oddziałem jest stabilne, a liczba użytkowników niewielka, często prościej jest uwierzytelniać ich przez VPN lub SD-WAN w centrali. Coraz więcej firm przenosi też tożsamość do Microsoft Entra ID, gdzie lokalny kontroler w oddziale przestaje być potrzebny.

Zasady replikacji haseł (PRP) i grupy bezpieczeństwa

Najważniejszą decyzją przy wdrażaniu RODC jest to, czyje hasła mogą być na nim przechowywane. Steruje tym Password Replication Policy, czyli lista kont i grup dozwolonych oraz zabronionych. Zabronienie zawsze wygrywa z zezwoleniem.

W domenie są dwie wbudowane grupy, które obowiązują wszystkie RODC:

• Allowed RODC Password Replication Group – domyślnie pusta. Członkowie mogą mieć hasła buforowane na każdym RODC.
• Denied RODC Password Replication Group – domyślnie zawiera m.in. Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Domain Controllers, Read-only Domain Controllers i konto krbtgt.

Dodatkowo każdy RODC ma domyślnie na liście zabronionych grupy Administrators, Server Operators, Backup Operators i Account Operators. Dzięki temu hasła kont uprzywilejowanych nigdy nie trafiają do oddziału – to ważny element ochrony kont administracyjnych, o której piszemy szerzej przy okazji Privileged Access Management.

Dobra praktyka: osobna grupa na każdy oddział

Nie dodawaj użytkowników do wbudowanej grupy Allowed, bo wtedy ich hasła mogą trafić na każdy RODC w domenie. Lepiej utworzyć grupę na oddział, np. RODC-Krakow-Allowed, i dodać do niej użytkowników oraz komputery z tej lokalizacji. Pamiętaj o komputerach – bez zbuforowanego hasła konta komputera stacja nie uwierzytelni się w domenie przy awarii łącza.

Konfiguracja w PowerShell:

# Dodanie grupy oddziału do listy dozwolonych na konkretnym RODC
Add-ADDomainControllerPasswordReplicationPolicy -Identity RODC-KRK01 -AllowedList "RODC-Krakow-Allowed"

# Podgląd list dozwolonych i zabronionych
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC-KRK01 -Allowed
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC-KRK01 -Denied

# Które konta mają hasło zbuforowane na RODC, a które się przez niego uwierzytelniały
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC-KRK01 -RevealedAccounts
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC-KRK01 -AuthenticatedAccounts

To samo zrobisz graficznie: konsola Użytkownicy i komputery usługi Active Directory → jednostka Domain Controllers → właściwości RODC → karta Zasady replikacji haseł (Password Replication Policy). Przycisk Zaawansowane pokazuje konta zbuforowane i pozwala wstępnie wypełnić hasła (prepopulate) przed uruchomieniem oddziału, żeby ludzie mogli się zalogować nawet przy pierwszym logowaniu bez łącza.

Instalacja RODC krok po kroku

Wymagania wstępne są dziś proste: w tej samej domenie musi działać zapisywalny kontroler domeny z obsługiwaną wersją Windows Server, z którym RODC ma łączność (DNS, LDAP, Kerberos, RPC). Zalecane jest użycie wersji Server Core – mniej usług to mniejsza powierzchnia ataku. Przed instalacją utwórz w AD lokację (site) i podsieć dla oddziału.

Instalacja w PowerShell

1. Zainstaluj rolę AD DS na serwerze w oddziale:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

2. Promuj serwer do roli RODC, wskazując lokację, delegowanego administratora i grupę dozwoloną w PRP:

Install-ADDSDomainController `
  -DomainName "corp.example.pl" `
  -ReadOnlyReplica `
  -SiteName "Krakow" `
  -InstallDns `
  -DelegatedAdministratorAccountName "CORP\RODC-Krakow-Admins" `
  -AllowPasswordReplicationAccountName "CORP\RODC-Krakow-Allowed" `
  -Credential (Get-Credential CORP\administrator)

3. Podaj hasło trybu przywracania usług katalogowych (DSRM), poczekaj na zakończenie replikacji i restart serwera.

W Menedżerze serwera ten sam efekt uzyskasz kreatorem Podnieś ten serwer do roli kontrolera domeny → Dodaj kontroler domeny do istniejącej domeny i zaznaczeniem opcji Kontroler domeny tylko do odczytu (RODC).

Instalacja etapowa (staged)

Gdy serwer w oddziale ma przygotować lokalny technik bez uprawnień administratora domeny, administrator w centrali najpierw tworzy konto RODC:

Add-ADDSReadOnlyDomainControllerAccount -DomainControllerAccountName "RODC-KRK01" `
  -DomainName "corp.example.pl" -SiteName "Krakow" `
  -DelegatedAdministratorAccountName "CORP\RODC-Krakow-Admins"

Następnie osoba z delegowanej grupy instaluje rolę na serwerze o tej samej nazwie i podłącza go do przygotowanego konta poleceniem Install-ADDSDomainController z parametrem -UseExistingAccount.

Wskazówka: Delegowany administrator RODC ma pełne prawa administracyjne do samego serwera (aktualizacje, sterowniki, restart), ale nie ma żadnych uprawnień w domenie. To jedna z największych zalet RODC w oddziałach z lokalnym IT.

Co RODC robi, a czego nie zrobi bez centrali

To najczęstsze źródło rozczarowań po wdrożeniu. RODC poradzi sobie lokalnie z:

• logowaniem użytkowników i komputerów, których hasła są zbuforowane,
• odpowiadaniem na zapytania LDAP, przetwarzaniem zasad grupy (GPO) i skryptów logowania z SYSVOL,
• rozwiązywaniem nazw w DNS dla stref zintegrowanych z AD.

Natomiast do zapisywalnego kontrolera domeny trafią zawsze:

• zmiana i reset hasła,
• dołączanie komputera do domeny (standardowo; dołączenie przez RODC jest możliwe tylko przy wcześniej przygotowanym koncie komputera) – więcej w poradniku o dołączaniu komputera do domeny,
• tworzenie i modyfikacja obiektów, zmiany członkostwa w grupach,
• logowanie kont, których hasła nie są (lub nie mogą być) zbuforowane.

Jeśli w oddziale działa aplikacja, która zapisuje coś do AD, sprawdź, czy poprawnie obsługuje odesłanie do zapisywalnego DC. Starsze aplikacje bywają z tym problematyczne.

„Nie można skontaktować się z kontrolerem domeny” w oddziale z RODC

Komunikaty „Nie można skontaktować się z kontrolerem domeny usługi Active Directory” albo „Nie można odczytać informacji o konfiguracji z kontrolera domeny” oznaczają, że komputer lub konsola administracyjna nie znalazła działającego kontrolera domeny albo nie mogła się z nim połączyć. W środowisku z RODC sprawdź po kolei:

1. Czy klienci w oddziale mają w DNS ustawiony lokalny RODC (lub inny serwer DNS domeny), a nie DNS operatora czy routera.
2. Czy RODC widzi zapisywalny kontroler domeny i czy replikacja działa.
3. Czy podsieć oddziału jest przypisana do właściwej lokacji AD – inaczej klienci szukają kontrolerów w złym miejscu.
4. Czy operacja, którą wykonujesz (np. dołączenie do domeny, otwarcie konsoli do edycji), nie wymaga zapisywalnego DC, który jest akurat nieosiągalny.

Przydatne polecenia diagnostyczne:

# Który kontroler obsługuje klienta i czy jest dostępny zapisywalny DC
nltest /dsgetdc:corp.example.pl
nltest /dsgetdc:corp.example.pl /writable

# Stan replikacji i testy kontrolera
repadmin /replsummary
repadmin /showrepl RODC-KRK01
dcdiag /s:RODC-KRK01 /v

# Czy rekordy SRV kontrolerów są w DNS
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example.pl

Pełną listę przyczyn tego błędu (DNS, zapora, czas, kanał zabezpieczeń) opisaliśmy w osobnym poradniku: Nie można skontaktować się z kontrolerem domeny Active Directory.

Co zrobić po kradzieży lub przejęciu RODC

Ponieważ RODC przechowuje tylko część haseł, reakcja na incydent jest stosunkowo prosta:

1. Otwórz konsolę Użytkownicy i komputery usługi Active Directory i przejdź do jednostki Domain Controllers.
2. Usuń konto komputera skradzionego RODC.
3. W oknie, które się pojawi, zaznacz opcje zresetowania haseł wszystkich kont użytkowników i komputerów zbuforowanych na tym RODC oraz eksportu ich listy do pliku.
4. Poinformuj użytkowników z listy o konieczności ustawienia nowych haseł, a komputery ponownie dołącz do domeny.

Uwaga: Reset haseł kont komputerów zerwie im relację zaufania z domeną. Zaplanuj ponowne dołączenie stacji z oddziału, zanim użytkownicy przyjdą do pracy.

Właśnie dlatego tak ważne jest trzymanie listy dozwolonych kont jak najkrócej: im mniej haseł na RODC, tym mniejsze skutki jego utraty i tym mniej pracy po incydencie.