„Nie można skontaktować się z kontrolerem domeny Active Directory” – przyczyny i naprawa

Komunikat „Nie można skontaktować się z kontrolerem domeny usługi Active Directory (AD DC) dla domeny…” niemal zawsze oznacza problem z DNS: komputer pyta niewłaściwy serwer DNS i nie znajduje rekordu, który wskazuje kontroler domeny. Najszybsza naprawa to ustawienie na komputerze jako serwera DNS adresu IP kontrolera domeny (a nie routera czy 8.8.8.8), wyczyszczenie pamięci DNS i ponowna próba dołączenia.

Jeśli to nie pomoże, sprawdzasz po kolei: rekordy SRV w DNS, łączność i porty między komputerem a kontrolerem, stan samego kontrolera (usługi, rejestracja w DNS) oraz synchronizację czasu. Poniżej każdy z tych kroków z konkretnymi poleceniami.

Co dokładnie mówi ten błąd i gdzie szukać szczegółów

Pełna wersja komunikatu pojawia się najczęściej podczas dołączania komputera do domeny (Ustawienia → Konto → Dostęp do konta szkoły lub pracy albo sysdm.cpl → Zmień). Po kliknięciu Szczegóły Windows pokazuje, co się stało przy zapytaniu DNS, np.:

• „Nazwa DNS nie istnieje” (kod 0x0000232B RCODE_NAME_ERROR) — serwer DNS, którego używa komputer, nie zna Twojej domeny. Prawie zawsze zły DNS na kliencie.
• „Upłynął limit czasu” (kod 0x000005B4 ERROR_TIMEOUT) — ustawiony serwer DNS nie odpowiada: jest wyłączony, nieosiągalny albo blokuje go zapora.
• „Awaria serwera DNS” (kod 0x0000232A RCODE_SERVER_FAILURE) — serwer DNS odpowiedział błędem; problem leży po stronie DNS na kontrolerze domeny.

W szczegółach znajdziesz też nazwę rekordu, o który pytał komputer, np. _ldap._tcp.dc._msdcs.firma.local. To klucz do całego problemu: klient nie „szuka” kontrolera domeny w sieci, tylko pyta DNS o rekord SRV, a DNS odpowiada listą kontrolerów. Jeśli chcesz lepiej zrozumieć ten mechanizm, zajrzyj do tekstów jak działa serwer DNS oraz czym jest AD DS.

Szczegółowy przebieg próby dołączenia zapisuje się w pliku C:\Windows\debug\NetSetup.log — warto do niego zajrzeć, gdy komunikat na ekranie jest zbyt ogólny.

Krok 1: ustaw poprawny serwer DNS na komputerze

To najczęstsza przyczyna, szczególnie w małych firmach, gdzie DHCP działa na routerze i rozdaje jako DNS adres routera lub operatora.

Sprawdź aktualne ustawienia:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4

W polu „Serwery DNS” mają być wyłącznie adresy kontrolerów domeny z rolą DNS. Jeśli widzisz adres routera (np. 192.168.1.1) albo publiczny DNS, zmień to:

1. Windows 11: Ustawienia → Sieć i Internet → Ethernet (lub Wi-Fi → Właściwości sprzętu) → Przypisanie serwera DNS → Edytuj → Ręcznie → włącz IPv4 i wpisz adres DC.
2. Alternatywnie: Win + R → ncpa.cpl → prawy klik na kartę → Właściwości → Protokół internetowy w wersji 4 (TCP/IPv4) → Użyj następujących adresów serwerów DNS.
3. Albo w PowerShell uruchomionym jako administrator:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.10.10,192.168.10.11
ipconfig /flushdns

Nazwę interfejsu sprawdzisz poleceniem Get-NetAdapter. Szerzej o zmianie adresacji pisaliśmy w poradniku jak zmienić IP w Windows.

Wskazówka: Docelowo nie poprawiaj DNS ręcznie na każdym komputerze. Ustaw w serwerze DHCP opcję 006 (DNS Servers) na adresy kontrolerów domeny, a publiczne DNS-y dodaj jako forwardery w konsoli DNS na serwerze. Więcej w tekście o dobrych praktykach konfiguracji DHCP.

