FSMO-roller I Active Directory: Hva de er og hvordan de fungerer

Active Directory (AD) Er en katalogtjeneste opprettet Av Microsoft, og den kommer som et sett med prosesser og tjenester i De fleste versjoner Av Windows Server-operativsystemer.

DU kan forestille DEG ANNONSE som en database eller et trygt sted som lagrer alle attributtene til brukerne dine, for eksempel brukernavn, passord og mer. Dette sentrale depotet automatiserer mange oppgaver som styring av brukerdata, sikkerhet og samhandling med andre kataloger.

i DE første versjonene av AD var det mange sjanser for konflikter. La oss for eksempel si at en domenekontroller la til en ny ansatt i databasen. Siden endringen ble gjort I ANNONSEN, ble den reflektert i hele bedriften, og det er greit. Noen få sekunder senere ønsket en annen domenekontroller å slette postene til ansatte som ikke lenger jobbet i bedriften. Ved et uhell slettet den denne ansatt fra ANNONSEN også.

konflikthåndteringssystemet som eksisterte, fulgte deretter policyen” last writer wins”, slik at endringen som ble gjort av den andre domenekontrolleren, var gyldig mens endringen som ble gjort av den første domenekontrolleren, ble forkastet. Dette betyr at den nye medarbeider ikke lenger var i systemet og ikke kunne få tilgang til systemets ressurser, noe som åpenbart ikke er riktig.

for å forhindre slike konflikter ble en enkeltmastermodell introdusert. I denne modellen kan bare en domenekontroller (DC) utføre en bestemt type oppdatering. I det ovennevnte tilfellet, hvis bare DEN første DC var ansvarlig for å legge til og fjerne ansatte og den andre DC var ansvarlig for sikkerhet, ville en slik konflikt ikke ha skjedd.

dette kom imidlertid med begrensninger også. Hva skjer når DEN første DC går ned? Du kan ikke legge til eller slette ansatte før den kommer opp igjen. En slik tung avhengighet av en enkelt kontroller er aldri bra fra et operativt synspunkt.

Så microsoft gikk litt lenger i senere versjoner for å inkludere flere roller for HVER DC og å gi HVER DC muligheten til å overføre hele rollen til en annen DC i samme bedrift. Den åpenbare fordelen her er at ingen rolle er bundet til en bestemt DC, så når man går ned, kan du automatisk overføre denne rollen til en annen FUNGERENDE DC.

Siden en slik modell gir mye fleksibilitet, kalles Den Fleksibel Single Master Operation (FSMO).

Effektivt ER FSMO en multimaster modell som tildeler klare roller og ansvar til HVER DC og samtidig, noe som gir fleksibilitet til å overføre roller om nødvendig.

FSMO roller

FSMO er grovt delt inn i fem roller og de er:

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

av disse er DE to FØRSTE fsmo-rollene tilgjengelige på skognivå, mens de resterende tre er nødvendige for hvert domene.

Eksterne Utvidelser

La oss nå se på HVER FSMO rolle i dybden.

Skjemamal

Skjemamal, som navnet antyder, inneholder en lese-skrive-kopi av HELE skjemaet I ANNONSEN. Hvis du lurer på hva et skjema er, er det alle attributter knyttet til et brukerobjekt og inkluderer passord, rolle, betegnelse og ansatt-ID, for å nevne noen.

Så, hvis du vil endre ansatt-ID, må du gjøre det i DENNE DC. Som standard vil den første kontrolleren du installerer i skogen, være skjemamalen.

Domain naming master

Domain naming master er ansvarlig for å verifisere domener, så det er bare en for hver skog. Dette betyr at hvis du oppretter et helt nytt domene i en eksisterende skog, sikrer denne kontrolleren at et slikt domene ikke allerede finnes. Hvis domain naming master er nede av en eller annen grunn, kan du ikke opprette et nytt domene.

siden du ikke oppretter domener ofte, foretrekker noen bedrifter å ha schema master og domain naming master i samme kontroller.

RID master

Hver gang du oppretter et sikkerhetsprinsipp, enten det er en brukerkonto, gruppekonto eller en hovedkonto, vil du legge til tilgangstillatelser til den. Men du kan ikke gjøre det basert på navnet på en bruker eller gruppe fordi det kan endres når som helst.

La oss si At Du hadde Andy med en bestemt rolle, og han forlot selskapet. Så du stengte Andys konto og hentet Tim. Nå må Du gå og erstatte Andy Med Tim i sikkerhetsadgangslistene for hver ressurs.

Dette er ikke praktisk, da det er tidkrevende og utsatt for feil.

dette er grunnen til at du knytter alle sikkerhetsprinsipper til noe som kalles en sikkerhets-ID eller SID. På denne måten, Selv Om Andy endrer Seg Til Tim, VIL SID forbli den samme, så du må bare gjøre en endring.

DENNE SID har et bestemt mønster for å sikre at hvert SID i systemet er unikt. Den starter alltid med bokstaven ” S ” etterfulgt av versjonen (starter med 1) og en identifikatorautoritetsverdi. Dette etterfølges av domenet eller det lokale datamaskinnavnet som er vanlig for Alle SIDs som ligger innenfor samme domene. Til slutt blir domenenavnet etterfulgt av det som kalles en relativ ID eller RID.

I Hovedsak ER RID verdien som sikrer unikhet mellom ulike objekter i active directory.

