Active Directory po 10 latach.
Co najczęściej zastajemy u nowych klientów?

Active Directory bardzo rzadko powstaje od razu jako duże i skomplikowane środowisko. Najczęściej zaczyna się od jednego kontrolera domeny, kilkunastu użytkowników i kilku prostych zasad grupowych.

Później firma rośnie. Pojawiają się kolejne serwery, oddziały, aplikacje, administratorzy, integratorzy i dostawcy zewnętrzni. Każdy dodaje konta, grupy, reguły oraz wyjątki potrzebne w danym momencie.

Po ośmiu, dziesięciu albo piętnastu latach domena nadal działa, ale często nikt nie potrafi już odpowiedzieć na podstawowe pytania:

• -które polityki GPO są naprawdę potrzebne,
• -kto ma uprawnienia administracyjne,
• -z jakich kont korzystają usługi,
• -czy kontrolery domeny są prawidłowo backupowane,
• -czy replikacja działa bez błędów,
• -które stare konta nadal umożliwiają logowanie,
• -co wydarzy się po awarii jednego z kontrolerów.

Nie oznacza to, że środowisko zostało pierwotnie źle zaprojektowane. Najczęściej jest to naturalny skutek wieloletniego rozwoju bez regularnych przeglądów, dokumentacji i konsekwentnego procesu zarządzania zmianami.

Dlaczego stare Active Directory staje się ryzykiem?

Active Directory odpowiada za uwierzytelnianie użytkowników, komputerów i usług. W wielu firmach kontroluje również dostęp do plików, systemów ERP, serwerów, sieci VPN, aplikacji biznesowych, kopii zapasowych, środowiska Microsoft 365, urządzeń sieciowych i infrastruktury wirtualnej.

Przejęcie konta o wysokich uprawnieniach może więc umożliwić atakującemu dostęp do znacznej części organizacji. Microsoft zaleca stosowanie zasady najmniejszych uprawnień oraz nieużywanie kont o wysokich uprawnieniach do zwykłych, codziennych prac administracyjnych.

Wieloletnia domena bez regularnych przeglądów często zawiera jednak wiele historycznych wyjątków, które z czasem stają się trudne do zauważenia i jeszcze trudniejsze do bezpiecznego usunięcia.

1. Stare kontrolery domeny i niespójne wersje systemów

Jednym z pierwszych elementów audytu jest sprawdzenie wersji systemów działających jako kontrolery domeny. Najczęściej spotykamy Windows Server 2012 R2, Windows Server 2016, mieszaninę wersji 2016, 2019 i 2022, kontrolery działające na starym sprzęcie fizycznym oraz maszyny wirtualne pamiętające kilka generacji platformy wirtualizacyjnej.

Windows Server 2012 R2 zakończył rozszerzone wsparcie 10 października 2023 roku. Windows Server 2016 pozostaje w rozszerzonym wsparciu do stycznia 2027 roku, dlatego środowiska nadal wykorzystujące tę wersję powinny już posiadać plan migracji.

Najważniejsze ryzyka starych kontrolerów to:

Nie rekomendujemy wykonywania ryzykownego uaktualnienia działającego kontrolera domeny tylko po to, aby zachować starą instalację. Bezpieczniejszy proces najczęściej obejmuje:

1. 1 przygotowanie nowego serwera,
2. 2 dołączenie go do domeny,
3. 3 promocję do roli kontrolera domeny,
4. 4 sprawdzenie replikacji,
5. 5 przeniesienie ról FSMO, jeżeli jest to potrzebne,
6. 6 kontrolowane wycofanie starego serwera.

Microsoft opisuje migrację kontrolerów domeny jako proces wymagający sprawdzenia wersji systemów, poziomu funkcjonalności i zgodności całego lasu.

2. Niski poziom funkcjonalności domeny i lasu

W starszych środowiskach często spotykamy poziomy funkcjonalności Windows Server 2008 R2, 2012 R2 lub 2016. Sam niski poziom nie oznacza automatycznie awarii ani braku zgodności z Windows 11. Określa jednak zestaw funkcji Active Directory dostępnych w domenie i lesie.

