Zabezpieczenie logowań AD

Zabezpieczenie logowań AD wymaga silnej polityki haseł i uwierzytelniania wieloskładnikowego na poziomie domeny.

Mechanizmy uwierzytelniania w Active Directory

Zabezpieczenie logowań AD, czyli logowań do domeny Active Directory Domain Services, zaczyna się od prawidłowego rozróżnienia sposobu uwierzytelniania. W typowej domenie Windows podstawowym protokołem jest Kerberos w wersji 5. Podczas logowania kontroler domeny pełniący rolę serwera KDC wydaje użytkownikowi bilet uwierzytelniający, a następnie bilety usługowe potrzebne do korzystania z zasobów sieciowych. Ogranicza to konieczność przesyłania hasła przy każdym dostępie do udziału, usługi lub komputera.

Drugim mechanizmem jest NTLM, który może zostać użyty między innymi wtedy, gdy Kerberos nie może zostać zastosowany. Taka sytuacja może wynikać z dostępu do usługi po adresie IP, nieprawidłowej konfiguracji nazw DNS, braku zaufania domenowego albo niezgodności aplikacji. NTLM powinien być traktowany jako mechanizm awaryjny i ograniczany za pomocą zasad zabezpieczeń oraz audytu. Samo wymuszenie silnych haseł nie rozwiązuje problemu, jeśli środowisko dopuszcza niekontrolowane użycie starszego protokołu.

Do poprawnego działania Kerberosa potrzebne są między innymi prawidłowe rekordy DNS, synchronizacja czasu oraz dostęp klienta do odpowiedniego kontrolera domeny. Kerberos wykorzystuje znaczniki czasu, dlatego większa rozbieżność zegarów może powodować odrzucenie biletu. W praktyce analiza logowania powinna obejmować nie tylko nazwę użytkownika i komunikat na ekranie, lecz także kontroler domeny, użyty protokół, źródłowy komputer, typ logowania oraz powiązane zdarzenia w dzienniku zabezpieczeń.

Polityka haseł i ochrona poświadczeń

Polityka haseł w domenie powinna określać minimalną długość, historię używanych haseł, wymagania dotyczące złożoności oraz reakcję na wielokrotne nieudane próby logowania. W klasycznej polityce domenowej ustawienia te są konfigurowane w obiekcie Default Domain Policy albo w odpowiedniej polityce grupowej obejmującej konta domenowe. W środowiskach wymagających różnych zasad dla poszczególnych grup można użyć Fine-Grained Password Policies, czyli szczegółowych zasad haseł przypisanych do użytkowników lub grup zabezpieczeń.

Ważne jest rozdzielenie blokady konta od wygaszania hasła. Account lockout może zatrzymać próby logowania po przekroczeniu ustalonego progu, ale zbyt niski próg może powodować łatwe blokowanie kont przez powtarzane próby z błędnym hasłem. Warto rejestrować zdarzenia blokady i ustalać ich źródło, ponieważ nieudane logowania mogą pochodzić z zapisanych poświadczeń w usłudze, zadaniu harmonogramu, mapowanym udziale sieciowym albo urządzeniu korzystającym z nieaktualnego hasła.

Ochrona kont uprzywilejowanych wymaga dodatkowych ograniczeń. Konta administracyjne nie powinny być używane do codziennej pracy, przeglądania stron ani uruchamiania przypadkowych aplikacji. Należy ograniczać ich logowanie interaktywne do wyznaczonych stacji administracyjnych, kontrolować członkostwo w grupach takich jak Domain Admins i rejestrować użycie uprawnień. Hasła kont usługowych również wymagają przeglądu; tam, gdzie jest to możliwe, bezpieczniejszym rozwiązaniem są konta zarządzane przez system, na przykład gMSA, zamiast haseł wpisanych na stałe w skryptach lub konfiguracjach.

Uwierzytelnianie wieloskładnikowe przy logowaniu domenowym

