FSMO Roles – praktyczne scenariusze zarządzania rolami Active Directory

Active Directory jest zaprojektowane jako usługa rozproszona. W typowym środowisku firmowym nie istnieje jeden centralny serwer, który wykonuje wszystkie operacje. Kontrolery domeny współpracują ze sobą, replikują dane i mogą obsługiwać logowania użytkowników.

Jednak nie wszystkie operacje można wykonywać jednocześnie na wielu kontrolerach domeny.

Niektóre zadania wymagają jednego właściciela.

Przykład:

Jeżeli dwa kontrolery domeny jednocześnie próbowałyby nadać ten sam identyfikator nowemu obiektowi albo zmienić strukturę całej domeny, mogłoby dojść do konfliktów.

Microsoft rozwiązał ten problem poprzez mechanizm:

FSMO – Flexible Single Master Operations.

FSMO to pięć specjalnych ról Active Directory przypisanych do kontrolerów domeny, które odpowiadają za konkretne operacje wymagające jednego właściciela.

Dlaczego istnieją role FSMO?

Active Directory wykorzystuje model wielomasterowej replikacji.

Oznacza to, że:

• każdy kontroler domeny może przyjmować zmiany,
• zmiany są następnie replikowane.

Przykład:

Administrator tworzy użytkownika:

jan.kowalski

Zmiana może zostać wykonana na dowolnym kontrolerze domeny.

Jednak niektóre operacje są zbyt krytyczne, aby wykonywać je równolegle.

Przykłady:

• zmiana schematu Active Directory,
• zarządzanie czasem domeny,
• przydzielanie identyfikatorów obiektów.

Dlatego powstały role FSMO.

Pięć ról FSMO w Active Directory

Role dzielą się na:

Role całego lasu (Forest-wide)

Dotyczą całej struktury Active Directory.

• Schema Master
• Domain Naming Master

Role domenowe (Domain-wide)

Dotyczą konkretnej domeny.

• RID Master
• PDC Emulator
• Infrastructure Master

1. Schema Master – właściciel schematu Active Directory

Zakres:

Cały las Active Directory.

Schema Master odpowiada za zmiany schematu.

Schemat określa:

• jakie typy obiektów istnieją,
• jakie posiadają atrybuty.

Przykład:

Standardowo użytkownik posiada:

• nazwę,
• login,
• adres e-mail.

Instalacja nowej aplikacji może dodać:

• nowe klasy obiektów,
• nowe atrybuty.

Przykład:

Instalacja:

• Exchange Server,
• systemu ERP,
• rozwiązania IAM.

Podczas instalacji wykonywana jest modyfikacja schematu.

Tylko Schema Master może zaakceptować taką zmianę.

Praktyczny scenariusz – instalacja Exchange

Administrator uruchamia:

Setup.exe /PrepareSchema

Exchange próbuje rozszerzyć Active Directory.

Proces:

1. kontakt z Schema Master,
2. dodanie nowych klas i atrybutów,
3. replikacja zmian do pozostałych DC.

Jeżeli Schema Master jest niedostępny:

• instalacja może się zatrzymać,
• pojawią się błędy uprawnień.

2. Domain Naming Master – zarządzanie nazwami domen

Zakres:

Cały las.

Odpowiada za:

• dodawanie nowych domen,
• usuwanie domen,
• dodawanie partycji aplikacyjnych.

Przykład:

Firma posiada:

firma.local

i chce dodać:

eu.firma.local

Operacja wymaga Domain Naming Master.

Praktyczny scenariusz – dodanie nowej domeny

Proces:

1. administrator uruchamia instalację nowej domeny,
2. sprawdzany jest Domain Naming Master,
3. tworzona jest nowa domena,
4. informacje są replikowane.

Bez tej roli operacja nie powiedzie się.

3. RID Master – przydzielanie identyfikatorów użytkowników

