FSMO-roller i Active Directory: hvad de er, og hvordan de fungerer

Active Directory (AD) er en katalogtjeneste oprettet af Microsoft, og den kommer som et sæt processer og tjenester i de fleste versioner af serveroperativsystemer.

du kan forestille dig AD som en database eller et sikkert sted, der gemmer alle dine brugeres attributter, f.eks. brugernavne, adgangskoder og meget mere. Denne centrale repository automatiserer mange opgaver såsom styring af brugerdata, levering af sikkerhed, og inter-operationer med andre mapper.

i de oprindelige versioner af AD var der mange chancer for konflikter. Lad os for eksempel sige, at en domænecontroller tilføjede en ny medarbejder til databasen. Siden ændringen blev foretaget i annoncen, blev den afspejlet i hele virksomheden, og det er fint. Et par sekunder senere ønskede en anden domænecontroller at slette poster for medarbejdere, der ikke længere arbejdede i virksomheden. Ved et uheld slettede den også denne medarbejder fra annoncen.

konfliktstyringssystemet, der eksisterede, fulgte derefter politikken “sidste forfatter vinder”, så ændringen foretaget af den anden domænecontroller var gyldig, mens ændringen foretaget af den første domænecontroller blev kasseret. Det betyder, at den nye medarbejder ikke længere var i systemet og ikke kunne få adgang til systemets ressourcer, hvilket naturligvis ikke er rigtigt.

for at forhindre sådanne konflikter blev en single-master model introduceret. I denne model kunne kun en domænecontroller (DC) udføre en bestemt type opdatering. I ovenstående tilfælde, hvis kun den første DC var ansvarlig for at tilføje og fjerne medarbejdere, og den anden DC var ansvarlig for sikkerhed, ville en sådan konflikt ikke have fundet sted.

dette kom dog også med begrænsninger. Hvad sker der, når den første DC går ned? Du kan ikke tilføje eller slette medarbejdere, før det kommer op igen. En sådan stor afhængighed af en enkelt controller er aldrig god fra et operationelt synspunkt.

så Microsoft gik lidt længere i efterfølgende versioner for at inkludere flere roller for hver DC og give hver DC mulighed for at overføre hele rollen til enhver anden DC inden for samme virksomhed. Den åbenlyse fordel her er, at ingen rolle er bundet til nogen bestemt DC, så når man går ned, Du kan automatisk overføre denne rolle til en anden fungerende DC.

da en sådan model tilbyder en masse fleksibilitet, kaldes den fleksibel single Master Operation (FSMO).

effektivt er FSMO en multimaster-model, der tildeler klare roller og ansvar til hver DC og på samme tid, hvilket giver fleksibilitet til at overføre roller, hvis det er nødvendigt.

FSMO roller

FSMO er bredt opdelt i fem roller, og de er:

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

ud af disse er de to første FSMO-roller tilgængelige på skovniveau, mens de resterende tre er nødvendige for hvert domæne.

Fjernudvidelser

lad os nu se på hver FSMO-rolle i dybden.

Schema master

Schema master, som navnet antyder, har en læse-skrive kopi af hele din annonces skema. Hvis du spekulerer på, hvad et skema er, er det alle de attributter, der er knyttet til et brugerobjekt og inkluderer adgangskode, rolle, betegnelse og medarbejder-ID for at nævne nogle få.

så hvis du vil ændre medarbejder-ID ‘ et, skal du gøre det i denne DC. Som standard er den første controller, du installerer i din skov, schema master.

Domain naming master

Domain naming master er ansvarlig for at verificere domæner, så der er kun en for hver skov. Dette betyder, at hvis du opretter et helt nyt domæne i en eksisterende skov, sikrer denne controller, at et sådant domæne ikke allerede findes. Hvis din domænenavnemaster er nede af en eller anden grund, kan du ikke oprette et nyt domæne.

da du ikke opretter domæner Ofte, foretrækker nogle virksomheder at have schema master og domain naming master inden for den samme controller.

RID master

hver gang du opretter et sikkerhedsprincip, det være sig en brugerkonto, gruppekonto eller en masterkonto, vil du tilføje adgangstilladelser til det. Men du kan ikke gøre det baseret på navnet på en bruger eller gruppe, fordi det kan ændres når som helst.

lad os sige, at du havde Andy med en bestemt rolle, og han forlod virksomheden. Så du lukkede Andys konto og hentede Tim. Nu skal du gå og erstatte Andy med Tim i sikkerhedsadgangslisterne for hver ressource.

dette er ikke praktisk, da det er tidskrævende og fejlbehæftet.

derfor forbinder du ethvert sikkerhedsprincip med noget, der hedder et Sikkerheds-ID eller SID. På denne måde, selvom Andy skifter til Tim, forbliver SID den samme, så du bliver nødt til at foretage kun en ændring.

denne SID har et specifikt mønster for at sikre, at hver SID i systemet er unik. Det starter altid med bogstavet “S” efterfulgt af versionen (starter med 1) og en identifikatorautoritetsværdi. Dette efterfølges af det domæne eller det lokale computernavn, der er fælles for alle Sid ‘ er, der er placeret inden for det samme domæne. Endelig efterfølges domænenavnet af det, der kaldes et relativt ID eller RID.