Windows Server 2025 wprowadził nowy poziom funkcjonalności domeny i lasu. Aby go włączyć, wszystkie kontrolery domeny w danym zakresie muszą działać na Windows Server 2025.

Podnoszenie poziomu funkcjonalności nie powinno być pierwszą zmianą wykonywaną podczas przejęcia środowiska. Najpierw należy sprawdzić wersje wszystkich kontrolerów, stan replikacji, aplikacje zależne od AD, Exchange, usługi certyfikatów, systemy korzystające ze starszych metod uwierzytelniania oraz możliwość odtworzenia domeny.

3. Brak redundancji kontrolerów domeny

W części małych firm domena nadal opiera się na jednym kontrolerze. Taka konfiguracja tworzy pojedynczy punkt awarii dla logowania użytkowników, DNS, polityk grupowych, aplikacji zależnych od domeny i dostępu do części zasobów sieciowych.

W większości środowisk produkcyjnych warto posiadać co najmniej dwa kontrolery domeny. Powinny działać na niezależnych hostach wirtualizacji, a w bardziej rozbudowanych organizacjach również w różnych lokalizacjach.

Dwa kontrolery nie zastępują jednak backupu. Błąd administracyjny, usunięcie obiektów albo przejęcie domeny może zostać zreplikowane pomiędzy wszystkimi serwerami.

4. Kontroler domeny pełniący kilka innych ról

W starszych firmach nadal spotykamy serwer, który jednocześnie działa jako kontroler domeny, DNS, DHCP, serwer plików, serwer wydruku, serwer aplikacji, baza danych i serwer licencji.

Nie każda dodatkowa rola jest automatycznie błędem. DNS jest wręcz naturalnym elementem środowiska Active Directory, a DHCP w niewielkiej organizacji może działać na tym samym Windows Server. Problem zaczyna się wtedy, gdy awaria lub aktualizacja jednego serwera wpływa jednocześnie na wszystkie podstawowe usługi firmy.

Szczególnie warto oddzielić od kontrolera domeny aplikacje biznesowe, bazy danych, publicznie dostępne usługi, serwer plików z dużą liczbą użytkowników oraz oprogramowanie niepotrzebne do działania AD DS. Kontroler domeny powinien mieć możliwie ograniczony zakres oprogramowania i dostępów.

5. Chaos w strukturze OU

Organizational Units powinny ułatwiać delegowanie uprawnień, stosowanie polityk grupowych, zarządzanie komputerami, rozdzielenie serwerów i stacji roboczych oraz oddzielenie kont uprzywilejowanych.

Po wielu latach często zastajemy jednak:

• -jedną płaską strukturę,
• -OU odwzorowujące nieaktualny schemat organizacyjny,
• -wiele pustych jednostek,
• -komputery znajdujące się w domyślnym kontenerze,
• -serwery i stacje robocze objęte tymi samymi GPO,
• -konta administratorów wymieszane ze zwykłymi kontami.

Struktura OU nie musi dokładnie odzwierciedlać działów firmy. Powinna przede wszystkim wspierać zarządzanie, delegację oraz stosowanie konfiguracji. Nadmiernie rozbudowane drzewo jest równie problematyczne jak całkowicie płaskie środowisko.

6. Nieaktualne i sprzeczne GPO

Group Policy jest jednym z najpotężniejszych mechanizmów zarządzania domeną. Po wielu latach może jednak zawierać polityki bez właściciela, stare skrypty logowania, ustawienia nieużywanego oprogramowania, zduplikowane konfiguracje, filtry WMI, których nikt nie rozumie, wyjątki dodawane w celu naprawienia innych wyjątków oraz reguły osłabiające nowsze systemy.

Brak WMI Filtering albo blokady dziedziczenia nie jest problemem samym w sobie. Te mechanizmy należy stosować tylko wtedy, gdy mają konkretne uzasadnienie. Ich nadmiar może utrudnić analizę wyniku polityk i wydłużyć logowanie użytkowników.

Podczas audytu sprawdzamy linkowanie GPO, kolejność stosowania, wymuszanie polityk, filtry bezpieczeństwa i WMI, nieużywane ustawienia, datę ostatnich zmian oraz zgodność polityk z aktualnymi systemami. Nie usuwamy od razu każdej starej polityki - najpierw ustalamy, jakie komputery i konta rzeczywiście jej używają.