Uwierzytelnianie wieloskładnikowe oznacza użycie co najmniej dwóch niezależnych składników, na przykład hasła oraz klucza sprzętowego, certyfikatu na karcie inteligentnej albo zatwierdzenia w aplikacji. Active Directory Domain Services nie dodaje automatycznie uniwersalnego drugiego składnika do każdego logowania do systemu Windows. MFA musi zostać zrealizowane przez konkretny mechanizm: Windows Hello for Business, logowanie kartą inteligentną, dostawcę poświadczeń, rozwiązanie ochrony dostępu zdalnego albo integrację z usługą tożsamości obsługującą dodatkową weryfikację.

Windows Hello for Business może wykorzystywać klucz kryptograficzny chroniony przez moduł TPM, a użytkownik odblokowuje go za pomocą kodu PIN lub biometrii. PIN nie jest hasłem domenowym i służy do lokalnego odblokowania klucza przypisanego do urządzenia. Przy wdrażaniu trzeba rozróżnić logowanie na urządzeniu należącym do domeny, urządzeniu Microsoft Entra joined oraz scenariuszu hybrydowym. Należy również sprawdzić, czy używany model wdrożenia, certyfikaty, kontrolery domeny i usługi zaufania obsługują wymagany przepływ.

W przypadku dostępu zdalnego MFA powinno być zastosowane w punkcie, który rzeczywiście kontroluje wejście do zasobu, na przykład przy VPN, bramie zdalnego pulpitu lub aplikacji publikującej usługę. Samo włączenie MFA dla poczty lub panelu chmurowego nie zabezpiecza automatycznie lokalnego logowania do komputera domenowego. Równie istotne jest przygotowanie procedury awaryjnej: utrata telefonu, niedostępność usługi uwierzytelniającej lub uszkodzony klucz nie powinny prowadzić do obchodzenia kontroli przez wspólne konta i współdzielone hasła.

Audyt zdarzeń i kontrola ścieżki logowania

Ocena zabezpieczenia logowań AD wymaga włączenia odpowiednich kategorii zaawansowanego audytu za pomocą Group Policy. Szczególne znaczenie mają zdarzenia logowania na komputerze, użycia poświadczeń, dostępu do usług uwierzytelniających oraz zmian w grupach i kontach. Zdarzenie 4624 opisuje udane logowanie, a 4625 nieudaną próbę. Zdarzenie 4740 wskazuje blokadę konta, natomiast 4768 i 4769 dotyczą odpowiednio żądania biletu uwierzytelniającego Kerberos oraz biletu usługowego. Warto analizować także 4776, związane z weryfikacją poświadczeń przez kontroler domeny.

Sam numer zdarzenia nie wystarcza do wyciągnięcia wniosku. Trzeba porównać konto, adres źródłowy, nazwę stacji, typ logowania, proces wywołujący oraz czas zdarzenia. Wielokrotne zdarzenia 4625 z jednego hosta mogą oznaczać błędne poświadczenia zapisane w usłudze, ale podobny wzorzec z wielu adresów może wskazywać na próbę odgadywania haseł. Z kolei logowanie typu 10 oznacza zwykle połączenie przez Remote Desktop Protocol, dlatego powinno być oceniane razem z konfiguracją dostępu zdalnego i zasadami dla grup uprawnionych do korzystania z RDP.

Przegląd zabezpieczeń powinien zakończyć się testem kontrolowanym: sprawdzeniem logowania hasłem, mechanizmem MFA, wygasłym hasłem, zablokowanym kontem oraz próbą dostępu do zasobu bez wymaganych uprawnień. Należy potwierdzić, że zdarzenia trafiają do właściwych dzienników, mają poprawny czas i zawierają dane umożliwiające odtworzenie przebiegu. W zastosowaniach serwerowych i domenowych diagnostyka może obejmować konfigurację zasad grupy, DNS, synchronizacji czasu, kontrolerów domeny oraz dostawców poświadczeń, bez zmieniania ustawień produkcyjnych bez wcześniejszego planu i kopii konfiguracji.