Roter en lokal VPN-konto uden at miste dens tilladelser

At erstatte en fungerende VPN-adgangskode ser ud som en ændring på to linjer, indtil den genopbyggede konto vender tilbage med standardtilladelser, og den eneste administrationssession er væk. Den sikre procedure afhænger af, hvor legitimationsoplysningen er gemt, og hvilken protokol der bruger den, ikke af hvilken kommando der er kortest. Sammenlign de to fremgangsmåder, før du rører ved enheden. Rotation på stedet bevarer kontoobjektet; sletning og genskabelse erstatter det, og alt, der pegede på det, forsvinder med det.

Find ud af, hvilket lager der faktisk godkender sessionen

Start ved tunnel- eller forbindelsesprofilen, ikke ved brugerdatabasen. Profilen angiver en godkendelsesmetode og ofte en servergruppe, og hvis den gruppe peger på RADIUS eller TACACS+, er det lokale brugernavn på boksen ren dekoration. Læs profilens godkendelsesliste og den AAA-gruppe, den refererer til, før du planlægger noget. Kun når profilen siger lokal, betyder kontoen på boksen noget. Tager du fejl her, roterer du en legitimationsoplysning, som ingen bruger, mens den rigtige katalogpost forbliver præcis, som den var.

Den samme enhed rummer normalt to befolkninger: administratorer, der logger ind på den, og VPN-brugere, der afslutter en tunnel. De kan dele et lager, og det bør ikke antages, at de gør.

Opdatering på stedet kontra sletning og genskabelse

Rotation på stedet ændrer ét attribut på et eksisterende objekt. Privilegieniveau, gruppemedlemskab, autorisationsattributter og enhver politik, der refererer til kontoen, overlever, fordi intet blev fjernet. Sletning og genskabelse genopbygger objektet fra en kommandolinje, så hvert felt, du ikke gentog, vender tilbage til sin standardværdi. På en enhed, hvor attributter pr. bruger bærer tildelinger af delt tunnel eller adressepulje, er den forskel hele risikoen.

Genopbygning har én legitim anvendelse: når selve det lagrede format skal ændres, og platformen ikke tilbyder nogen konvertering. Selv da skal du først registrere den eksisterende post, fordi den kørende konfiguration er det eneste præcise inventar over, hvad kontoen bar. En kopi af den konfiguration, der er taget før ændringen, slår en tilbagerulningsplan skrevet fra hukommelsen.

Hvorfor den hash, du har, måske ikke er den hemmelighed, den har brug for

Lagerformater adskiller sig på en måde, der afgør svaret. En envejs-hash kan verificere en adgangskode, når serveren modtager den i klartekst inde i tunnelen, men en udfordring-svar-metode har brug for selve den delte hemmelighed for at beregne digesten. Derfor kan det at konvertere hver konto til det stærkeste envejsformat bryde CHAP eller MS-CHAP for præcis de brugere, der er afhængige af det.

Beslut efter protokol, ikke efter slogan. Hvor metoden kræver en genopretningsbar hemmelighed, er det krav en begrænsning i designet og ikke en forglemmelse, der skal ryddes op.

Sessioner, der overlever legitimationsoplysningen

Ændring af en legitimationsoplysning afslutter ikke sessioner, der allerede er godkendt. En peer med en etableret tunnel fortsætter med at virke indtil nøglefornyelse, gentagen godkendelse eller en eksplicit afbrydelse.

Planlæg den del separat, og planlæg den før ændringen. Hvis legitimationsoplysningen er lækket, gør det rotationen formålsløs at lade live-sessioner køre. Hvis den blot er udløbet, er det en afbrydelse, du ikke havde brug for, at tvinge hver peer offline. Hold en anden administrationsvej åben, mens du arbejder, helst en, der ikke afhænger af den konto, der redigeres, fordi fejltilstanden her fjerner din adgang præcis, når du har brug for den. Bekræft derefter et nyt logon og de ressourcer, det kan nå.

Bevis, at tilladelserne overlevede

Log ind som den roterede bruger, og kontroller, hvad sessionen giver, ikke bare at den åbnede. Nå en ressource, der kræver den autorisation, kontoen skal bære, og prøv en, den ikke bør nå. Et vellykket logon med indskrænket eller udvidet adgang er en mislykket ændring.

Sammenlign autorisationsattributterne i den kørende konfiguration med den kopi, du tog i starten. Se på gruppemedlemskab, adressepulje, DNS- og delt-tunnel-indstillinger og ethvert politikobjekt, der navngav kontoen. Opdater derefter registreringen af, hvor den legitimationsoplysning bor, da den næste rotation begynder fra den note. En rotation, som ingen kan gentage ud fra dokumentation, er kun blevet overlevet én gang.