To jedna z najważniejszych ról podczas codziennej pracy domeny.

Każdy obiekt bezpieczeństwa Active Directory otrzymuje unikalny identyfikator:

SID (Security Identifier).

Przykład:

S-1-5-21-123456789-987654321-111111111-1105

Ostatnia część:

1105

to RID.

Dlaczego potrzebny jest RID Master?

Każdy kontroler domeny tworzący użytkowników potrzebuje puli RID.

Przykład:

DC01 otrzymuje:

RID 1000-1499

DC02:

RID 1500-1999

Dzięki temu dwa kontrolery nie stworzą dwóch użytkowników z identycznym SID.

Praktyczny scenariusz – brak RID Master

Normalna praca:

• użytkownicy nadal mogą się logować,
• istniejące konta działają.

Problem pojawia się przy tworzeniu nowych obiektów.

Po wyczerpaniu puli RID:

• nie można tworzyć użytkowników,
• nie można tworzyć grup,
• pojawiają się błędy Active Directory.

4. PDC Emulator – najważniejsza rola FSMO

W praktyce jest to najczęściej najważniejsza rola.

PDC Emulator odpowiada między innymi za:

• synchronizację czasu,
• obsługę zmian haseł,
• blokady kont,
• kompatybilność ze starszymi systemami.

PDC Emulator i czas w domenie

Kerberos wymaga synchronizacji czasu.

Jeżeli różnica przekroczy zwykle kilka minut:

• logowanie może się nie udać,
• bilety Kerberos zostaną odrzucone.

Hierarchia czasu:

Internet NTP
      |
PDC Emulator
      |
Pozostałe DC
      |
Komputery domenowe

Praktyczny scenariusz – użytkownik zmienia hasło

Załóżmy:

Użytkownik zmienia hasło na:

NoweHaslo123!

na DC01.

Chwilę później loguje się przez VPN, który korzysta z DC02.

Problem:

replikacja może jeszcze nie dotrzeć.

PDC Emulator pomaga rozwiązać ten problem.

Jeżeli DC02 nie zna nowego hasła, pyta PDC Emulator.

Dzięki temu użytkownik nie musi czekać na pełną replikację.

PDC Emulator i blokada konta

Przykład:

Atakujący próbuje zgadywać hasło:

admin
password1
password2
password3

Po przekroczeniu limitu:

Account Lockout Threshold

PDC Emulator pomaga skoordynować stan konta.

5. Infrastructure Master – aktualizacja odwołań między domenami

Ta rola jest często najmniej rozumiana.

Infrastructure Master odpowiada za aktualizację referencji do obiektów z innych domen.

Przykład:

Las:

firma.local

Domena:

eu.firma.local

Użytkownik z jednej domeny jest członkiem grupy w drugiej.

Jeżeli zmieni się nazwa obiektu, Infrastructure Master aktualizuje informacje.

Praktyczny scenariusz – środowisko wielodomenowe

Firma posiada:

firma.pl
 ├── polska.firma.pl
 └── niemcy.firma.pl

Użytkownik:

Hans

jest członkiem grupy:

Administrators_PL

Zmiana nazwy lub usunięcie obiektu wymaga aktualizacji referencji.

Gdzie powinny znajdować się role FSMO?

Nie istnieje jedna konfiguracja dla wszystkich firm.

Mała firma

Przykład:

2 kontrolery domeny:

DC01
DC02

Często:

DC01:
Schema Master
Domain Naming Master
RID Master
PDC Emulator
Infrastructure Master

DC02:

brak ról.

Średnia firma

Często rozdziela się role:

DC01:
Schema Master
Domain Naming Master

DC02:
RID Master
PDC Emulator
Infrastructure Master

Duże środowisko

Role mogą być rozłożone według:

• lokalizacji,
• obciążenia,
• dostępności.

Jak sprawdzić właścicieli FSMO?

Polecenie:

netdom query fsmo

Przykład wyniku:

Schema master:
DC01.firma.local

Domain naming master:
DC01.firma.local

RID master:
DC02.firma.local

PDC:
DC02.firma.local

Infrastructure master:
DC02.firma.local

Zarządzanie FSMO przez PowerShell

Sprawdzenie:

Get-ADForest | Format-List SchemaMaster,DomainNamingMaster

oraz:

Get-ADDomain | Format-List RIDMaster,PDCEmulator,InfrastructureMaster

Przenoszenie ról FSMO

Normalna migracja:

Move-ADDirectoryServerOperationMasterRole

Przykład:

Move-ADDirectoryServerOperationMasterRole `
-Identity DC02 `
-OperationMasterRole PDCEmulator

Stosuje się przy:

• wymianie kontrolera domeny,
• migracji sprzętu,
• zmianach infrastruktury.

Seizing FSMO – wymuszenie przejęcia roli

Czasami kontroler domeny umiera.

Przykład:

Stary DC:

DC01

ulega awarii sprzętowej.

Role nadal wskazują na niego.

Administrator wykonuje:

FSMO seizure

czyli wymuszone przejęcie.

Przykład:

Move-ADDirectoryServerOperationMasterRole `
-Identity DC02 `
-OperationMasterRole PDCEmulator `
-Force

Uwaga po przejęciu FSMO

Jeżeli wykonano seizure:

stary kontroler domeny nie powinien wrócić do sieci bez ponownej konfiguracji.

Dlaczego?

Ponieważ nadal uważa się za właściciela roli.

Może dojść do:

• konfliktów,
• niespójności,
• problemów z replikacją.

FSMO a bezpieczeństwo Active Directory

Role FSMO są atrakcyjnym celem dla atakujących.

Szczególnie:

PDC Emulator

ponieważ wpływa na:

• logowanie,
• czas,
• hasła.

Schema Master

ponieważ pozwala zmieniać strukturę AD.

Dlatego:

• kontrolery domeny powinny być chronione,
• dostęp administracyjny powinien być ograniczony,
• konta uprzywilejowane powinny być objęte tieringiem.

Najczęstsze błędy administratorów

Jeden stary kontroler trzyma wszystkie role

Problem:

awaria = problemy administracyjne.

Brak dokumentacji

Administratorzy często nie wiedzą:

• gdzie są role,
• który DC jest właścicielem.

Ignorowanie PDC Emulator

Problemy z czasem i logowaniem często zaczynają się właśnie tutaj.

Niepoprawne usunięcie kontrolera domeny

Może pozostawić:

• stare rekordy DNS,
• stare role FSMO,
• błędy replikacji.

Podsumowanie

FSMO Roles są mechanizmem, który pozwala Active Directory zachować spójność w środowisku wielokontrolerowym.

Pięć ról odpowiada za różne zadania:

Najważniejsza rzecz do zapamiętania:

Active Directory jest usługą rozproszoną, ale niektóre decyzje muszą mieć jednego właściciela. Tym właśnie są role FSMO.

Dobrze zaprojektowane rozmieszczenie FSMO, regularny monitoring i poprawna procedura odzyskiwania ról są jednym z fundamentów stabilnej infrastruktury Windows Server.

Polecane wpisy

Wsparcie dla Windows Server 2016/2019/2022: Najlepsze praktyki zarządzania i optymalizacji

🖥️ Wsparcie dla Windows Server 2016/2019/2022: Najlepsze praktyki zarządzania i optymalizacji 🚀 Wprowadzenie Windows Server to fundament dla większości korporacyjnych Czytaj dalej

Reagowanie na incydenty bezpieczeństwa związane z zaszyfrowanymi danymi na Windows Server

🚨 Reagowanie na incydenty bezpieczeństwa związane z zaszyfrowanymi danymi na Windows Server Windows Server jest jednym z najczęściej wykorzystywanych systemów Czytaj dalej