i det væsentlige er RID den værdi, der sikrer unikhed mellem forskellige objekter i active directory.

en SID vil se sådan ud: S-1-5-32365098609486930-1029. Her er 1029 RID, der gør en SID unik, mens den lange række tal er dit domænenavn.

men det kan også føre til konflikter. Lad os sige, at vi opretter to brugerkonti på samme tid. Dette kan forårsage konflikt, da der er mulighed for, at begge disse objekter har samme SID.

for at undgå denne konflikt tildeler RID master blokke på 500 til hver domænecontroller. På denne måde får DC1 RIDs fra 1 til 500, DC2 RIDs fra 501 til 1.000, og så videre. Når en domænecontroller løber tør for RIDs, kontakter den RID master og til gengæld tildeler denne RID master en anden blok på 500.

så RID master er ansvarlig for behandling af RID pool anmodninger fra DCs inden for et enkelt domæne for at sikre, at hver SID er unik.

PDC emulator

PDC står for primær domænecontroller, og det kommer fra en tid, hvor der kun var en domænecontroller, der havde en læse-skriv kopi af skemaet. De resterende domænecontrollere var en sikkerhedskopi til denne PDC. Så hvis du ville ændre en adgangskode, skal du gå til PDC.

i dag er der ikke flere PDC ‘ er. Men et par af dets roller som tidssynkronisering og adgangskodestyring overtages af en domænecontroller kaldet PDC emulator.

lad os først se på adgangskodeadministrationen.

lad os sige, at jeg går til en domænecontroller og nulstiller min adgangskode, fordi den er udløbet. Så logger jeg på en anden maskine til et andet sted, og lad os sige, det kontakter en anden domænecontroller til godkendelse. Der er en chance for, at mit login mislykkes, fordi den første domænecontroller muligvis ikke har gentaget min adgangskodeændring til andre controllere.

en PDC-emulator undgår disse forvirringer ved at være controller til nulstilling af adgangskode. Så min klient vil kontakte PDC-emulatoren, når et login mislykkes, for at kontrollere, om der var en adgangskodeændring. Også alle konto lockouts på grund af forkerte adgangskoder behandles på denne PDC emulator.

bortset fra adgangskodestyring synkroniserer PDC emulator tiden i et virksomhedssystem. Dette er en vigtig funktionalitet, fordi ANNONCEAUTENTIFICERING bruger en protokol kaldet kerberos til sikkerhed. Denne protokols hovedopgave er at sikre, at datapakker ikke tages ud af netværket eller manipuleres, mens det bliver transmitteret.

så når der er en forskel på fem minutter eller mere mellem et serverur og dit system under godkendelsesprocessen, mener kerberos, at dette er et angreb og vil ikke godkende dig.

fint, men hvad er rollen som en PDC-emulator her?

nå, dit lokale system synkroniserer sin tid med domænecontrolleren, og domænecontrolleren synkroniserer igen sin tid med PDC-emulatoren. På denne måde er PDC-emulatoren masteruret for alle domænecontrollere i dit domæne.

når denne controller er nede, går din sikkerhed ned et par hak og gør adgangskoder sårbare over for angreb.

Infrastructure master

kernefunktionaliteten i en infrastructure master er at henvise til alle lokale brugere og referencer inden for et domæne. Denne controller forstår den overordnede infrastruktur af domænet, herunder hvilke objekter er til stede det.

det er ansvarligt for opdatering af objektreferencer lokalt og sikrer også, at det er opdateret i kopierne af andre domæner. Den håndterer denne opdateringsproces gennem en unik identifikator, muligvis en SID.

Infrastructure master ligner et andet ANNONCEVÆRKTØJ kaldet Global Catalog (GC). Denne GC er som et indeks, der ved, hvor alt er, inde i en active directory. Infrastrukturmesteren er derimod en mindre version af GC, da den er begrænset inden for et enkelt domæne.

nu, hvorfor er det vigtigt at vide om GC her? Fordi GC og infrastructure master ikke bør placeres i den samme domænecontroller. Hvis du tilfældigvis gør det, stopper infrastrukturmesteren med at arbejde, da GC får forrang.

generelt, hvis du kun har en domænecontroller, betyder det ikke så meget. Men hvis du har en stor skov med flere domænecontrollere, vil tilstedeværelsen af både GC og infrastructure master forårsage problemer.

lad os tage en situation her. Vi har flere domæner, der ser op til en GC-server. Inden for et domæne foretager vi en ændring af gruppemedlemskabet, og infrastrukturmesteren kender til denne ændring. Men det opdaterer ikke GC-serveren, fordi ændringen ikke blev foretaget til en universel gruppe. Dette betyder, at der er en chance for, at din GC-og infrastrukturmester er synkroniseret, og dette kan igen forårsage godkendelsesproblemer. Derfor skal du sørge for, at du enten har en infrastrukturmester eller en GC for hvert domæne, men ikke begge dele.

Resume

som du kan se. FSMO-roller forhindrer konflikter i en active directory og giver dig samtidig fleksibilitet til at håndtere forskellige operationer i active directory. De kan bredt opdeles i fem roller, hvoraf de to første er for hele skoven, mens de resterende tre vedrører et bestemt domæne.

har du implementeret FSMO roller i din organisation? Venligst dele dine tanker med os.

Fotokredit: