Gdy komputery firmowe są spięte w domenę Active Directory, awaria kontrolera domeny potrafi zablokować logowanie wszystkim pracownikom jednocześnie — nawet jeśli same stacje robocze są całkowicie sprawne.

Pierwsza godzina

Pracownicy przy próbie zalogowania widzą komunikat o niedostępnym kontrolerze domeny, błędnych danych logowania mimo poprawnego hasła, albo komputer wisi na ekranie logowania znacznie dłużej niż zwykle.

Co sprawdzamy w pierwszej kolejności

Dostępność i stan serwera pełniącego rolę kontrolera domeny.
Połączenie sieciowe między stacjami roboczymi a serwerem.
Logi zdarzeń na serwerze wskazujące przyczynę odmowy logowania.
Czy problem dotyczy wszystkich pracowników, czy tylko części — pomaga to zawęzić przyczynę.

Co robimy

Diagnoza lokalizuje przyczynę na serwerze lub w sieci i przywraca dostęp możliwie szybko, żeby ograniczyć przestój w pracy firmy. W zależności od wyniku wykonywany jest restart usług domenowych, naprawa serwera lub konfiguracja sieciowa.

Ile to trwa

Diagnoza i przywrócenie dostępu to zwykle jedna wizyta realizowana priorytetowo, ze względu na skalę przestoju.

Warunki

Diagnoza komputera stacjonarnego door-to-door kosztuje 200 zł i wlicza się w cenę naprawy. Dojazd na terenie Warszawy i okolic jest bezpłatny, a naprawa objęta jest gwarancją do 12 miesięcy.

Najczęstsze techniczne przyczyny problemów z logowaniem do domeny

W środowiskach opartych na usłudze Active Directory (systemie katalogowym firmy Microsoft zarządzającym tożsamościami i uprawnieniami w sieci) proces logowania jest złożoną procedurą zależną od wielu współpracujących ze sobą komponentów. Niemożność zalogowania się pracownika na stacji roboczej rzadko wynika ze zwykłego błędu w haśle. Najczęściej źródłem usterki są awarie infrastrukturalne na poziomie serwera, sieci lub konfiguracji stacji klienckich.

Podstawowe przyczyny uniemożliwiające uwierzytelnienie w domenie obejmują:

Błędy serwera DNS (Domain Name System, system odpowiedzialny za tłumaczenie nazw domenowych na adresy IP). Usługa Active Directory jest bezpośrednio uzależniona od poprawności wpisów DNS. Stacja robocza, aby uwierzytelnić użytkownika, musi odpytać serwer DNS o rekordy SRV (rekordy usług wskazujące adres kontrolera domeny i porty komunikacyjne). Jeśli serwer DNS nie odpowiada, został błędnie skonfigurowany lub stacja otrzymała z routera publiczne adresy DNS zamiast adresu lokalnego kontrolera, komputer wyświetla komunikat o braku dostępnych kontrolerów domeny.
Rozsynchronizowanie zegara systemowego (NTP, Network Time Protocol, protokół synchronizacji czasu w sieci). Główny protokół uwierzytelniania w domenie, czyli Kerberos (system bezpiecznego uwierzytelniania biletowego), wymaga ścisłej zgodności czasu między stacją roboczą a kontrolerem domeny. Dopuszczalna różnica czasu wynosi standardowo do 5 minut. Jeżeli bateria podtrzymująca zegar czasu rzeczywistego (RTC) na płycie głównej komputera ulegnie wyczerpaniu lub strefa czasowa zostanie przestawiona, stacja robocza nie otrzyma biletu logowania (Ticket Granting Ticket) i odmówi dostępu.
Zerwanie relacji zaufania stacji roboczej z domeną (Secure Channel, bezpieczny kanał kryptograficzny między komputerem a kontrolerem domeny). Każdy komputer włączony do Active Directory posiada własne konto maszynowe z hasłem zmienianym automatycznie co 30 dni. Jeżeli komputer był wyłączony przez dłuższy czas, przywrócono kopię zapasową systemu sprzed zmiany hasła lub wystąpił błąd synchronizacji, relacja zaufania zostaje uszkodzona. Użytkownik widzi wówczas komunikat informujący, że relacja zaufania między tą stacją roboczą a domeną podstawową nie powiodła się.
Zablokowanie portów sieciowych lub awaria urządzeń pośredniczących. Komunikacja między stacją roboczą a kontrolerem wymaga otwarcia określonych portów, w tym portu 88 (protokół Kerberos), 389 i 636 (protokół LDAP służący do odpytywania bazy katalogowej), 445 (protokół SMB do przesyłania plików i zasad grupy) oraz 135 (RPC Endpoint Mapper). Nieprawidłowa konfiguracja zapory sieciowej (firewall) na serwerze, przełączniku zarządzalnym lub komputerze pracownika całkowicie odcina możliwość weryfikacji tożsamości.
Uszkodzenie bazy danych Active Directory (plik ntds.dit przechowujący obiekty domeny, konta użytkowników i hasła). Do uszkodzenia struktury bazy może dojść na skutek nagłego zaniku zasilania serwera, awarii macierzy dyskowej RAID lub braku wolnego miejsca na partycji systemowej kontrolera domeny.
Zablokowanie konta użytkownika w ramach polityki bezpieczeństwa (Account Lockout Policy, reguły blokujące konto po określonej liczbie nieudanych prób logowania). Częstym źródłem problemu są zapisane stare hasła w menedżerze poświadczeń Windows na innym urządzeniu pracownika, na przykład w telefonie odbierającym pocztę firmową, co powoduje cykliczne blokowanie konta w domenie zaraz po zmianie hasła.

Warianty usterki logowania w środowisku firmowym

Objawy problemów z logowaniem do domeny mogą przybierać różne formy w zależności od tego, który element infrastruktury uległ awarii. Prawidłowe rozpoznanie wariantu pozwala szybko określić zakres prac serwisowych:

Całkowity brak możliwości logowania dla wszystkich stacji w biurze. Żaden pracownik nie może zalogować się na swój profil domenowy, a komputery po wpisaniu danych logowania wyświetlają informację o niedostępności serwera uwierzytelniania. Wskazuje to na awarię fizyczną serwera, zatrzymanie kluczowych usług domenowych (Active Directory Domain Services), problem z serwerem DNS lub awarię głównego przełącznika sieciowego (switch).
Działanie wyłącznie w trybie poświadczeń buforowanych (Cached Credentials, mechanizm zapisywania skrótów haseł na dysku lokalnym stacji, pozwalający na logowanie bez kontaktu z kontrolerem domeny). Pracownik loguje się do systemu bez błędu, ale nie ma dostępu do dysków sieciowych, folderów współdzielonych, oprogramowania Comarch Optima, Symfonia czy baz danych InsERT Subiekt GT. System nie pobiera również nowych zasad grupy (GPO).
Błąd logowania dotyczący wyłącznie pracowników zdalnych łączących się przez VPN (Virtual Private Network, wirtualna sieć prywatna tworząca zaszyfrowany tunel do biura). Przyczyną jest zazwyczaj brak przekazywania firmowych serwerów DNS przez konfigurację połączenia VPN, błędny routing podsieci lub wygaśnięcie certyfikatu uwierzytelniającego na koncentratorze VPN.
Izolowany błąd pojedynczego komputera. Inni pracownicy logują się poprawnie, natomiast na jednej stacji roboczej pojawia się komunikat o błędnym haśle lub braku relacji zaufania. Oznacza to problem z konfiguracją karty sieciowej, lokalnym stosem TCP/IP, uszkodzeniem rejestru systemu Windows lub wygaśnięciem hasła konta maszyny w Active Directory.

Błędy popełniane podczas samodzielnych prób naprawy logowania domenowego

Próby samodzielnego przywrócenia dostępu do komputera lub serwera bez specjalistycznej wiedzy o strukturze Active Directory często prowadzą do pogłębienia awarii i wydłużenia przestoju firmy. Do najczęstszych błędów należą:

Wypinanie komputera z domeny do grupy roboczej (Workgroup). Jest to bardzo powszechny błąd. Użytkownik lub lokalny opiekun odłącza stację od domeny, licząc na to, że po ponownym podłączeniu błąd zniknie. Bez znajomości hasła do lokalnego konta administratora komputer staje się całkowicie niedostępny. Dodatkowo profil domenowy użytkownika zostaje odłączony, co może skutkować utratą konfiguracji programów pocztowych, certyfikatów i skrótów do systemów ERP.
Twardy restart serwera pełniącego rolę kontrolera domeny. Wyłączenie serwera przyciskiem zasilania w momencie, gdy baza ntds.dit wykonuje operacje zapisu, prowadzi do uszkodzenia struktury logicznej bazy danych lub transakcyjnych plików dziennika (logów transakcyjnych EDB). W środowiskach z kilkoma kontrolerami domeny nagły restart może wywołać zjawisko USN Rollback, czyli niespójność numerów sekwencyjnych aktualizacji i trwałe zatrzymanie replikacji.
Ręczna zmiana adresów DNS na stacjach roboczych na publiczne adresy internetowe (na przykład serwery dostawcy internetu lub publiczne DNS). Powoduje to, że na komputerze zaczyna działać przeglądanie stron internetowych, ale Active Directory całkowicie przestaje funkcjonować, uniemożliwiając logowanie kolejnym osobom i blokując działanie systemów Comarch, WAPRO czy Płatnik.
Usuwanie obiektów kont komputerów lub użytkowników za pomocą zaawansowanych narzędzi, takich jak ADSI Edit (edytor interfejsu usług katalogowych Active Directory), bez posiadania aktualnej kopii zapasowej stanu systemu (System State Backup). Błędne modyfikacje schematu lub atrybutów mogą trwale uszkodzić drzewo domeny.
Resetowanie haseł kont usługowych (Service Accounts, konta uruchamiające procesy w tle). Zmiana hasła dla konta obsługującego bazę Microsoft SQL Server lub usługi domenowe bez aktualizacji parametrów w menedżerze usług zatrzymuje kluczowe systemy w całym przedsiębiorstwie.

Kiedy brak logowania nie wynika z awarii kontrolera domeny

Nie każdy problem z dostępem do komputera oznacza awarię serwera Active Directory. W praktyce serwisowej spotyka się sytuacje, w których objaw jest identyczny, ale źródło problemu leży w zupełnie innym miejscu:

Uszkodzenie lokalnego profilu użytkownika w systemie Windows. Jeśli plik rejestru NTUSER.DAT na dysku twardym stacji roboczej zostanie uszkodzony (na przykład przez błędy nośnika SSD lub nagłe odcięcie zasilania), system loguje pracownika do profilu tymczasowego lub zatrzymuje się na etapie ładowania pulpitu. Sam kontroler domeny uwierzytelnia użytkownika prawidłowo, lecz system operacyjny stacji nie może załadować środowiska pracy.
Awaria serwera DHCP (Dynamic Host Configuration Protocol, usługa automatycznie przydzielająca adresy IP w sieci lokalnej). Jeśli pula adresów IP na routerze lub serwerze wyczerpie się, stacja robocza przypisuje sobie adres autokonfiguracji z puli APIPA (adres zaczynający się od 169.254.x.x). Komputer traci wówczas fizyczną łączność z podsiecią firmową i kontrolerem domeny.
Infekcja złośliwym oprogramowaniem szyfrującym lub blokującym. Wirusy typu ransomware mogą zablokować usługi sieciowe stacji roboczej lub zmodyfikować plik hosts, uniemożliwiając komunikację z serwerem uwierzytelniającym.
Prace techniczne po stronie dostawcy łączy internetowych (ISP). W firmach korzystających ze struktur hybrydowych (na przykład kontroler domeny zlokalizowany w chmurze Microsoft Azure lub w centrali połączonej tunelem IPSec), brak dostępu do internetu odcina możliwość weryfikacji tożsamości użytkowników nieposiadających lokalnie zbuforowanych poświadczeń.

Metodyka diagnostyki domenowej podczas wizyty serwisanta

Podczas wizyty serwisanta w siedzibie firmy diagnostyka infrastruktury domenowej przebiega według usystematyzowanego schematu technicznego, co pozwala szybko zlokalizować źródło usterki i przywrócić sprawność operacyjną biura:

Weryfikacja fizycznego stanu serwera i macierzy dyskowej. Sprawdzany jest stan kontrolera RAID, integralność woluminów dyskowych oraz dostępność wolnego miejsca na partycji z bazą Active Directory i folderem SYSVOL (folderem przechowującym skrypty logowania i szablony zasad grupy).
Analiza integralności bazy danych ntds.dit za pomocą dedykowanego narzędzia ntdsutil (narzędzia wiersza poleceń do zarządzania bazą danych Active Directory). W razie wykrycia niespójności wykonywana jest naprawa logiczna bazy lub przywrócenie stanu spójności.
Testy diagnostyczne usług domenowych za pomocą narzędzia dcdiag (Domain Controller Diagnostic Tool). Narzędzie to weryfikuje poprawność działania ponad trzydziestu parametrów serwera, w tym łączność sieciową, uprawnienia systemowe, dostępność ról FSMO (Flexible Single Master Operations, ról elastycznych pojedynczego wzorca operacji kontrolujących kluczowe funkcje domeny) oraz poprawność rejestracji rekordów w usłudze DNS.
Sprawdzenie stanu replikacji za pomocą narzędzia repadmin (narzędzia do monitorowania i rozwiązywania problemów z replikacją między kontrolerami domeny). Pozwala to wykryć blokady synchronizacji danych między wieloma serwerami w organizacji.
Analiza dzienników zdarzeń systemowych (Event Viewer). Szczegółowej weryfikacji poddawane są dzienniki Directory Service, DNS Server, System oraz Security, ze szczególnym uwzględnieniem identyfikatorów zdarzeń informujących o błędach uwierzytelniania Kerberos (np. Event ID 4, 7, 11) lub problemach z relacją zaufania (Event ID 3210, 5722).
Weryfikacja kanału bezpiecznej komunikacji stacji roboczej z kontrolerem przy użyciu narzędzia nltest lub poleceń środowiska PowerShell (Test-ComputerSecureChannel). W przypadku zerwania relacji zaufania serwisant wykonuje bezpieczną naprawę kanału bez konieczności wypinania komputera z domeny i bez utraty powiązania z profilem użytkownika.

