Dette indlæg er bragt af Ed Baker, Windows Server-instruktør hos Firebrand Training
Før Windows 2008 skulle brugeren implementere flere filtre for domæner og adgangskoder for at muliggøre, at forskellige grupper af brugere har forskellige krav til adgangskoder eller spærringspolitikker. Dette var både komplekst og dyrt.
I 2008-operativsystemet har Microsoft fundet en løsning på dette. Denne løsning var mildt sagt også kompleks og indviklet. Det virkede som om, løsningen var fundet modvilligt, men den var så svær at implementere, at de fleste af os ikke en gang gad prøve.
Med implementeringen af R2 fulgte en vis fleksibilitet, men med Server 2012 har Microsoft endelig taget konceptet til sig som et dagligt administrationskrav.
Hvad er formålet med detaljerede adgangskoder?
I en stor organisation med mange niveauer af brugere og sikkerhed er det ofte nødvendigt at angive forskellige krav til kompleksiteten af adgangskoder og spærringspolitikker. F.eks. er det ikke sikkert, at kontorassistenten har brug for de samme niveauer som forsknings- og udviklingsafdelingen.
I Windows Server 2012 er løsningen implementeret hele vejen gennem ADAC (Active Directory Administrative Center). ADAC var tilgængelig i Server 2008 R, men blev generelt ignoreret af ”ægte administratorer”. Det er i det væsentlige en GUI front-end til PowerShell Cmdlets – der gør det muligt at oprette, redigere og slette ethvert Active Directory-objekt i databasen ntds.dit.
ADAC er tilbage, og med en mission. Værktøjet er nu det eneste sted, hvor du kan udføre flere vigtige administrative funktioner (bortset fra PowerShell version 3.0, hvor du kan foretage dig stort set alt, der har med serverhåndtering og –administration at gøre).
Hvordan får jeg det til at virke?
For at implementere detaljerede adgangskoder skal du installere Windows Server 2012 domænecontroller, hvor domænets funktionsniveau er angivet til Windows Server 2008 eller derover. Du kan nu udføre denne opgave i ADAC (forudsat, at du ”kører som administrator”).
For at kunne udvikle dine færdigheden inden for dette område er det også en god ide at oprette et antal testgrupper og –brugere, således at de ændringer, du foretager, ikke får indflydelse på dit daglige arbejde. Den bedste måde at teste dette på er i et sandkassemiljø, men hvis dette ikke er muligt, vil brug af testkonti, -grupper og –organisationsenheder forhindre en katastrofe.
I scenariet herunder har jeg konfigureret FGP_User1, FGP_User2, FGP_GP1, FGP_GP2 – du kan anvende de navne, du ønsker. Dette kan udføres for AD-brugere og -computere, i ADAC eller i PowerShell 3.0.
Start nu Server Manager-programmet…
I programmet skal du vælge Tools (Værktøjer) og ADAC. I vinduet ADAC skal du vælge Tree View (trævisning) (der gør det nemmer at se, hvad der er vigtigt) og derefter vælge det domæne, du ønsker at arbejde med. Udvid træet, indtil du kan se System container (Systembeholder), udvid den, og vælg Password Setting Container (beholder til angivelse af adgangskode).
Højreklik, og vælg: New à Password Settings (nye indstillinger for adgangskode).
Vinduet Create Password Settings (angiv indstillinger for adgangskode) åbnes. Der er flere obligatoriske valg, hvoraf de fleste er valgt på forhånd – du skal angive navn og prioriteret rækkefølge. (Bemærk: jo lavere tal for prioriteret rækkefølge, jo højere prioritet!)
Her kan du ændre alle indstillingerne for dette adgangskodeobjekt (længde, spærring osv. – se billede herunder).
Den bedste måde er at indtaste en beskrivelse af politikken og derefter klikke på Add (tilføj) i området Directly Applies To (finder direkte anvendelse på). Vælg din tidligere oprettede gruppe fra AD, sørg for, at din politik har alle de korrekte indstillinger, der vedrører adgangskoden og spærring.
I dette eksempel har jeg tilføjet min bruger til en gruppe med to FGP-politikker, der er anvendt med forskellige indstillinger for prioriteret rækkefølge.
For at fastslå, hvilket indstillingsobjekt, der er gyldigt for adgangskoden, skal du vælge den berørte bruger og højreklikke.
Vælg View resultant password settings… (vis resulterende indstillinger for adgangskode…) Dette åbner den politik, der er aktiv. For os, der levede med den gamle metode, er dette et stort spring fremad med hensyn til anvendelighed.
Sådan redigeres og slettes politikker
At redigere en politik gøres meget simpelt ved at udvide AD-træet og vælge den korrekte politik i Password Settings container (beholder til angivelse af adgangskode). Den politik, der skal redigeres, åbnes ved at højreklikke eller dobbeltklikke på Properties (Egenskaber).
For at slette en politik (husk, at AD-objekter som standard er beskyttet mod utilsigtet sletning) skal du fjerne markeringen i boksen Protect From Accidental Deletion (beskyt mod utilsigtet sletning). Gem politikken, højreklik på den, og vælg Delete (slet).
I modsætning til brugere er det ikke muligt at aktivere eller deaktivere en politik. Hvis politikken findes, er den aktiv for ethvert objekt, den finder direkte anvendelse på. Glem ikke, at du, som det ses af det følgende billede, kan anvende politikker for brugere eller grupper. Dette giver dig også mulighed for at se, hvad der påvirkes, når du sletter politikken.
Del af ”de fem store”
Dette anses for at være en af de ”fem store” funktionalitetsområder i Windows Server 2012. Muligheden for at tilføje eller fjerne detaljerede adgangskoder efter eget ønske – med lidt besvær eller dybdegående AD-kendskab – er et stort fremskridt for dem, som har efterspurgt denne funktion år efter år.
For at genopfriske din hukommelse blev denne funktion første gang implementeret i Windows Server 2008. Det var nødvendigt at bruge ADSIEDIT til at oprette det nye objekt for angivelse af adgangskode OG alle attributter for dette objekt (i dette tilfælde adgangskodens længde, detaljer for spærring osv.). Det var også nødvendigt at indstille objekterne ”finder anvendelse på” i ADSIEDIT. Ikke et brugervenligt værktøj.
Microsoft har implementeret en meget efterspurgt funktion og udviklet et værktøj, der er meget mere anvendeligt end de første få varianter.
Og husk, at ALLE disse trin relativt nemt kan udføres med PowerShell 3.0.