EAP-metoden først: hvilken adgangskodehash en VPN kan bruge
En VPN verificerer hemmeligheden, ikke webhashet. Læs metoden, og se så hvad lageret indeholder, før du lover at de samme adgangskoder bliver ved med at virke.
Mange teams har et weblogin, der virker, og en VPN, der afviser hver adgangskode fra den samme tabel. Webapplikationen sammenligner et hash, den selv har beregnet, mens tunnelen beder klienten om at bevise besiddelse af en hemmelighed på en måde, som serveren skal kunne kontrollere. Det er forskellige krav til det lagrede materiale. Netop i kløften mellem dem går de fleste af disse projekter i stå.
Læs metoden, derefter skemaet
Skriv ned, hvilket bevis den valgte metode kræver, før du ser på noget skema. En udfordring-svar-metode har brug for materiale, som serveren kan beregne det forventede svar ud fra, hvilket i praksis betyder adgangskoden eller en kompatibel afledt form. En metode, der bærer adgangskoden inde i en beskyttet tunnel, har brug for selve adgangskoden hos verifikationen. Læs metodens dokumentation for kravet til verifikatoren og ikke for klientkonfigurationen, fordi klientkravene normalt er den nemme del.
Et saltet hash fra et moderne webframework giver ingen af delene. Det verificerer én bestemt sammenligning og kan ikke føres tilbage til den hemmelighed, det kom fra.
Udfordring-svar kan ikke bruge et saltet hash
MSCHAPv2 er en udfordring-svar-udveksling, så serveren modtager aldrig adgangskoden og kan ikke sammenligne en lagret streng. Den skal udlede det forventede svar af materiale, den allerede har, og derfor er de kompatible lagrede former så snævre. En bcrypt- eller Argon2-værdi med en salt pr. bruger er envejs på en måde, der udelukker udvekslingen helt. Tabellen nedenfor tager udgangspunkt i lagerformen frem for metodenavnet, fordi lagerformen er det, der afgør svaret.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Dokumentationen for SQL-pluginet til strongSwan definerer sit eget skema til konfiguration og legitimationsoplysninger, og projektet markerer stadig det plugin som eksperimentelt. Intet i den tilpasser sig en applikations brugertabel eller gætter på, hvilken hashmetode der har produceret en lagret værdi. De realistiske muligheder er derfor migrering til et lager, gatewayen kan bruge, eller en godkendelsestjeneste foran det eksisterende lager, som kan udføre udvekslingen. Alt andet er et stik med en skjult antagelse indeni.
RADIUS flytter arbejdet, ikke kravet
At delegere EAP til en RADIUS-server ændrer, hvor verifikationen sker, og forbedrer normalt revisionssporet. Det gendanner ikke en adgangskode fra et envejshash, så godkendelsestjenesten har stadig brug for materiale, der er kompatibelt med den metode, den afslutter. Teams opdager det, efter de har bygget RADIUS-vejen og mødt den samme mur i den anden ende.
Hvor RADIUS-serveren kan læse en mappe med en kompatibel legitimation, virker designet, og VPN-gatewayen forbliver enkel. Hvor den ikke kan, er det ærlige svar en ændring af tilmeldingen frem for endnu et stik. Provisionering og tilbagekaldelse tilhører den, der ejer identiteten, så en kopieret tabel uden en understøttet synkroniseringsproces er en anden livscyklus for legitimation frem for enkelt login. Den driver første gang, nogen nulstiller en adgangskode kun ét sted, og driften er lydløs, indtil en konto, der findes i begge systemer, opfører sig forskelligt i hvert af dem.
Begræns den konto, der læser mappen, til netop den læsning, og hold den adskilt fra den konto, gatewayen bruger til sin egen konfiguration. En delt administrativ konto gør et skrivebeskyttet design til en meget større skadesradius.
Hvor kontoen bør bo
Når materialesprørgsmålet er afgjort, er der to arkitekturer tilbage. Gatewayen kan eje et lille lager for legitimation, som kun den læser, eller den kan delegere til en godkendelsestjeneste, der står foran virksomhedens mappe.
Den første er lettere at gennemskue og dårligere for brugeren, der ender med en ekstra adgangskode at vedligeholde. Den anden bevarer én identitet og tilføjer en afhængighed af en tjeneste, som nu skal være oppe, før nogen kan forbinde. Ingen af dem er forkerte, men valget bør noteres ved siden af gatewaykonfigurationen, fordi den næste ingeniør ellers vil antage, at den anden blev valgt. Uanset hvad du vælger, er de to kommandoer nedenfor dem, der viser den aktuelle tilstand, før du ændrer den.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsKontogodkendelse afgør heller ikke autorisation. Gruppemedlemskab, enhedstilstand og netværkstilladelse kræver stadig en eksplicit mapping, når brugeren har bevist den krævede identitet. En forbindelse, der godkender perfekt og ikke autoriserer noget, er et policyresultat, ikke en fejl i metoden.