FSMO-roller i Active Directory: vad de är och hur de fungerar

Active Directory (AD) är en katalogtjänst som skapats av Microsoft, och det kommer som en uppsättning processer och tjänster i de flesta versioner av Windows Server-operativsystem.

du kan tänka dig AD som en databas eller en säker plats som lagrar alla attribut för dina användare som användarnamn, lösenord och mer. Detta centrala arkiv automatiserar många uppgifter som hantering av användardata, tillhandahållande av säkerhet och operationer med andra kataloger.

i de ursprungliga versionerna av AD fanns det många chanser för konflikter. Till exempel, låt oss säga, en domänkontrollant lade till en ny anställd i databasen. Sedan ändringen gjordes i annonsen återspeglades den i hela företaget, och det är bra. Några sekunder senare ville en annan domänkontrollant ta bort register över anställda som inte längre arbetade i företaget. Av misstag raderade den också den här medarbetaren från annonsen.

konflikthanteringssystemet som fanns följde sedan policyn “last writer wins”, så ändringen som gjordes av den andra domänkontrollanten var giltig medan ändringen som gjordes av den första domänkontrollanten kasserades. Det betyder att den nya medarbetaren inte längre var i systemet och inte kunde komma åt systemets resurser, vilket uppenbarligen inte är rätt.

för att förhindra sådana konflikter infördes en single-master-modell. I den här modellen kan endast en domänkontrollant (DC) utföra en viss typ av uppdatering. I ovanstående fall, om bara den första DC var ansvarig för att lägga till och ta bort anställda och den andra DC var ansvarig för säkerheten, skulle en sådan konflikt inte ha inträffat.

detta kom dock med begränsningar också. Vad händer när den första DC går ner? Du kan inte lägga till eller ta bort anställda förrän det kommer upp igen. Ett sådant stort beroende av en enda styrenhet är aldrig bra ur operativ synvinkel.

så Microsoft gick lite längre i efterföljande versioner för att inkludera flera roller för varje DC och för att ge varje DC möjlighet att överföra hela rollen till någon annan DC inom samma företag. Den uppenbara fördelen här är ingen roll är bunden till någon särskild DC, så när man går ner, Du kan automatiskt överföra denna roll till en annan fungerande DC.

eftersom en sådan modell erbjuder mycket flexibilitet kallas den Flexible Single Master Operation (FSMO).

effektivt är FSMO en multimaster-modell som tilldelar tydliga roller och ansvar till varje DC och samtidigt ger flexibilitet att överföra roller om det behövs.

FSMO roller

FSMO är i stort sett uppdelad i fem roller och de är:

• Schema master
• Domain naming master
• RID master
• PDC emulator
• Infrastructure master

av dessa är de två första FSMO-rollerna tillgängliga på skogsnivå medan de återstående tre är nödvändiga för varje domän.

Fjärrtillägg

Låt oss nu titta på varje FSMO-roll på djupet.

Schemamaster

Schemamaster, som namnet antyder, har en läs-och skrivkopia av annonsens hela schema. Om du undrar vad ett schema är, är det alla attribut som är associerade med ett användarobjekt och innehåller lösenord, Roll, beteckning och anställds-ID, för att nämna några.

så, om du vill ändra anställd ID, måste du göra det i denna DC. Som standard är den första styrenheten du installerar i din skog schemamästaren.

Domain naming master

Domain naming master ansvarar för att verifiera domäner, så det finns bara en för varje skog. Det betyder att om du skapar en helt ny domän i en befintlig skog, säkerställer den här kontrollen att en sådan domän inte redan finns. Om din domännamnschef är nere av någon anledning kan du inte skapa en ny domän.

eftersom du inte skapar domäner ofta föredrar vissa företag att ha schema master och domain naming master inom samma controller.

RID master

varje gång du skapar en säkerhetsprincip, vare sig det är ett användarkonto, gruppkonto eller ett huvudkonto, vill du lägga till åtkomstbehörigheter till det. Men du kan inte göra det baserat på namnet på en användare eller grupp eftersom det kan ändras när som helst.

låt oss säga att du hade Andy med en viss roll, och han lämnade företaget. Så du stängde Andys konto och tog istället in Tim. Nu måste du gå och ersätta Andy med Tim i säkerhetsåtkomstlistorna för varje resurs.

Detta är inte praktiskt, eftersom det är tidskrävande och felaktigt.

det är därför du associerar varje säkerhetsprincip med något som kallas ett säkerhets-ID eller SID. På så sätt, även om Andy ändras till Tim, kommer SID att förbli densamma, så du måste bara göra en förändring.

detta SID har ett specifikt mönster för att säkerställa att varje SID i systemet är unikt. Det börjar alltid med bokstaven “S” följt av versionen (börjar med 1) och ett identifieringsmyndighetsvärde. Detta följs av domänen eller det lokala datornamnet som är vanligt för alla Sid: er som finns inom samma domän. Slutligen följs domännamnet av vad som kallas ett relativt ID eller RID.

i huvudsak är RID det värde som säkerställer unikhet mellan olika objekt i active directory.

