Nowe konto ma działać na komputerze, poczta ma rozpoznawać pracownika, a aplikacja .NET ma sprawdzić jego uprawnienia. W firmie korzystającej z klasycznej domeny Windows zwykle odpowiada za to Active Directory, choć sam katalog nie wystarczy, jeśli komputery nie potrafią odnaleźć kontrolera domeny.
Domena Windows porządkuje tożsamości, ale zależy od poprawnej konfiguracji sieci
- AD DS przechowuje konta, komputery, grupy i ustawienia używane w domenie.
- Microsoft Entra ID i usługi domenowe w Azure obsługują inne scenariusze niż samodzielnie zarządzana domena lokalna.
- DNS pomaga komputerom i aplikacjom znaleźć właściwy kontroler domeny.
- Replikacja i kopie zapasowe wymagają planu, który uwzględnia rolę kontrolerów i sposób odtwarzania.
AD DS łączy konto użytkownika z komputerem i zasobami
Przy logowaniu do komputera domenowego system musi odpowiedzieć na kilka pytań: czy konto istnieje, czy hasło jest poprawne i do jakich zasobów ma dostęp dana osoba. Active Directory Domain Services (AD DS) przechowuje informacje o użytkownikach, komputerach, grupach i innych obiektach sieciowych, a kontrolery domeny udostępniają je urządzeniom oraz aplikacjom.
Administrator porządkuje obiekty w domenie i jednostkach organizacyjnych, czyli kontenerach takich jak „Komputery” lub „Pracownicy”. Do jednostek organizacyjnych można przypisać zasady grupy (GPO), które ustawiają zachowanie komputerów i użytkowników, na przykład konfigurują politykę ekranu blokady. Uprawnienia do folderu sieciowego zwykle przypisuje się grupie, a konta dodaje się do niej zgodnie z rolą.
Ta centralizacja ułatwia spójne zarządzanie stacjami Windows, ale też tworzy zależności: niedostępny kontroler domeny albo błędna konfiguracja DNS potrafią zakłócić logowanie i dostęp do aplikacji. Dla programisty .NET istotne jest więc, z jakim typem katalogu łączy się aplikacja i jakiego mechanizmu logowania wymaga.
Przy aplikacji .NET wybór zależy od protokołu logowania
Aplikacja korzystająca z LDAP, Kerberos, NTLM, dołączania komputerów do domeny lub GPO ma wymagania typowe dla AD DS. Z kolei aplikacja oparta na logowaniu do Microsoft 365 albo nowoczesnym uwierzytelnianiu może lepiej pasować do Microsoft Entra ID. Podobna nazwa nie oznacza zamienności tych usług.
Microsoft rozróżnia też Microsoft Entra Domain Services, czyli zarządzaną usługę domenową w Azure, która udostępnia wybrane tradycyjne możliwości, takie jak LDAP, Kerberos i zasady grupy. W porównaniu przygotowanym przez Microsoft Learn AD DS opisano jako usługę z zarządzaniem obiektami komputerów, GPO i relacjami zaufania, a Entra ID jako usługę tożsamości dla zasobów chmurowych. Zarządzana usługa domenowa przydaje się, gdy starsza aplikacja potrzebuje protokołów domenowych, lecz organizacja nie chce samodzielnie utrzymywać kontrolerów w chmurze.
Reguła wyboru jest praktyczna: jeśli aplikacja wymaga LDAP lub Kerberosa, sprawdź zgodność z AD DS albo Entra Domain Services; jeśli używa OpenID Connect lub OAuth, rozważ Entra ID. W projekcie .NET najpierw spisałbym wymagane protokoły i sposób dołączania urządzeń, a dopiero potem dobierał usługę katalogową. Sam fakt, że rozwiązanie działa w Azure, nie mówi jeszcze, której z nich potrzebuje.
Gdy logowanie do domeny zawodzi, zacznij od DNS
Stacja robocza nie musi znać adresu kontrolera domeny na pamięć. Odszukuje go między innymi przez rekordy SRV w DNS, które wskazują serwery oferujące określone usługi katalogowe. Dokumentacja Microsoft Learn dotycząca lokalizowania kontrolerów opisuje także wybór kontrolera z uwzględnieniem lokacji Active Directory.
Jeśli komputer używa publicznego serwera DNS zamiast DNS obsługującego domenę, może nie znaleźć tych rekordów. Objaw przypomina wtedy problem z hasłem albo niedostępnością domeny, choć przyczyna leży w rozwiązywaniu nazw. Tabela pomaga zawęzić pierwszy krok diagnostyczny.
| Sytuacja | Możliwa przyczyna | Co sprawdzić |
|---|---|---|
| Komputera nie można dołączyć do domeny | Klient nie widzi kontrolera domeny lub nie znajduje rekordów SRV | Ustawienia DNS klienta, łączność z siecią firmową i zapytanie o rekordy SRV domeny |
| Logowanie działa w biurze, ale szwankuje przez VPN | Klient VPN nie kieruje zapytań DNS do właściwych serwerów albo brakuje łączności z kontrolerem | Serwery DNS przekazane przez VPN, sufiks DNS oraz dostęp do usług domenowych |
| Problem dotyczy głównie jednej lokalizacji | Niepoprawne przypisanie podsieci do lokacji lub błędne rekordy lokalizacyjne | Adres IP klienta, obiekt podsieci i lokację kontrolera w konfiguracji AD DS |
Przy diagnostyce zacząłbym od zapytania DNS i sprawdzenia, jaki kontroler został odnaleziony, zanim zmieniałbym hasła lub uprawnienia użytkownika. Takie rozdzielenie pozwala odróżnić problem z tożsamością od problemu z odnajdywaniem usługi.
Lokacje i replikacja decydują, skąd domena pobiera zmiany
W organizacji z biurem głównym i oddziałami każde logowanie nie powinno niepotrzebnie obciążać łącza WAN. Obiekty Active Directory Sites and Services wiążą podsieci IP z lokacjami, a łącza lokacji opisują logiczne ścieżki replikacji między nimi. Jeśli podsieć nie jest przypisana prawidłowo, komputer może korzystać z kontrolera z innej lokalizacji.
Zmiana hasła, członkostwa w grupie lub konfiguracji katalogu musi dotrzeć do pozostałych kontrolerów. Gdy replikacja nie działa, jeden serwer może znać nowe dane, a inny nadal odpowiadać na podstawie starszego stanu. Microsoft wskazuje błędną konfigurację DNS, łączność sieciową i niezgodność topologii lokacji z rzeczywistymi połączeniami WAN lub VPN jako możliwe przyczyny awarii replikacji.
Po dodaniu kontrolera do nowej lokalizacji sprawdź nie tylko, czy serwer odpowiada, lecz także czy klienci trafiają do niego zgodnie z przypisaniem podsieci i czy zmiany replikują się między lokacjami. W przeciwnym razie drugi kontroler może zwiększyć złożoność bez poprawy dostępności.
Pięć ról FSMO nie oznacza jednego serwera do każdego logowania
W katalogu większość zmian może obsługiwać więcej niż jeden kontroler, ale wybrane operacje mają przypisanego właściciela. Służy do tego pięć ról FSMO: Schema Master i Domain Naming Master działają w skali lasu, a PDC Emulator, RID Master i Infrastructure Master w skali domeny. Ich zakresy różnią się, więc awaria właściciela pojedynczej roli nie musi automatycznie zatrzymać zwykłego logowania wszystkich użytkowników.
Przykładowo Schema Master obsługuje zmiany schematu katalogu, a Domain Naming Master uczestniczy w dodawaniu i usuwaniu domen w lesie. PDC Emulator ma szerszy kontakt z codziennymi operacjami niż pozostałe role, dlatego jego dostępność zasługuje na szczególną uwagę. Microsoft Learn opisuje zakresy tych ról oraz wskazuje, że ich rozmieszczenie nabiera większego znaczenia wraz z rozbudową lasu o kolejne domeny i lokacje.
W małej domenie nie przenosiłbym ról FSMO bez powodu; najpierw ustaliłbym ich właścicieli i zapewnił kopię zapasową stanu systemu kontrolera. Przy awarii plan przejęcia roli zależy od tego, czy dotychczasowy serwer wróci do sieci, więc pochopne działania mogą skomplikować późniejsze odtworzenie.
Przywracanie kontrolera wymaga kopii stanu systemu
Migawka maszyny wirtualnej wygląda jak wygodny skrót do kopii zapasowej, ale nie powinna zastępować kopii zgodnej z Active Directory. Nowsze wersje AD DS korzystają z identyfikatora VM-Generation ID, jeśli obsługuje go hypervisor; mechanizm może wykryć przywrócenie migawki i uruchomić zabezpieczenia ograniczające ryzyko problemów z replikacją. To zabezpieczenie nie zmienia migawki w zalecaną metodę odtwarzania kontrolera.
Microsoft zaleca kopię stanu systemu wykonaną narzędziem zgodnym z Active Directory, takim jak Windows Server Backup. Przywrócenie starej kopii może prowadzić do problemów, jeśli przekracza okres utrzymywania tombstone’ów, czyli znaczników usuniętych obiektów replikowanych między kontrolerami. Dlatego scenariusz odzyskiwania powinien uwzględniać wiek kopii, dostępność innych kontrolerów oraz sposób odtworzenia usługi SYSVOL.
Jeśli problem dotyczy pojedynczego obiektu, a pozostałe kontrolery działają, dobór procedury będzie inny niż przy utracie całej domeny. W dokumentacji „Active Directory Forest Recovery” Microsoft opisuje tworzenie kopii stanu systemu kontrolerów na potrzeby odzyskiwania lasu. W praktyce plan powinien jasno określać, skąd pobrać kopię i kto podejmuje decyzję o odtwarzaniu, zanim awaria odetnie dostęp do domeny.
Najpierw ustal, która warstwa przestała odpowiadać
Gdy użytkownik nie może się zalogować, problem może leżeć w koncie, DNS, łączności z kontrolerem albo replikacji. Oddziel te warstwy przed zmianą konfiguracji: sprawdź, czy klient odnajduje kontroler, czy serwer ma aktualne dane i czy aplikacja korzysta z właściwego mechanizmu uwierzytelniania.
Dla środowiska .NET oznacza to prostą kolejność decyzji: najpierw wymagania protokołu, potem wybór usługi katalogowej, a przy awarii sprawdzenie DNS i stanu kontrolerów. Taki porządek skraca drogę od komunikatu „nie można zalogować” do przyczyny, którą da się naprawić.