Zwróć też uwagę na IPv6. Jeśli router ogłasza własny DNS przez IPv6, Windows może z niego korzystać w pierwszej kolejności. Sprawdź w ipconfig /all, czy nie ma tam adresów DNS IPv6 wskazujących na router, i w razie potrzeby wyłącz ich rozgłaszanie na routerze.

Krok 2: sprawdź rekordy SRV i lokalizowanie kontrolera domeny

Gdy DNS jest ustawiony, sprawdź, czy klient widzi rekord SRV kontrolera domeny. Zamień firma.local na nazwę swojej domeny:

nslookup -type=SRV _ldap._tcp.dc._msdcs.firma.local
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.firma.local
nltest /dsgetdc:firma.local

Prawidłowy wynik to lista kontrolerów domeny z nazwami i portem 389, a nltest zwraca nazwę DC, jego adres i flagi (m.in. DS, KDC, LDAP). Jak interpretować błędy:

• Non-existent domain / DNS name does not exist — pytasz niewłaściwy serwer DNS albo na serwerze brakuje strefy _msdcs,
• rekord istnieje, ale wskazuje stary adres IP lub nieistniejący serwer — zostały śmieci po usuniętym kontrolerze (trzeba wyczyścić metadane i rekordy DNS),
• nslookup działa, a nltest zwraca błąd ERROR_NO_SUCH_DOMAIN — DNS jest w porządku, ale komputer nie może połączyć się z DC (przejdź do kroku 3).

Upewnij się też, że wpisujesz pełną nazwę domeny DNS (np. firma.local lub ad.firma.pl), a nie nazwę NetBIOS (FIRMA). Dołączenie po nazwie NetBIOS wymaga dodatkowo rozwiązywania nazw NetBIOS, które w wielu sieciach jest wyłączone.

Krok 3: łączność i porty między komputerem a kontrolerem domeny

Sam ping niewiele mówi — ICMP bywa zablokowany, a nawet jeśli działa, porty usług AD mogą być zamknięte. Lepiej sprawdzić konkretne porty:

Test-NetConnection dc01.firma.local -Port 389
Test-NetConnection dc01.firma.local -Port 88
Test-NetConnection dc01.firma.local -Port 445
Test-NetConnection dc01.firma.local -Port 135

Porty potrzebne klientowi do dołączenia do domeny i logowania:

Typowe miejsca, w których ruch jest blokowany: zapora między VLAN-ami lub oddziałami, tunel VPN site-to-site bez reguł dla RPC, zapora innej firmy na kontrolerze domeny albo program zabezpieczający na kliencie. Jeśli komputer jest podłączony przez VPN klienta, sprawdź, czy tunel przekazuje ruch do podsieci serwerów i czy DNS jest wtedy przełączany na serwery firmowe.

Krok 4: sprawdź stan kontrolera domeny

Jeśli problem dotyczy wszystkich komputerów, a nie jednego, zaloguj się na kontroler domeny i sprawdź jego kondycję.

dcdiag /test:dns /v
dcdiag /q
Get-Service NTDS, DNS, Netlogon, KDC, W32Time, DFSR | Format-Table Name, Status
net share

Na co patrzeć:

1. Usługi NTDS, DNS, Netlogon i KDC muszą działać. dcdiag /q wypisze tylko błędy.
2. net share powinien pokazać udziały SYSVOL i NETLOGON. Ich brak oznacza zwykle problem z replikacją SYSVOL (DFSR) — DC nie ogłasza się wtedy jako w pełni sprawny.
3. Ustawienia DNS samego kontrolera: jako preferowany DNS inny kontroler domeny lub on sam (jego własny adres IP), jako zapasowy — 127.0.0.1 lub inny DC. Nigdy router ani publiczny DNS.
4. Strefa _msdcs.<domena> w konsoli Menedżer DNS (dnsmgmt.msc) musi zawierać rekordy SRV bieżących kontrolerów.

Jeśli rekordów SRV brakuje, wymuś ich ponowną rejestrację na kontrolerze domeny:

ipconfig /registerdns
nltest /dsregdns
Restart-Service Netlogon

Usługa Netlogon przy starcie rejestruje wszystkie rekordy z pliku %SystemRoot%\System32\config\netlogon.dns. Po kilku minutach powtórz test z kroku 2 na kliencie.