en SID kommer att se ut så här: S-1-5-32365098609486930-1029. Här är 1029 RID som gör en SID unik medan den långa serien av siffror är ditt domännamn.

men det kan också leda till konflikter. Låt oss säga att vi skapar två användarkonton samtidigt. Detta kan orsaka konflikter eftersom det finns en möjlighet för båda dessa objekt att ha samma SID.

för att undvika denna konflikt tilldelar RID-mästaren block på 500 till varje domänkontrollant. På så sätt får DC1 RIDs från 1 till 500, DC2 får RIDs från 501 till 1000, och så vidare. När en domänkontrollant tar slut på RIDs kontaktar den RID-mästaren och i sin tur tilldelar denna RID-mästare ett annat block på 500.

så, RID master är ansvarig för att behandla rid pool förfrågningar från DCs inom en enda domän för att säkerställa att varje SID är unik.

PDC emulator

PDC står för primär domänkontrollant och det kommer från en tid då det bara fanns en domänkontrollant som hade en läs-och skrivkopia av schemat. De återstående domänkontrollerna var en säkerhetskopia för denna PDC. Så om du vill ändra ett lösenord måste du gå till PDC.

idag finns det inga fler PDC. Men några av dess roller som tidssynkronisering och lösenordshantering tas över av en domänkontrollant som heter PDC emulator.

Låt oss först titta på lösenordshanteringen.

låt oss säga att jag går till en domänkontrollant och återställer mitt lösenord eftersom det har gått ut. Sedan loggar jag in på en annan maskin för en annan webbplats och låt oss säga att den kontaktar en annan domänkontrollant för autentisering. Det finns en chans att min inloggning misslyckas eftersom den första domänkontrollanten kanske inte har replikerat mitt lösenordsbyte till andra kontroller.

en PDC-emulator undviker dessa förvirringar genom att vara styrenheten för återställning av lösenord. Så, min klient kommer att kontakta PDC-emulatorn när en inloggning misslyckas, för att kontrollera om det var en lösenordsändring. Dessutom behandlas alla kontolåsningar på grund av fel lösenord på denna PDC-emulator.

annat än lösenordshantering, PDC emulator synkroniserar tiden i ett företagssystem. Detta är en viktig funktion eftersom ANNONSAUTENTISERING använder ett protokoll som heter kerberos för säkerhet. Detta protokolls huvuduppgift är att se till att datapaket inte tas bort från nätverket eller manipuleras medan det överförs.

så, när det finns en skillnad på fem minuter eller mer mellan en serverklocka och ditt system under autentiseringsprocessen, tror kerberos att detta är en attack och kommer inte att autentisera dig.

bra, men vad är rollen som en PDC-emulator här?

Tja, ditt lokala system synkroniserar sin tid med domänkontrollanten, och domänkontrollanten synkroniserar i sin tur sin tid med PDC-emulatorn. På så sätt är PDC-emulatorn huvudklockan för alla domänkontrollanter i din domän.

när den här kontrollen är nere, går din säkerhet ner några hack och gör lösenord sårbara för attacker.

Infrastrukturmästare

kärnfunktionen i en infrastrukturmästare är att referera till alla lokala användare och referenser inom en domän. Den här styrenheten förstår domänens övergripande infrastruktur inklusive vilka objekt som finns.

det ansvarar för att uppdatera objektreferenser lokalt och säkerställer också att det är uppdaterat i kopior av andra domäner. Den hanterar denna uppdateringsprocess genom en unik identifierare, eventuellt en SID.

Infrastructure master liknar ett annat annonsverktyg som heter Global Catalog (GC). Denna GC är som ett index som vet var allt är, inuti en active directory. Infrastrukturmästaren är å andra sidan en mindre version av GC, eftersom den är begränsad inom en enda domän.

nu, Varför är det viktigt att veta om GC här? Eftersom GC och infrastructure master inte ska placeras i samma domänkontrollant. Om du råkar göra det kommer infrastrukturmästaren att sluta fungera eftersom GC får företräde.

i allmänhet, om du bara har en domänkontrollant, spelar det ingen roll så mycket. Men om du har en stor skog med flera domänkontrollanter kommer närvaron av både GC och infrastructure master att orsaka problem.

Låt oss ta en situation här. Vi har flera domäner som ser upp till en GC-server. Inuti en domän gör vi en ändring av gruppmedlemskapet och infrastrukturmästaren vet om denna förändring. Men det uppdaterar inte GC-servern eftersom ändringen inte gjordes till en universell grupp. Det betyder att det finns en chans för din GC-och infrastrukturmästare att vara synkroniserad, vilket i sin tur kan orsaka autentiseringsproblem. Därför se till att du har antingen en infrastrukturmästare eller en GC för varje domän, men inte båda.

sammanfattning

som du kan se. FSMO-roller förhindrar konflikter i en active directory och ger dig samtidigt flexibiliteten att hantera olika operationer i active directory. De kan i stort sett delas in i fem roller, varav de två första är för hela skogen medan de återstående tre avser en viss domän.

har du implementerat FSMO-roller i din organisation? Vänligen dela dina tankar med oss.

Fotokredit: Wikimedia