Timeout RADIUS при интеграции OTP (Indeed) с UserGate (что важно знать)
По словам самого вендора на UserGate изначально задан неизменяемый параметр (на Q1-2023) - при аутентификации через RADIUS таймаут ожидания ответа от RADIUS-сервера = 10 сек (установлено опытным путем, несмотря на то, что поддержка уверяет, что уже давно в новом релизе таймаут задан = 60 сек. Возможно, он и задан, но пока не работает! - обещают исправить в 6.1.10)
Поэтому при проведении интеграции с различными сторонними системами, которые, в свою очередь, дают возможность этот таймаут задать, может возникать рассинхронизация из-за невозможности задать единое значение. В таком кейсе UserGate может оказаться узким местом с самым минимальным таймаутом по сравнению с параллельными системами (обычно тайм-ауты для аутентификации RADIUS 20-30 сек, особенно с учетом наличия необходимости взять телефон и подтвердить второй фактор, прилетающий по PUSH-у).
Были проведены проверки по определению времени, при котором подключение происходит сразу и времени, при котором сессия будет прервана. Также имелись все необходимые значения по таймауту на радиус сервере и системе 2FA, которые, в свою очередь, были увеличены в 3 раза для проведения тестов и диагностики. Собирались дампы трафика при моментальном подключении и сбросом соединения. В проходимом кейсе система 2FA работала исправно и корректно, так как всегда PUSH (элемент авторизации 2FA) приходит почти что моментально.
Путь, который происходит "за кулисами" в сценарии авторизации пользователя через второй фактор :
Пользователь при подключении по VPN логинится у себя на клиенте (в кейсе рассматривался встроенный клиент Windows - так как пока у UserGate нет собственного клиента)
Далее запрос уходит в сторону сервера 2FA (там же расположен радиус) через UserGate
Сервер 2FA проверяет в AD есть ли пользователь с такими данными
AD дает свой ответ в сторону сервера 2FA
После идет запрос на сервер с модулем для PUSH-уведомлений
С сервера с модулем для PUSH-уведомлений уходит PUSH на телефон пользователя
Пользователь подтверждает PUSH
Информация о подтверждении уходит на на сервер с модулем для PUSH-уведомлений, после на сервер 2FA,
после подтверждение уходит на UserGate с RADIUS сервера
UserGate должен "успеть" передать RADIUS ОК ответ в сторону клиента, пока тот не закрыл установленную сессию по тайм-ауту.
В нашем сценарии сессия отваливалась, поскольку последнего шага UserGate не совершал : для него RADIUS сессия уже казалась закрытой (ведь изменить таймаут нельзя - об этом зарегистрировали feature request).
В данной ситуации выхода 2:
подготовить инструкцию для пользователей, согласно которой они должны подключаться и "знать" про ограничения на таймаут - в случае необходимости они должны быть готовы повторно выполнить попытку, уже держа телефон наготове (если в первый раз не успели это сделать).
исключить часть особо "чувствительных" пользователей из группы, которая должна проходить 2FA аутентификацию (обычно это ТОПы). Но мы крайней не рекомендуем этого делать, так как "особо чувствительные" категории обычно и особо уязвимые - поэтому лучше уж они будут готовы и следуют инструкциям.