7. Zbyt wiele kont uprzywilejowanych

Jednym z najpoważniejszych problemów jest nadmierna liczba członków grup takich jak Domain Admins, Enterprise Admins, Schema Admins, Administrators, Backup Operators i Account Operators.

Często znajdują się w nich zwykłe konta administratorów, konta serwisowe, byli pracownicy, integratorzy, konta utworzone do jednorazowego wdrożenia oraz grupy zawierające kolejne grupy.

Microsoft zaleca ograniczanie stałych uprawnień oraz rozdzielanie ról lokalnych, domenowych i chmurowych. Dotyczy to również kont posiadających jednocześnie wysokie uprawnienia w Active Directory i Microsoft Entra ID.

Dobra praktyka polega na używaniu:

• -osobnego konta do zwykłej pracy,
• -osobnego konta do administracji stacjami,
• -osobnego konta do zarządzania serwerami,
• -ściśle chronionego konta do zmian w domenie.

Konto Domain Admin nie powinno służyć do czytania poczty, przeglądania internetu ani codziennego logowania na stacjach roboczych.

8. Konto Administrator i wspólne hasła

W starszych domenach często kilka osób korzysta z jednego konta administracyjnego. Powoduje to problemy z ustaleniem autora zmiany, bezpiecznym odebraniem dostępu, audytem operacji, rotacją haseł i rozliczalnością administratorów.

Warto wdrożyć indywidualne konta oraz pozostawić wbudowane konto Administrator wyłącznie jako odpowiednio zabezpieczony dostęp awaryjny.

Należy również sprawdzić hasło DSRM, czyli Directory Services Restore Mode. W wielu firmach zostało ustawione podczas instalacji domeny i od tamtej pory nikt go nie weryfikował.

9. Konta byłych pracowników i dostawców

Częstym problemem są konta nieużywane od kilku lat. Mogą należeć do byłych pracowników, poprzednich administratorów, zewnętrznych wdrożeniowców, dostawców systemów, nieistniejących aplikacji lub kont testowych. Pisaliśmy o tym również w kontekście IT offboardingu po odejściu pracownika.

Nie należy jednak automatycznie usuwać wszystkich kont na podstawie daty ostatniego logowania. Niektóre wartości mogą być niepełne, a konto może być wykorzystywane przez usługę lub zadanie harmonogramu.

Bezpieczny proces obejmuje:

1. 1 identyfikację właściciela,
2. 2 sprawdzenie członkostwa w grupach,
3. 3 analizę logowań,
4. 4 sprawdzenie usług i zadań,
5. 5 czasowe wyłączenie,
6. 6 obserwację środowiska,
7. 7 usunięcie po upływie ustalonego okresu.

10. Konta serwisowe z niepotrzebnymi uprawnieniami

Starsze aplikacje często działają na zwykłych kontach domenowych z hasłem, które nigdy nie wygasa, jest znane kilku osobom, znajduje się w dokumentacji tekstowej, posiada uprawnienia Domain Admin i jest używane przez wiele niezależnych usług.

Microsoft rekomenduje regularną identyfikację kont serwisowych i ograniczanie ich uprawnień. Tam, gdzie aplikacja to obsługuje, warto rozważyć gMSA, czyli Group Managed Service Accounts. Mechanizm umożliwia automatyczne zarządzanie hasłem konta przez Active Directory i ograniczenie komputerów, które mogą z niego korzystać.

Migracja na gMSA wymaga jednak testów. Nie każda starsza aplikacja lub usługa wspiera ten typ konta.

11. Lokalne hasła administratorów bez Windows LAPS

W wielu organizacjach każde stanowisko ma to samo lokalne hasło administratora. Jeżeli zostanie ono przejęte na jednym komputerze, może umożliwić atakującemu przemieszczanie się pomiędzy kolejnymi urządzeniami.

Windows LAPS pozwala automatycznie generować i przechowywać różne hasło lokalnego administratora dla każdego komputera. Wdrożenie powinno obejmować ograniczenie osób mogących odczytać hasła, audyt dostępu, politykę rotacji, zabezpieczenie konta lokalnego i test procedury awaryjnej.

