OpenVPN køyrer ned ein OTP-økt seinare: kva reautentisering krev

Frå klienten si side ser det ut som ein tilfeldig fråkopling ein time ut i ei arbeidsøkt. Skuffeikonet forsvinn, tunnelen blir bygd opp att, og loggen viser ein autentiseringsfeil i staden for ein nettverksfeil. Det som faktisk skjedde, var at økta reforhandla og at den andre handtrykken trong legitimasjon som klienten ikkje lenger hadde ein gyldig kopi av. Ein eingongskode som fungerte ved innlogging kan ikkje fungere att, så rekeyen feilar nøyaktig som designa.

Løysinga er eit vedtak om kva den andre handtrykken skal presentere, ikkje ein lengre retry-timer.

Gå gjennom utvekslinga frå klienten sitt ståstad

Ved innlogging sender klienten brukarnamnet, passordet og ein kode frå token-eininga, og serveren godtek kombinasjonen. Deretter går økta til ein utløysar for reforhandling fyker av, og den startar ein ny TLS-handtrykk inne i den eksisterande tunnelen. Den handtrykken ber om autentisering på nytt. Viss autentiseringsvegen til serveren ventar eit passord pluss ein gjeldande eingongskode, har klienten ingen ny kode å by på med mindre brukaren er til stades og kan skrive han inn.

Dei fleste klientar opnar ikkje ei førespurnad midt i økta, så handtrykken går ut på tid og tunnelen fell. Brukaren ser ei tilkopling på nytt, ikkje ei autentiseringsførespurnad, og difor legg den første rapporten vanlegvis skulda på nettverket.

auth-gen-token endrar kven som svarar på det andre spørsmålet

Alternativet auth-gen-token lèt serveren gje ut eit token etter vellukka innlogging, og seinare reforhandlingar presenterer det tokenet i staden for å gjenta passordet og koden. Handboka dokumenterer levetida og fornyingsåtferda, og tokenet må handsamast som legitimasjon med sin eigen utløpsdato. I standardvegen validerer serveren tokenet sjølv i staden for å kalle den eksterne passordautentikatoren på nytt.

Med ein ekstern autentiseringsintegrasjon endrar den fordelinga seg. Pluginen må forstå tilstanden til tokenet og bruke sine eigne kontrollar, fordi serveren ikkje lenger er den einaste komponenten som avgjer om økta held fram. Å handsame tokenet som nok ein numerisk eingongskode er ikkje ein implementasjon av funksjonen.

Avgjer kva som skjer med kontostatusen

Eit token som lever lenger enn tilgangen til ein konto er eit hol i policyen. Avgjer korleis ein deaktivert konto, eit fjerna gruppemedlemskap eller ei tilbakekalla eining verkar medan eit token framleis er gyldig. Kort tokenlevetid gjer vindauget mindre; ein eksplisitt tilbakekallingsveg gjer det medvite. Skriv ned svaret før du slår på alternativet, fordi standardvegen ikkje spør den eksterne autentikatoren ved kvar reforhandling.

I ein distribusjon med fleire serverar må hemmelegheita for tokensignering delast, elles kan klienten sendast til ein node som ikkje kan validere tokenet.

Test utløp og attkopling, ikkje berre innlogging

Senk reforhandlingsintervallet i ein testprofil slik at den andre handtrykken skjer medan du ser på, og følg deretter båe loggane. Stadfest at tokenet blir gjeve ut ved innlogging, presentert ved rekey, og fornya eller gjeve ut på nytt i samsvar med den konfigurerte levetida. Tving deretter fram eit tokenutløp og ei full attkopling, fordi ein klient som koplar til på nytt reint framleis kan feile på rekey-vegen.

Test kontofjerning til slutt. Det tilfellet fortel deg om policyen du skreiv blir handheva eller berre dokumentert.

Ikkje fiks det ved å slå av fornying

Å setje reforhandlingsintervallet til null på båe partar fjernar symptomet og nøkkelrotasjonen med det. Det skjuler eit problem med gjenbruk av legitimasjon bak ei policyendring ingen har gått gjennom. Hald på fornyinga, og vel mellom eit token som serveren gjev ut og ei ny interaktiv utfordring ut frå om ein brukar er til stades.

Ein lengre retry-timer gjer ikkje ein brukt kode gyldig att. Han berre utset fråkoplinga og gjer loggen vanskelegare å lese.