Са стране клијента то изгледа као случајан прекид сат времена након почетка радне сесије. Икона у системској траци нестаје, тунел се поново гради, а дневник показује грешку аутентикације уместо мрежне грешке. Оно што се заиста догодило јесте да је сесија поново преговарала и да су другом руковању требали креденцијали за које клијент више није имао важећу копију. Једнократни код који је радио при пријави не може поново да ради, па поновна размена кључева пада тачно како је пројектовано.

Решење је одлука о томе шта друго руковање треба да представи, а не дужи тајмер поновних покушаја.

Прођите кроз размену из угла клијента

При пријави клијент шаље корисничко име, лозинку и код са токен уређаја, а сервер прихвата ту комбинацију. Затим сесија траје док се не активира окидач за поновно преговарање, који покреће ново TLS руковање унутар постојећег тунела. То руковање поново тражи аутентикацију. Ако пут аутентикације на серверу очекује лозинку и тренутни једнократни код, клијент нема нови код да понуди осим ако корисник није присутан да га унесе.

Већина клијената не отвара упит усред сесије, па руковање истекне и тунел падне. Корисник види поновно повезивање, а не упит за аутентикацију, и зато први извештај обично окривљује мрежу.

auth-gen-token мења ко одговара на друго питање

Опција auth-gen-token дозвољава серверу да изда токен након успешне пријаве, а каснија преговарања представљају тај токен уместо да понављају лозинку и код. Упутство документује његов животни век и понашање при обнављању, а токен се мора третирати као креденцијал са сопственим роком трајања. На подразумеваном путу сервер сам валидира токен уместо да поново позива спољни аутентификатор лозинки.

Са интеграцијом спољне аутентикације, та подела се мења. Прикључак мора да разуме стање токена и примени сопствене провере, јер сервер више није једина компонента која одлучује да ли се сесија наставља. Третирање токена као још једног нумеричког једнократног кода није имплементација ове функције.

Одлучите шта се дешава са статусом налога

Токен који надживи приступ налога је рупа у политици. Одлучите како онемогућен налог, уклоњено чланство у групи или опозван уређај делују док је токен још важећи. Кратак животни век токена сужава прозор; експлицитна путања опозива чини га намерним. Запишите одговор пре него што укључите опцију, јер подразумевани пут не консултује спољни аутентификатор при сваком преговарању.

У поставци са више сервера, тајна за потписивање токена мора бити дељена, иначе клијент може бити послат на чвор који не може да валидира његов токен.

Тестирајте истек и поновно повезивање, не само пријаву

Смањите интервал преговарања у тестном профилу да друго руковање прође док гледате, па пратите оба дневника. Потврдите да се токен издаје при пријави, представља при размени кључева и обнавља или поново издаје према конфигурисаном животном веку. Затим принудно изазовите истек токена и потпуно поновно повезивање, јер клијент који се чисто поново повезује и даље може да падне на путу размене кључева.

Уклањање налога тестирајте на крају. Тај случај вам каже да ли се написана политика спроводи или је само документована.

Не поправљајте то искључивањем обнављања

Постављање интервала преговарања на нулу на оба партнера уклања симптом и заједно са њим ротацију кључева. То скрива проблем поновне употребе креденцијала иза промене политике коју нико није прегледао. Задржите обнављање и изаберите између токена који издаје сервер и новог интерактивног изазова на основу тога да ли је корисник присутан.

Дужи тајмер поновних покушаја не чини искоришћен код поново важећим. Он само одлаже прекид и отежава читање дневника.

Повезани чланци