Uwaga: Nie usuwaj „na próbę” stref DNS ani obiektów kontrolerów domeny z Active Directory. Czyszczenie metadanych nieistniejącego DC to osobna procedura — błąd na produkcyjnym kontrolerze może unieruchomić całą domenę.

Krok 5: różnica czasu i Kerberos

Uwierzytelnianie w domenie opiera się na protokole Kerberos, który domyślnie toleruje najwyżej 5 minut różnicy czasu między klientem a kontrolerem domeny. Przy większej rozbieżności dołączanie i logowanie kończą się błędami, czasem mylącymi.

Sprawdź i zsynchronizuj czas:

w32tm /query /status
w32tm /stripchart /computer:dc01.firma.local /samples:3 /dataonly
w32tm /resync

Komputery w domenie synchronizują czas z kontrolerami domeny, a kontroler z rolą emulatora PDC — ze źródłem zewnętrznym. Jeśli emulator PDC ma zły czas, problem dotknie całą domenę.

„Nie można odczytać informacji o konfiguracji z kontrolera domeny”

Ten pokrewny komunikat („…ponieważ komputer jest niedostępny lub odmówiono dostępu”) pojawia się zwykle przy promowaniu nowego serwera na kontroler domeny, dodawaniu go do istniejącej domeny albo w konsolach administracyjnych. Oznacza, że serwer znalazł kontroler domeny, ale nie mógł odczytać partycji konfiguracji katalogu.

Najczęstsze przyczyny i co sprawdzić:

1. DNS nowego serwera — musi wskazywać istniejący kontroler domeny, tak jak w kroku 1.
2. Porty RPC i LDAP — Test-NetConnection na porty 135 i 389 oraz dostępność zakresu dynamicznego RPC.
3. Uprawnienia konta — do dodania kontrolera domeny potrzebne jest konto z grupy Domain Admins (a dla nowej domeny w lesie — Enterprise Admins). Podaj je w formacie FIRMA\administrator lub administrator@firma.local.
4. Stan istniejącego DC — dcdiag i repadmin /replsummary pokażą, czy replikacja działa.
5. Czas — ta sama zasada 5 minut co wyżej.

Podobne błędy domenowe i jak je odróżnić

Relację zaufania naprawisz bez ponownego dołączania do domeny poleceniem z tabeli — uruchom je jako lokalny administrator i podaj konto domenowe z uprawnieniami do resetu konta komputera.

Dołączenie do domeny z PowerShell po naprawie

Gdy testy z kroków 2 i 3 przechodzą, dołącz komputer do domeny. Z interfejsu graficznego albo szybciej z PowerShell uruchomionego jako administrator:

Add-Computer -DomainName firma.local -Credential FIRMA\administrator -Restart

Możesz od razu wskazać jednostkę organizacyjną parametrem -OUPath "OU=Komputery,DC=firma,DC=local". Pamiętaj, że edycje Home systemu Windows nie obsługują dołączania do domeny — potrzebujesz wersji Pro, Education lub Enterprise. Pełną procedurę, także dla starszych systemów i konta z delegowanymi uprawnieniami, opisaliśmy w poradniku dołączenie komputera do domeny.

Co zrobić, jeśli nic nie pomogło

Przejdź listę jeszcze raz, w tej kolejności:

1. Na kliencie DNS = wyłącznie kontrolery domeny, także w IPv6; ipconfig /flushdns.
2. nslookup -type=SRV _ldap._tcp.dc._msdcs.<domena> zwraca poprawne serwery.
3. nltest /dsgetdc:<domena> znajduje kontroler.
4. Test-NetConnection na porty 53, 88, 135, 389, 445 przechodzi.
5. Na DC: dcdiag /q bez błędów, udziały SYSVOL i NETLOGON obecne, rekordy SRV zarejestrowane.
6. Różnica czasu poniżej 5 minut.

Jeśli wszystko wygląda poprawnie, a błąd nadal występuje, przeanalizuj C:\Windows\debug\NetSetup.log na kliencie i dziennik Directory Service oraz DNS Server w Podglądzie zdarzeń na kontrolerze. Tam zwykle widać, na którym etapie połączenie się zatrzymuje.