Microsoft AZ-801: Bezpieczeństwo Active Directory Domain Services — Przewodnik do nauki

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Część Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Usługi Active Directory Domain Services (AD DS) stanowią podstawę tożsamości i dostępu w sieciach Windows. Zabezpieczanie AD DS oznacza kontrolowanie sposobu tworzenia, przechowywania i używania poświadczeń; ograniczanie miejsc, w których mogą uwierzytelniać się tożsamości uprzywilejowane; wzmacnianie protokołów uwierzytelniania; inspekcję działań o wysokim znaczeniu; oraz zapewnienie niezawodnego odzyskiwania. Ta sekcja omawia szczegółowe zasady haseł i kont, ochronę tożsamości uprzywilejowanych, wzmacnianie i delegowanie uwierzytelniania, inspekcję i listy SACL, Kosz, podpisywanie LDAP i powiązanie kanału, zachowanie AdminSDHolder, kopie zapasowe i autorytatywne przywracanie, w tym odzyskiwanie SYSVOL, oraz model warstwowy AD.

Zasady dotyczące poświadczeń i kontrola tożsamości uprzywilejowanych

Szczegółowe zasady haseł (PSO) pozwalają na stosowanie wielu zasad haseł/blokady kont w jednej domenie bez potrzeby tworzenia dodatkowych domen. Zasady PSO są obiektami msDS-PasswordSettings przechowywanymi w

undefined

(kontenerze msDS-PasswordSettingsContainer). Zasada PSO jest stosowana do użytkowników i globalnych grup zabezpieczeń poprzez atrybut msDS-PSOAppliesTo. Gdy do użytkownika ma zastosowanie wiele zasad PSO (bezpośrednio lub przez grupy), wynikową zasadą PSO jest ta z najniższą wartością msDS-PasswordSettingsPrecedence; w przypadku remisu wygrywa zasada PSO z najniższym identyfikatorem GUID. Efektywna zasada PSO dla użytkownika jest zapisywana w atrybucie msDS-ResultantPSO. Projektuj zasady PSO tak, aby niższe numery pierwszeństwa odpowiadały najbardziej restrykcyjnym zasadom, które mają być stosowane, i weryfikuj obowiązujące zasady, odczytując atrybut msDS-ResultantPSO.

Grupa zabezpieczeń Protected Users wzmacnia ochronę kont o wysokim znaczeniu, eliminując przestarzałe i ryzykowne mechanizmy uwierzytelniania. Członkowie:

Nie mogą używać NTLM, Digest ani CredSSP
Mają zablokowane użycie RC4 i DES dla Kerberos
Nie mogą być delegowani przez Kerberos (w sposób nieograniczony lub ograniczony)
Otrzymują nieodnawialne bilety TGT o stałym, krótkim czasie życia (domyślnie 4 godziny)
Nie przechowują w pamięci podręcznej stacji roboczej poświadczeń w postaci zwykłego tekstu ani sekretów długoterminowych (zapobiega to użyciu WDigest jako mechanizmu zapasowego i pozostawaniu materiału poświadczeń w LSASS) Używaj tej grupy dla tożsamości uprzywilejowanych obsługiwanych przez ludzi oraz właścicieli usług wysokiego ryzyka po zweryfikowaniu zgodności aplikacji. Kontrolery domeny muszą działać pod kontrolą systemu Windows Server 2012 R2 lub nowszego, aby wymusić te zabezpieczenia.

Zasady uwierzytelniania i silosy zasad uwierzytelniania ograniczają, gdzie i jak konta mogą się uwierzytelniać. Zasada uwierzytelniania może ustawiać ograniczenia Kerberos dla poszczególnych kont, takie jak czas życia biletu TGT i dozwolone urządzenia (według SPN/FQDN hosta). Silos zasad uwierzytelniania grupuje użytkowników, komputery i konta usług, tak aby tylko dozwolone kombinacje mogły uwierzytelniać się przy użyciu protokołu Kerberos ograniczonego przez tę zasadę. Wymusza to kontrole typu „stacja do administratora”: na przykład administratorzy warstwy 0 (Tier 0) mogą logować się tylko na kontrolery domeny i wyznaczone stacje robocze z dostępem uprzywilejowanym (PAW), a nie na serwery członkowskie czy stacje robocze. Połącz z grupą Protected Users, aby uzyskać maksymalny efekt. Te funkcje wymagają kontrolerów domeny z systemem Windows Server 2012 R2 oraz wzmocnienia KDC (KDC armoring).

