Vanuit die kliënt se kant lyk dit soos 'n toevallige ontkoppeling 'n uur in 'n werkende sessie. Die taakbalk-ikoon verdwyn, die tonnel bou weer op, en die log wys 'n verifikasiefout eerder as 'n netwerkfout. Wat eintlik gebeur het, is dat die sessie heraonderhandel het en die tweede handdruk geloofsbriewe nodig gehad het waarvan die kliënt nie meer 'n geldige kopie gehad het nie. 'n Eenmalige kode wat by aanmelding gewerk het, kan nie weer werk nie, so die herslutel misluk presies soos ontwerp.

Die oplossing is 'n besluit oor wat die tweede handdruk moet voorlê, nie 'n langer herprobeer-tydhouer nie.

Volg die uitruiling vanuit die kliënt se oogpunt

By aanmelding stuur die kliënt die gebruikersnaam, die wagwoord en 'n kode van die token-toestel, en die bediener aanvaar die kombinasie. Die sessie loop dan totdat 'n heraonderhandelingsnoot afgaan, wat 'n nuwe TLS-handdruk binne die bestaande tonnel begin. Daardie handdruk vra weer vir verifikasie. As die bediener se verifikasiepad 'n wagwoord plus 'n huidige eenmalige kode verwag, het die kliënt geen nuwe kode om aan te bied nie, tensy die gebruiker teenwoordig is om een te tik.

Die meeste kliënte maak nie 'n aansporing midde-in die sessie oop nie, so die handdruk verstryk en die tonnel val weg. Die gebruiker sien 'n herverbinding, nie 'n verifikasië-aansporing nie, en daarom blameer die eerste verslag gewoonlik die netwerk.

auth-gen-token verander wie die tweede vraag beantwoord

Die auth-gen-token-opsie laat die bediener 'n token uitreik ná 'n suksesvolle aanmelding, en latere heraonderhandelings bied daardie token aan in plaas van om die wagwoord en kode te herhaal. Die handleiding dokumenteer die leeftyd en hernuwingsgedrag daarvan, en die token moet as 'n geloofsbrief met sy eie vervaldatum behandel word. In die verstekpad valideer die bediener die token self eerder as om die eksterne wagwoord-verifieerder weer te roep.

Met 'n eksterne verifikasie-integrasie verander daardie verdeling. Die inprop moet token-toestand verstaan en sy eie kontroles toepas, want die bediener is nie meer die enigste komponent wat besluit of die sessie voortduur nie. Om die token as nog 'n numeriese eenmalige kode te behandel, is nie 'n implementering van die funksie nie.

Besluit wat met rekeningstatus gebeur

'n Token wat 'n rekening se toegang oorleef, is 'n beleidsgat. Besluit hoe 'n gedeaktiveerde rekening, 'n verwyderde groeplidmaatskap of 'n herroepte toestel in werking tree terwyl 'n token nog geldig is. Kort token-leeftye maak die venster kleiner; 'n eksplisiete herroepingspad maak dit doelbewus. Skryf die antwoord neer voordat jy die opsie aktiveer, want die verstekpad raadpleeg nie die eksterne verifieerder by elke heraonderhandeling nie.

In 'n multi-bediener-ontplooiing moet die token-ondertekeningsgeheim gedeel word, anders kan die kliënt na 'n nodus gestuur word wat nie sy token kan valideer nie.

Toets verval en herverbinding, nie net aanmelding nie

Verlaag die heraonderhandelingsinterval in 'n toetsprofiel sodat die tweede handdruk plaasvind terwyl jy kyk, en volg dan albei logs. Bevestig dat die token by aanmelding uitgereik word, by herslutel voorgelê word, en volgens die gekonfigureerde leeftyd hernu of heruitgereik word. Forseer dan 'n token-verval en 'n volledige herverbinding, want 'n kliënt wat skoon herbind, kan steeds op die herslutelpad misluk.

Toets rekening-verwydering laaste. Daardie geval vertel jou of die beleid wat jy geskryf het, toegepas of bloot gedokumenteer word.

Moenie dit regstel deur hernuwing te deaktiveer nie

Om die heraonderhandelingsinterval op beide eweknieë op nul te stel, verwyder die simptoom en die sleutelrotasie saam daarmee. Dit verberg 'n geloofsbrief-herspelingsprobleem agter 'n beleidsverandering wat niemand hersien het nie. Hou die hernuwing, en kies tussen 'n bediener-uitgegewe token en 'n vars interaktiewe uitdaging op grond van of 'n gebruiker teenwoordig is.

'n Langer herprobeer-tydhouer maak nie 'n gebruikte kode weer geldig nie. Dit vertraag net die ontkoppeling en maak die log moeiliker om te lees.

Verwante artikels