Najczęściej zadawane pytania dotyczące problemów z logowaniem do domeny

Czy w przypadku awarii kontrolera domeny pracownicy mogą nadal korzystać ze swoich komputerów?

Jeżeli pracownik logował się już wcześniej na danej stacji roboczej, system Windows standardowo umożliwia logowanie przy użyciu poświadczeń buforowanych (Cached Credentials), czyli lokalnie zapamiętanych danych uwierzytelniających. Użytkownik uzyska dostęp do lokalnego pulpitu i zainstalowanych programów, jednak nie będzie miał dostępu do zasobów sieciowych, takich jak dyski wspólne, serwery plików, bazy danych programów księgowych czy drukarki sieciowe. Ponadto nowe konta lub pracownicy logujący się na danym komputerze po raz pierwszy nie będą mogli rozpocząć pracy do momentu usunięcia awarii serwera.

Dlaczego na komputerach działa internet, a logowanie do domeny zgłasza błąd?

Dostęp do internetu wymaga jedynie poprawnej komunikacji z routerem i publicznym serwerem DNS, natomiast logowanie do domeny wymaga bezbłędnej komunikacji z lokalnym serwerem DNS zintegrowanym z Active Directory. Jeżeli stacja robocza pobrała z routera zewnętrzny adres DNS (na przykład od dostawcy łącza), przeglądarka internetowa otworzy strony www, ale system operacyjny nie odnajdzie kontrolera domeny, co spowoduje błąd logowania i brak dostępu do sieci firmowej.

Czy naprawa logowania domenowego wymaga podawania haseł pracowników?

Domyślnie serwisant nie wymaga podawania haseł użytkowników. Wszelkie prace diagnostyczne i naprawcze na kontrolerze domeny oraz stacjach roboczych wykonywane są przy użyciu dedykowanych kont administracyjnych w obecności osoby wyznaczonej przez firmę. W przypadku konieczności resetu hasła konkretnego pracownika, nowe hasło tymczasowe jest generowane i przekazywane bezpośrednio użytkownikowi z wymuszeniem jego zmiany przy pierwszym poprawnym logowaniu.

Jak zabezpieczyć środowisko firmowe przed paraliżem w razie awarii kontrolera domeny?

Podstawowym zabezpieczeniem w środowisku Active Directory jest wdrożenie co najmniej dwóch kontrolerów domeny (kontrolera podstawowego oraz zapasowego kontrolera pomocniczego) z uruchomioną automatyczną replikacją. W razie awarii sprzętowej jednego serwera, drugi natychmiast przejmuje obsługę zapytań logowania i zapytań DNS, co zapobiega przestojowi w pracy biura. Niezbędne jest również regularne wykonywanie automatycznych kopii zapasowych stanu systemu (System State Backup) oraz okresowy przegląd infrastruktury IT.

Co należy zrobić natychmiast po wystąpieniu problemu z logowaniem w biurze?

W pierwszej kolejności nie należy restartować serwera z przycisku zasilania ani wypinać stacji roboczych z domeny do grupy roboczej. Należy ustalić, czy problem dotyczy jednego stanowiska, czy wszystkich pracowników w biurze, oraz sprawdzić, czy kontroler domeny jest włączony i podłączony do sieci lokalnej. Bezpłatna porada telefoniczna pod numerem 22 378 48 09 pozwala wstępnie ocenić charakter usterki i ustalić priorytetowy przyjazd serwisanta do siedziby firmy.

Ciągłość działania infrastruktury Active Directory w firmie

Prawidłowo funkcjonująca domena Active Directory stanowi fundament bezpieczeństwa i sprawnego działania każdego przedsiębiorstwa korzystającego ze środowiska Windows. Wszelkie nieprawidłowości w procesie logowania, komunikacji DNS czy replikacji bazy ntds.dit wymagają bezzwłocznej, metodycznej interwencji, aby uniknąć kosztownych przestojów i ryzyka utraty integralności danych. Dojeżdżamy do klientów na terenie całej Warszawy oraz okolicznych powiatów (w tym powiatu pruszkowskiego, piaseczyńskiego, warszawskiego zachodniego, legionowskiego, wołomińskiego, otwockiego i grodziskiego), zapewniając fachową diagnostykę serwerową, naprawę relacji zaufania oraz pełne wsparcie infrastruktury sieciowej bezpośrednio w siedzibie firmy.

22 378 48 09

Pracownicy nie mogą się zalogować do domeny firmowej