AdminSDHolder i SDProp chronią listy ACL tożsamości uprzywilejowanych. Członkowie wbudowanych grup administracyjnych (na przykład Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators i inne) są „chronieni”. Proces SDProp uruchamia się co godzinę na emulatorze PDC, kopiując listę ACL z obiektu CN=AdminSDHolder,CN=System do obiektów chronionych i wyłącza na nich dziedziczenie list ACL (AdminCount=1). Aby przyznać uprawnienia działu pomocy technicznej do obiektów chronionych, zmień listę ACL na obiekcie AdminSDHolder — nigdy bezpośrednio na poszczególnych obiektach chronionych — w przeciwnym razie zmiana zostanie cofnięta. Gdy konto zostanie usunięte ze wszystkich grup chronionych, ponownie włącz dziedziczenie list ACL i wyzeruj atrybut AdminCount, aby listy ACL na poziomie jednostek organizacyjnych (OU) i obiekty GPO znów były stosowane.

Zastosuj model warstwowy AD, aby zminimalizować ryzyko narażenia poświadczeń. Warstwa 0 (Tier 0) zawiera kontrolery domeny, systemy tożsamości (PKI, federacja, PAM) oraz konta administracyjne, które nimi zarządzają. Warstwa 1 (Tier 1) zawiera obciążenia serwerowe i ich administratorów. Warstwa 2 (Tier 2) zawiera stacje robocze i ich administratorów. Zapobiegaj logowaniu między warstwami, używaj stacji PAW do administracji warstwami 0 i 1 oraz izoluj poświadczenia za pomocą funkcji takich jak Protected Users, silosy uwierzytelniania, Remote Credential Guard, Just-Enough Administration (JEA) oraz Windows LAPS do rotacji haseł administratora lokalnego.

Wzmacnianie uwierzytelniania i delegowanie

Podpisywanie LDAP i channel binding chronią przed atakami typu relay i man‑in‑the‑middle. Skonfiguruj kontrolery domeny, aby wymagały podpisywania za pomocą zasad grupy (Group Policy): Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\„Domain controller: LDAP server signing requirements” = Require signing. Wymagaj podpisywania przez klienta tam, gdzie to możliwe: „Network security: LDAP client signing requirements” = Require signing. Dla LDAPS włącz channel binding na kontrolerach domeny, ustawiając wartość LDAPEnforceChannelBinding w kluczu HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters na 1 (Enabled, zalecane) lub 2 (Always). Zidentyfikuj starsze urządzenia i aplikacje; włączenie podpisywania lub channel binding może zakłócić działanie anonimowych/prostych powiązań (binds) lub starych stosów LDAP. Monitoruj dziennik zdarzeń Directory Service: 2886 (podpisywanie nie jest wymagane), 2887 (podsumowanie niepodpisanych prostych powiązań), 2888 (podpisywanie jest nadal wyłączone), 2889 (adresy IP klientów wykonujących niepodpisane proste powiązania, gdy włączone jest logowanie diagnostyczne). Wdrażaj zmiany etapami, najpierw w trybie „Warn” (channel binding=1), zanim wymusisz tryb „Always” (2).

Delegowanie Kerberos kontroluje, w jaki sposób usługi działają w imieniu użytkowników:

Delegowanie nieograniczone („Trust this computer for delegation to any service (Kerberos only)”) pozwala usłudze na otrzymanie przekazywalnego biletu TGT i podszywanie się pod użytkowników w celu uzyskania dostępu do dowolnej usługi. Jest to wysoce ryzykowne; należy go unikać na rzecz modeli ograniczonych.
Delegowanie ograniczone (KCD) („Trust this computer for delegation to specified services only”) ogranicza, dokąd usługa może delegować uprawnienia (lista docelowych nazw SPN). Przy użyciu opcji „Use any authentication protocol” usługa może wykorzystać przejście protokołu (S4U2Self), a następnie S4U2Proxy, aby uzyskać dostęp do określonych usług backendowych.
Delegowanie ograniczone oparte na zasobach (RBCD) przenosi kontrolę na zasób poprzez ustawienie atrybutu msDS-AllowedToActOnBehalfOfOtherIdentity na docelowym koncie usługi. Właściciel zasobu określa, które podmioty front-endowe mogą delegować do niego uprawnienia, co upraszcza scenariusze międzydomenowe i minimalizuje powierzchnię ataku. Preferuj RBCD w nowoczesnych projektach; przeprowadzaj audyty i okresowo weryfikuj ustawienia SPN i delegowania.

Audyt i odporność

Audyt AD DS musi być przemyślany i szczegółowy. Użyj zaawansowanej konfiguracji zasad inspekcji (Advanced Audit Policy Configuration), aby włączyć podkategorie zamiast starszych kategorii, i ustaw opcję „Audit: Force audit policy subcategory settings to override audit policy category settings”, aby zapewnić spójność. Zalecane podkategorie to Account Management, Logon/Logoff (Logon, Logoff, Special Logon), Account Logon (Kerberos Authentication Service/Service Ticket Operations) oraz Directory Service Changes/Access. Kluczowe identyfikatory zdarzeń:

4720 (Utworzono konto użytkownika) z kategorii Account Management
4740 (Konto użytkownika zostało zablokowane) z kategorii Account Management
4625 (Logowanie na konto nie powiodło się) z kategorii Logon/Logoff
4648 (Podjęto próbę logowania przy użyciu jawnych poświadczeń) z kategorii Logon/Logoff Uzupełnij audyt o Directory Service Changes, aby przechwytywać wartości kto/co/stara/nowa dla krytycznych atrybutów (zdarzenia 5136/5137/5139). Aby audytować określone zmiany (np. członkostwo w grupach, SPN, ACL), skonfiguruj listy SACL na docelowych obiektach lub jednostkach organizacyjnych (włącz Advanced Features w ADUC, otwórz obiekt Security > Advanced > Auditing). Dodaj wpisy audytujące „Write all properties” lub określone właściwości (member, servicePrincipalName) oraz, w razie potrzeby, „Modify permissions/owner”. Sprawdź, czy logi docierają do centralnego systemu SIEM i czy logi zabezpieczeń na kontrolerach domeny mają wystarczający okres retencji.

Koszt AD DS chroni przed przypadkowym usunięciem, zachowując wszystkie atrybuty i linki zwrotne (backlinks) usuniętych obiektów. Włącz go raz na las (operacja nieodwracalna) za pomocą ADAC lub PowerShell (Enable-ADOptionalFeature -Identity ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target <forest>). Po włączeniu usunięty obiekt pozostaje w stanie „usuniętego obiektu” (deleted object) przez czas określony w atrybucie msDS-DeletedObjectLifetime (jeśli nie jest ustawiony, domyślnie przyjmuje wartość tombstoneLifetime), podczas którego można go w pełni przywrócić z nienaruszonymi atrybutami. Po tym czasie staje się obiektem poddanym recyklingowi (recycled object) i nie można go już przywrócić z atrybutami, a później jest usuwany przez proces garbage collection. W nowoczesnych lasach domyślna wartość tombstoneLifetime wynosi zazwyczaj 180 dni; w starszych lasach może to być 60 dni. Przywracaj za pomocą ADAC, LDP lub PowerShell (Restore-ADObject) i preferuj autorytatywne odzyskiwanie członkostwa w grupach za pomocą Kosza zamiast ręcznego ponownego dodawania, aby uniknąć zjawiska „privilege drift” (dryfowania uprawnień).

Kopie zapasowe i przywracanie autorytatywne to ostatnia linia obrony. Wykonuj częste kopie zapasowe stanu systemu (System State) każdego kontrolera domeny za pomocą Windows Server Backup lub wbadmin (wbadmin start systemstatebackup). Aby cofnąć zmiany na poziomie obiektów, wykraczające poza możliwości Kosza, wykonaj nieautorytatywne przywracanie stanu systemu, a następnie użyj ntdsutil, aby oznaczyć określone obiekty lub jednostki organizacyjne jako autorytatywne (zwiększając ich numer wersji, aby replikacja ponownie je zastosowała). Zrozum różnicę: przywracanie nieautorytatywne przywraca kontroler domeny, a następnie stosuje bieżącą replikację; przywracanie autorytatywne oznacza obiekt tak, aby przywrócona wersja nadpisała nowsze repliki. Dla woluminu SYSVOL używającego replikacji DFS (DFSR) wykonaj odzyskiwanie nieautorytatywne lub autorytatywne:

Nieautorytatywne: Zatrzymaj usługę DFSR, ustaw subskrypcję SYSVOL danego członka jako nieautorytatywną (msDFSR-Options=0), uruchom usługę DFSR, aby mogła ona ponownie zsynchronizować dane od partnera nadrzędnego.
Autorytatywne: Na wybranym, sprawnym kontrolerze domeny ustaw subskrypcję SYSVOL jako autorytatywną (msDFSR-Options=1), uruchom usługę DFSR, a następnie wymuś ponowną synchronizację u partnerów (DFSRDIAG PollAD). Sprawdź stan za pomocą dfsrdiag backlog i dzienników zdarzeń. W przypadku starszej technologii FRS (nieobsługiwanej) przeprowadź migrację do DFSR i unikaj procedur z użyciem BurFlags.

Podsumowanie: Operacje, priorytety wzmacniania zabezpieczeń i dostęp warstwowy

Nadaj priorytet najpierw warstwie Tier 0: wymuś podpisywanie LDAP/powiązanie kanału (channel binding), usuń nieograniczone delegowanie (unconstrained delegation), przejdź na KCD/RBCD, umieść uprzywilejowane tożsamości w grupie Protected Users i dołącz zasady/silosy uwierzytelniania, aby ograniczyć punkty końcowe logowania, oraz wymagaj stacji PAW dla administratorów warstw Tier 0/1. Ustanów obiekty PSO dla kont uprzywilejowanych z rygorystyczną blokadą i rotacją. Włącz zaawansowane inspekcje (auditing) z listami SACL na kontenerach warstwy Tier 0. Zapewnij codzienne kopie zapasowe stanu systemu (System State) kontrolerów domeny i udokumentowane procedury (runbooks) autorytatywnego przywracania i odzyskiwania SYSVOL. W warstwach Tier 1/2 blokuj logowanie administratorów do niższych warstw, wyeliminuj ponowne używanie tych samych haseł administratorów lokalnych za pomocą Windows LAPS i monitoruj skoki zdarzeń 4625/4740 oraz niewłaściwe użycie 4648 pod kątem prób ruchu bocznego (lateral movement).

Praktyczny scenariusz problemowy

Firma Adobe musi szybko zabezpieczyć lokalny las AD DS po przejęciu spółki zależnej, której aplikacje biznesowe opierają się na przestarzałych protokołach. Cele to zmniejszenie skuteczności ataków typu password spraying, zatrzymanie ataków typu credential relay na kontrolery domeny, ograniczenie logowań uprzywilejowanych do stacji PAW, zmodernizowanie delegowania dla warstwy webowej oraz zapewnienie szybkiego odzyskiwania po przypadkowych usunięciach.

Zdefiniuj obiekty PSO i przypisz je do grup uprzywilejowanych

Utwórz rygorystyczny obiekt PSO (niska wartość pierwszeństwa) w kontenerze msDS-PasswordSettingsContainer z krótkim wiekiem hasła, wysoką złożonością i agresywną blokadą.
Zastosuj za pomocą atrybutu msDS-PSOAppliesTo do grup „Domain Admins”, „Server Admins” i niestandardowej grupy „Tier0‑Privs”. Dlaczego: Szczegółowe obiekty zasad haseł (PSO) dotyczą tylko kont wysokiego ryzyka bez zakłócania całej domeny, a pierwszeństwo gwarantuje, że rygorystyczna zasada zawsze wygrywa.

Wymuś użycie grupy Protected Users i silosów uwierzytelniania