12. Nieaktualne zasady haseł

W starszych domenach często spotykamy politykę wymagającą minimum ośmiu znaków, zmiany co 30 lub 90 dni, złożoności i historii kilku haseł. Taka konfiguracja może prowadzić do przewidywalnych schematów, na przykład Firma2026!, a następnie Firma2027!.

Lepsze podejście obejmuje:

W czystym lokalnym Active Directory MFA nie działa automatycznie dla każdego protokołu. Może wymagać dodatkowych rozwiązań, na przykład dla VPN, RDP, aplikacji albo środowiska hybrydowego.

13. Brak nowoczesnego modelu dostępu uprzywilejowanego

Klasyczny model Tier 0, Tier 1 i Tier 2 nadal pomaga zrozumieć różne poziomy ryzyka:

Microsoft rozwija obecnie szerszy Enterprise Access Model, który obejmuje również środowiska chmurowe, urządzenia i warstwy zarządzania.

W małej firmie nie zawsze trzeba budować rozbudowany model korporacyjny. Należy jednak przynajmniej oddzielić administrację domeną od wsparcia użytkowników, ograniczyć logowanie kont wysokiego poziomu, używać dedykowanych urządzeń lub sesji administracyjnych, kontrolować dostęp dostawców i monitorować członkostwo w grupach uprzywilejowanych.

14. Problemy z DNS

Active Directory jest silnie zależne od DNS. Problemy z DNS często objawiają się jako wolne logowanie, brak stosowania GPO, problemy z dołączeniem komputera do domeny, błędy replikacji lub okresowa niedostępność usług.

W starszych środowiskach spotykamy tysiące nieaktualnych rekordów, błędne serwery DNS na kartach sieciowych, ręcznie wpisane publiczne DNS na klientach domenowych, stare rekordy po usuniętych serwerach, nieprawidłowe delegacje i brak kontroli dynamicznych aktualizacji.

DNS Aging i Scavenging mogą automatycznie usuwać przestarzałe rekordy dynamiczne, ale są domyślnie wyłączone i wymagają poprawnej konfiguracji zarówno na serwerze, jak i w strefie. Ręcznie utworzone rekordy z timestampem równym zero nie są automatycznie usuwane.

Scavenging nie powinien być włączany bez analizy. Błędna konfiguracja może usunąć potrzebne rekordy.

15. DHCP bez redundancji

Jeden serwer DHCP jest kolejnym częstym punktem awarii. Windows Server obsługuje DHCP Failover, który pozwala dwóm serwerom współdzielić informacje o zakresach, konfiguracji i aktywnych dzierżawach. Po awarii jednego z nich drugi może obsługiwać klientów.

Sam fakt uruchomienia DHCP na kontrolerze domeny nie jest automatycznie błędem. Ważniejsze pytania brzmią: czy istnieje redundancja, czy konfiguracja jest backupowana, czy aktualizacje DNS są bezpieczne, jakie konto wykonuje rejestrację rekordów i co stanie się po awarii serwera.

16. Problemy z replikacją Active Directory

Domena może pozornie działać, mimo że replikacja od miesięcy zgłasza błędy. Typowe przyczyny to problemy DNS, zerwane połączenia między lokalizacjami, błędna konfiguracja Sites and Services, kontroler odłączony przez długi czas, nieprawidłowa synchronizacja czasu, stary serwer, którego nigdy poprawnie nie usunięto, oraz uszkodzony SYSVOL.

Podczas audytu wykorzystujemy między innymi dcdiag, repadmin, dzienniki Directory Service i DFS Replication, analizę DNS, kontrolę ról FSMO oraz sprawdzenie SYSVOL i NETLOGON.

Problemów replikacji nie powinno się naprawiać przez przypadkowe usuwanie obiektów lub ponowną promocję serwera bez ustalenia przyczyny.

17. Stare lub źle skonfigurowane usługi certyfikatów

Active Directory Certificate Services bywa wdrażane podczas projektu VPN, Wi-Fi, kart inteligentnych albo szyfrowania. Po kilku latach często okazuje się, że nikt nie zna konfiguracji CA, serwer działa na starym systemie, klucz prywatny nie ma bezpiecznej kopii, szablony certyfikatów mają zbyt szerokie uprawnienia, a użytkownicy mogą wystawiać certyfikaty o niebezpiecznych właściwościach.

AD CS jest elementem Tier 0, ponieważ przejęcie urzędu certyfikacji może umożliwić podszywanie się pod użytkowników i systemy. Nie powinno się go modernizować ani wyłączać bez pełnej analizy zależności.

18. Brak monitoringu zmian w Active Directory

W wielu firmach nikt nie otrzymuje alertu, gdy użytkownik zostaje dodany do Domain Admins, powstaje nowe konto administratora, zmieniana jest polityka domenowa, konto serwisowe zaczyna logować się z nietypowego urządzenia, zostaje wyłączony audyt albo pojawiają się błędy replikacji.

Monitoring powinien obejmować co najmniej:

W większych środowiskach można dodatkowo wykorzystać Microsoft Defender for Identity lub inne systemy analizujące zachowania i ścieżki ataku.

19. Brak prawidłowego backupu Active Directory

Backup całej maszyny wirtualnej jest wartościowy, ale domena wymaga również świadomej strategii odtwarzania. Microsoft wskazuje, że w scenariuszu Disaster Recovery należy regularnie wykonywać backup System State kontrolera domeny. Obejmuje on między innymi bazę Active Directory, logi, rejestr i SYSVOL.

Strategia powinna odpowiadać na pytania:

• -który kontroler jest backupowany,
• -gdzie znajduje się kopia,
• -czy backup jest odporny na ransomware,
• -czy znamy hasło DSRM,
• -jak wykonać odtworzenie nieautorytatywne,
• -jak odzyskać przypadkowo usunięte obiekty,
• -co zrobić po utracie całego lasu.

Microsoft zaleca, aby backup domeny był wykonywany odpowiednio często i nie był starszy niż tombstone lifetime. Dla domen utworzonych na nowszych wersjach Windows Server domyślna wartość zwykle wynosi 180 dni. Pełna procedura Forest Recovery powinna być przygotowana i testowana przed wystąpieniem awarii.

20. Brak dokumentacji

Najczęściej nie znajdujemy jednego spektakularnego błędu. Znajdujemy środowisko, o którym nikt nie posiada kompletnej wiedzy. Brakuje informacji o kontrolerach domeny, rolach FSMO, strukturze OU, GPO, kontach serwisowych, grupach uprzywilejowanych, integracjach, DNS, DHCP, certyfikatach, backupie i procedurach awaryjnych.

Dokumentacja nie musi mieć kilkuset stron. Powinna umożliwić innej osobie zrozumienie architektury i bezpieczne przejęcie podstawowych działań. Jak ją zbudować, opisaliśmy w artykule Jak przygotować dokumentację IT od zera?

Jak wygląda audyt Active Directory?

Audyt powinien być wykonywany etapami i bez wprowadzania ryzykownych zmian na początku.

Etap 1. Zebranie danych

Sprawdzamy strukturę lasu i domen, kontrolery domeny, poziomy funkcjonalności, role FSMO, Sites and Services, DNS i DHCP, replikację, GPO, konta i grupy, konta serwisowe, polityki haseł, AD CS, Entra Connect lub Cloud Sync oraz backup.

Etap 2. Analiza bezpieczeństwa

Oceniamy liczbę kont uprzywilejowanych, zagnieżdżone członkostwa, uprawnienia delegowane, konta nieaktywne, logowanie kont administracyjnych, słabe protokoły, ścieżki prowadzące do przejęcia domeny oraz dostęp dostawców zewnętrznych.

Narzędzia analizujące relacje uprawnień, takie jak BloodHound, mogą być pomocne, ale powinny być używane w kontrolowanym zakresie, za zgodą klienta i z odpowiednim zabezpieczeniem zebranych danych.

Etap 3. Ocena ciągłości działania

Sprawdzamy liczbę kontrolerów, niezależność hostów, backup System State, hasło DSRM, procedurę odtworzenia, redundancję DNS i DHCP oraz zależności od pojedynczych serwerów.

Etap 4. Raport i plan modernizacji

Problemy dzielimy według priorytetu:

Jak wygląda bezpieczna modernizacja domeny?

Modernizacja nie powinna oznaczać wykonywania wszystkich zmian w pierwszym miesiącu. Rozsądny plan może wyglądać następująco:

1. 1 Stabilizacja: naprawa replikacji, potwierdzenie backupu, wdrożenie drugiego kontrolera, zabezpieczenie dostępów awaryjnych, usunięcie krytycznych uprawnień, aktualizacja dokumentacji.
2. 2 Migracja kontrolerów: wdrożenie nowych serwerów, przeniesienie ról, kontrola DNS, democja starych kontrolerów, usunięcie pozostałości, podniesienie poziomu funkcjonalności, jeżeli jest uzasadnione.
3. 3 Porządkowanie tożsamości: wyłączenie nieaktywnych kont, uporządkowanie grup, wdrożenie gMSA i Windows LAPS, rozdzielenie kont administracyjnych, ograniczenie logowania kont uprzywilejowanych.
4. 4 GPO i urządzenia: przegląd polityk, testy w wydzielonej OU, usuwanie nieużywanych ustawień, wdrożenie aktualnych baseline bezpieczeństwa, kontrolowane wyłączenie starszych protokołów.
5. 5 Monitoring i procedury: alerty dotyczące zmian uprzywilejowanych, monitoring replikacji, kontrola synchronizacji Entra ID, test odtworzenia, procedura Forest Recovery, cykliczny audyt.

Czy warto migrować wszystko do Microsoft Entra ID?

Microsoft Entra ID nie jest bezpośrednim zamiennikiem Active Directory Domain Services. Oba rozwiązania mają inny model działania i inne zastosowania. Microsoft opisuje AD DS jako usługę katalogową opartą między innymi na domenach, Kerberosie, LDAP i Group Policy, natomiast Entra ID jako chmurową platformę tożsamości dla aplikacji i usług.

Firmy korzystające z klasycznych aplikacji domenowych, systemów ERP, udziałów SMB, Kerberosa, LDAP, serwerów Windows i rozbudowanych GPO często nadal potrzebują lokalnego AD albo modelu hybrydowego.

Dla organizacji działających głównie na Microsoft 365, aplikacjach SaaS i urządzeniach zarządzanych przez Intune możliwe jest stopniowe ograniczanie zależności od lokalnej domeny. Jak wygląda takie wdrożenie, opisaliśmy w artykule o wdrożeniu Microsoft Entra ID.

Decyzję należy podjąć po analizie aplikacji i procesów, a nie tylko dlatego, że Entra ID jest nowszą usługą.

Najczęstsze błędy podczas porządkowania Active Directory

Nieaktywne konto może być używane przez usługę lub integrację. Wyłączenie starszych protokołów bez analizy może zatrzymać ERP, skanery i urządzenia przemysłowe. Microsoft ostrzega też, że nie należy dodawać wszystkich kont uprzywilejowanych do grupy Protected Users bez testów, ponieważ może to wpłynąć na zgodność uwierzytelniania.

Podsumowanie

Active Directory po dziesięciu latach rzadko jest całkowicie zepsute. Najczęściej działa, ale zawiera wiele historycznych decyzji, wyjątków i kont, których znaczenia nikt już nie pamięta.

Największe zagrożenia zwykle nie wynikają z jednej starej polityki. Wynikają z połączenia kilku elementów: niewspieranych kontrolerów domeny, nadmiernych uprawnień, wspólnych kont administratorów, nieznanych kont serwisowych, braku monitoringu, problemów z DNS i replikacją, braku testowanego backupu oraz nieaktualnej dokumentacji.

Modernizacja domeny nie powinna polegać na gwałtownym usuwaniu wszystkiego, co wygląda na stare. Najpierw trzeba zrozumieć zależności, zabezpieczyć możliwość odtworzenia środowiska, usunąć krytyczne ryzyka i dopiero później porządkować strukturę.

W PRO-Admin rozpoczynamy od audytu technicznego i bezpieczeństwa. Sprawdzamy kontrolery domeny, replikację, DNS, GPO, konta, uprawnienia, backup oraz integrację z Microsoft Entra ID. Następnie przygotowujemy plan modernizacji podzielony na etapy, tak aby poprawiać bezpieczeństwo bez zatrzymywania codziennej pracy firmy.