EN SID vil se slik ut: S-1-5-32365098609486930-1029. Her er 1029 RID som gjør EN SID unik mens den lange serien av tall er domenenavnet ditt.

men dette kan også føre til konflikter. La oss si at vi oppretter to brukerkontoer samtidig. Dette kan føre til konflikt da det er en mulighet for begge disse objektene å ha samme SID.

FOR å unngå denne konflikten tilordner rid-mesteren blokker på 500 til hver domenekontroller. PÅ denne måten FÅR DC1 RIDs fra 1 til 500, DC2 Får RIDs fra 501 til 1000, og så videre. Når en domenekontroller går tom For RIDs, kontakter DEN RID master og i sin tur tilordner DENNE RID master en annen blokk på 500.

SÅ, rid master er ansvarlig for behandling AV RID pool forespørsler fra DCs innenfor et enkelt domene for å sikre at HVER SID er unik.

PDC emulator

PDC står For Primær Domain Controller og DET kommer fra en tid da det var bare en domenekontroller som hadde en lese-skrive kopi av skjemaet. De resterende domenekontrollere var en sikkerhetskopi for DENNE PDC. Så, hvis du vil endre et passord, må du gå til PDC.

I Dag er Det ikke Flere Pdcer. Men noen av sine roller som tidssynkronisering og passordbehandling blir overtatt av en domenekontroller kalt PDC emulator.

La oss se på passordadministrasjonen først.

La oss si at jeg går til en domenekontroller og tilbakestiller passordet mitt fordi det er utløpt. Så logger jeg på en annen maskin for et annet nettsted, og la oss si at den kontakter en annen domenekontroller for godkjenning. Det er en sjanse for at påloggingen min mislykkes fordi den første domenekontrolleren kanskje ikke har replikert passordendringen til andre kontroller.

EN PDC-emulator unngår disse forvirringene ved å være kontrolleren for tilbakestilling av passord. Så, min klient vil kontakte PDC emulator når en pålogging mislykkes, for å sjekke om det var en endring av passord. Også, alle konto lockout på grunn av feil passord behandles på DENNE PDC emulator.

ANNET enn passordbehandling, SYNKRONISERER PDC emulator tiden i et bedriftssystem. DETTE er en viktig funksjonalitet fordi AD-godkjenning bruker en protokoll kalt kerberos for sikkerhet. Denne protokollens hovedoppgave er å sikre at datapakker ikke tas av nettverket eller manipuleres mens det blir overført.

så når det er en forskjell på fem minutter eller mer mellom en serverklokke og systemet ditt under godkjenningsprosessen, mener kerberos at dette er et angrep og ikke vil godkjenne deg.

Fint, men hva er ROLLEN som EN PDC-emulator her?

vel, ditt lokale system synkroniserer sin tid med domenekontrolleren, og domenekontrolleren synkroniserer i sin tur sin tid med PDC-emulatoren. PÅ denne måten ER PDC emulator master klokke for alle domenekontrollere i domenet.

når denne kontrolleren er nede, går sikkerheten ned noen få hakk og gjør passord sårbare for angrep.

Infrastructure master

kjernefunksjonaliteten til en infrastructure master er å referere til alle lokale brukere og referanser innenfor et domene. Denne kontrolleren forstår den generelle infrastrukturen til domenet, inkludert hvilke objekter som er tilstede.

Det er ansvarlig for å oppdatere objektreferanser lokalt og sikrer også at det er oppdatert i kopier av andre domener. Den håndterer denne oppdateringsprosessen gjennom en unik identifikator, muligens EN SID.

Infrastructure master ligner på ET ANNET ANNONSEVERKTØY kalt Global Catalog (Gc). DENNE GC er som en indeks som vet hvor alt er, inne i en active directory. Infrastrukturmesteren er derimot en mindre versjon AV GC, da den er begrenset innenfor et enkelt domene.

Nå, Hvorfor er DET viktig å vite OM GC her? FORDI GC og infrastructure master ikke skal plasseres i samme domenekontroller. Hvis du gjør det, vil infrastrukturmesteren slutte å fungere som GC får forrang.

generelt, hvis du bare har en domenekontroller, vil dette ikke være så mye. Men hvis du har en stor skog med flere domenekontrollere, vil tilstedeværelsen av BÅDE GC og infrastructure master føre til problemer.

La oss ta en situasjon her. Vi har flere domener som ser opp TIL EN gc-server. Innenfor ett domene gjør vi en endring i gruppemedlemskapet, og infrastrukturmesteren vet om denne endringen. MEN det oppdaterer IKKE gc-serveren fordi endringen ikke ble gjort til en universell gruppe. Dette betyr at DET er en sjanse for AT GC-og infrastrukturmesteren er ute av synkronisering, og i sin tur kan dette føre til godkjenningsproblemer. Derfor må du sørge for at du har enten en infrastrukturmester eller EN GC for hvert domene, men ikke begge deler.

Sammendrag

Som du kan se. FSMO-roller forhindrer konflikter i en active directory, og gir deg samtidig fleksibiliteten til å håndtere ulike operasjoner i active directory. De kan grovt deles inn i fem roller, hvorav de to første er for hele skogen, mens de resterende tre tilhører et bestemt domene.

har DU implementert FSMO-roller i organisasjonen din? Vennligst del dine tanker med oss.

fotokreditt: Wikimedia