Dodaj ludzkich administratorów warstwy Tier 0 do grupy Protected Users.
Utwórz zasadę uwierzytelniania zezwalającą na logowanie Kerberos tylko z nazw SPN hostów PAW i kontrolerów domeny; połącz konta i stacje PAW w silosie zasad uwierzytelniania. Dlaczego: Grupa Protected Users eliminuje NTLM/RC4 i zapobiega delegowaniu; silosy wymuszają zasadę „tylko ze stacji PAW”, zmniejszając narażenie tokenów i ścieżki kradzieży poświadczeń.

Wzmocnij zabezpieczenia LDAP i monitoruj pod kątem awarii

Ustaw „Kontroler domeny: wymagania dotyczące podpisywania serwera LDAP” na Wymagaj; początkowo skonfiguruj LDAPEnforceChannelBinding=1.
Przeglądaj zdarzenia usługi katalogowej (Directory Service) o numerach 2886–2889, aby zidentyfikować przestarzałe powiązania; napraw aplikacje, a następnie ustaw LDAPEnforceChannelBinding=2. Dlaczego: Podpisywanie i powiązanie kanału (channel binding) eliminują popularne ścieżki ataków typu relay na kontrolery domeny, a etapowe wdrożenie pozwala uniknąć przerw w działaniu.

Zmigruj delegowanie do RBCD dla warstwy webowej

Przekonwertuj serwery WWW front-end z delegowania nieograniczonego na RBCD, dodając ich konta komputerów do atrybutu msDS-AllowedToActOnBehalfOfOtherIdentity konta usługi API back-end.
Usuń przestarzałe flagi „Ufaj temu komputerowi w kwestii delegowania do dowolnej usługi”; precyzyjnie zdefiniuj nazwy SPN usług. Dlaczego: RBCD pozwala zasobowi dyktować, kto może do niego delegować uprawnienia, i ogranicza podszywanie się (impersonation) do zamierzonych celów, zmniejszając możliwości ruchu bocznego.

Włącz zaawansowane inspekcje i listy SACL

Skonfiguruj zaawansowane zasady inspekcji (Advanced Audit Policy) dla zarządzania kontami, logowania/wylogowywania, logowania do konta i zmian w usłudze katalogowej.
Na jednostkach organizacyjnych (OU) warstwy Tier 0 i kluczowych grupach dodaj listy SACL inspekcji zapisu (Write) dla atrybutów member i servicePrincipalName oraz zmian uprawnień/właściciela.
Przesyłaj logi do systemu SIEM; ustaw alerty na anomalie w zdarzeniach 4720, 4740, 4625 i 4648. Dlaczego: Nie możesz bronić tego, czego nie widzisz; te zdarzenia ujawniają tworzenie kont, blokady, nieudane logowania i wzorce jawnego użycia poświadczeń.

Włącz Kosz AD DS i sfinalizuj procedury odzyskiwania

Włącz Kosz na poziomie lasu i udokumentuj przepływy pracy z użyciem Restore-ADObject.
Ustandaryzuj codzienne kopie zapasowe stanu systemu (System State) kontrolerów domeny za pomocą Windows Server Backup, przetestuj autorytatywne przywracanie za pomocą ntdsutil w laboratorium.
Udokumentuj i przećwicz autorytatywne i nieautorytatywne odzyskiwanie woluminu SYSVOL replikowanego przez DFSR. Dlaczego: Szybkie i dokładne odzyskiwanie zniechęca atakujących do destrukcyjnych działań i łagodzi skutki błędów administratorów bez ryzyka pełzania uprawnień (privilege drift).

Wdróż operacyjnie model warstwowy AD

Zdefiniuj zasoby warstw Tier 0/1/2; ogranicz logowania administratorów według warstw za pomocą zasad grupy (Group Policy) i silosów uwierzytelniania.
Wdróż stacje PAW dla warstw Tier 0/1, wymuś użycie Remote Credential Guard i rotuj hasła administratorów lokalnych za pomocą Windows LAPS. Dlaczego: Model warstwowy zapewnia izolację poświadczeń i zatrzymuje eskalację uprawnień przez atakujących między warstwami, dostosowując codzienne operacje do granic bezpieczeństwa.

← Microsoft Sentinel i monitorowanie bezpieczeństwa · Wszystkie domeny · Azure Arc i zarządzanie serwerami hybrydowymi →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →