Hvor den statiske udfordringskode hører til i et OpenVPN-login

Klienten viser en anden boks efter adgangskodefeltet, du indtaster koden fra hardwaretokens, og login fejler stadig med en godkendelsesfejl. Den boks findes, så profilen bad om den. Om serveren nogensinde modtog værdien i en form, den forstår, er et andet spørgsmål, og det er det, der er værd at besvare først.

Begynd med den prompt, din klient faktisk viser

En profil kan indeholde en statisk udfordringsdirektiv med en promptstreng og et flag, der styrer, om svaret vises, mens du skriver. Prompten er det, du ser i dialogen; flaget er en visningsindstilling for samme input. Ingen af dem fortæller serveren, hvordan den skal verificere noget.

Tæl de felter, du faktisk fik. Ét felt til et brugernavn plus ét maskeret felt er et normalt adgangskode-login helt uden udfordring. Et andet felt, der dukker op efter adgangskoden med sin egen etiket, er klienten, der implementerer udfordringsinteraktionen.

Hvis den anden boks aldrig vises i den klient, du bruger, implementerer den måske ikke interaktionen, eller den implementerer den kun gennem en anden frontend som en administrationsgrænseflade. At kontrollere klienten er billigere end at omskrive profilen, og det er normalt der, uoverensstemmelsen faktisk ligger.

Hvad serveren allerede skal understøtte

Profilen beskriver, hvad klienten skal indsamle. Den aktiverer ikke verifikation på serveren, og en server uden den tilsvarende godkendelsesintegration modtager blot en adgangskode, den ikke genkender. Derfor viser nogle installationer prompten og afviser hver kode, og derfor er operatørens svar om, hvilken mekanisme der udfører kontrollen, det svar, der betyder noget.

Spørg operatøren, hvilken mekanisme der udfører kontrollen. Det kan være et plugin, der taler med PAM, et scriptkrog, der validerer svaret mod en tokentjeneste, eller en administrationsbaseret integration, der selv parser den pakkede værdi. Hver af dem forventer et lidt forskelligt input.

Det er også her, forventningerne skal kalibreres. En anden prompt er en inputmekanisme, ikke bevis på, at en anden faktor håndhæves, fordi håndhævelsen sker på serversiden og først viser sig, når du tester en forkert kode.

Det kodede felt, som administrationsgrænsefladen sender

Når en frontend driver forbindelsen gennem administrationsgrænsefladen, pakkes adgangskoden og udfordringssvaret i én værdi før indsendelse. Referencen for administrationsgrænsefladen dokumenterer formatet: et præfiks og derefter adgangskoden og svaret som separate Base64-komponenter.

Base64 er en kodning, ikke en beskyttelse. Den skjuler intet for nogen, der kan læse feltet, og den gør ikke en engangskode om til noget genanvendeligt. Den pakkede værdi fortjener samme håndtering som en adgangskode: ud af delte profiler, ud af kommandolinjer og ud af diagnostiske logfiler.

Den kodning er også den mest almindelige kilde til forvirring, fordi der nu er tre former, der ser ens ud og ikke kan udskiftes. En almindelig legitimationsfil indeholder en adgangskode. En bogstavelig sammenkædning af adgangskode og kode indeholder en anden streng. En administrationsklients pakkede svar indeholder en tredje. Bekræft, hvilken din verifikationsvej forventer, før du ændrer et felt, blot fordi en fejl forsvandt.

Statisk kontra dynamisk: forskellig timing

En statisk udfordring kendes, før den første legitimationsoplysning sendes, så klienten kan spørge om den på forhånd. En dynamisk udfordring kommer senere, sendt af godkendelsesforløbet efter en udveksling allerede er begyndt, og den kræver en klient, der kan håndtere en anmodning midt i samtalen.

Støtte til den ene giver dig ikke den anden. Et profildirektiv, der konfigurerer en statisk prompt, implementerer ikke en serverinitieret udfordring, og en frontend, der håndterer dynamiske anmodninger, viser måske stadig ikke en statisk. At læse, hvilken side der startede anmodningen, er den hurtigste måde at skelne dem.

Uovervåget drift er, hvor dette bliver et designspørgsmål snarere end et UI-spørgsmål. En gemt kode er ikke en holdbar legitimationsoplysning ved opstart, og en genopkobling timer senere kræver friskt input, medmindre installationen understøtter en tokenordning, som operatøren bevidst har aktiveret.

Test succes og fiasko, ikke bare dialogen

Kør begge halvdele af testen. Korrekte legitimationsoplysninger med et gyldigt svar bør lykkes; korrekte legitimationsoplysninger med et bevidst forkert svar bør afvises. Hvis begge lykkes, indsamler klienten input, som intet verificerer, og dialogen er blevet forvekslet med en kontrol. Den ene test fanger flere installationer end nogen mængde profilgennemgang.

Gentag derefter forbindelsen efter en genopkobling, med en konto, der ikke er tilmeldt, og gennem hvilken som helst klient, dine brugere faktisk kører. At prompten vises, er klientadfærd; at en forkert kode afvises, er serveren, der håndhæver noget.