По словам самого вендора на UserGate изначально задан неизменяемый параметр (на Q1-2023) - при аутентификации через RADIUS таймаут ожидания ответа от RADIUS-сервера = 10 сек
(установлено опытным путем, несмотря на то, что поддержка уверяет, что уже давно в новом релизе таймаут задан = 60 сек. Возможно, он и задан, но пока не работает! - обещают исправить в 6.1.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 аутентификацию (обычно это ТОПы). Но мы крайней не рекомендуем этого делать, так как "особо чувствительные" категории обычно и особо уязвимые - поэтому лучше уж они будут готовы и следуют инструкциям.