Коротко — да и нет. Формально связка MikroTik → FreeRADIUS → privacyIDEA поддерживает OTP, но именно для схемы Windows L2TP/IPsec (MS‑CHAPv2) есть принципиальное ограничение, и простого «включил на RADIUS — и всё работает» не получится. Объясню почему и какие есть рабочие варианты.
Почему проблема
- MS‑CHAPv2 — challenge/response протокол: клиент не пересылает пароль в открытом виде, а RADIUS‑сервер получает MS‑CHAP‑ответ. Чтобы проверить этот ответ, RADIUS должен иметь доступ к «исходному» паролю пользователя (или использовать ntlm_auth/AD‑сервис, который самостоятельно проверяет ответ). То есть простая проверка OTP, как отдельного токена, невозможна без того, чтобы RADIUS видел (или мог проверить) отдельные составляющие.
- privacyIDEA ожидает проверку OTP (и/или password+otp). Windows встроенный L2TP клиент не умеет отдельно передавать OTP как отдельное поле RADIUS — единственный приемлемый приём на клиенте — слепить пароль+OTP в одно поле (user types password+otp). Но:
- при использовании AD + ntlm_auth/rlm_winbind/rlm_ntlm_auth вы не получаете «plaintext» для дальнейшей обработки/распарсинга (модуль сам общается с AD), поэтому разделить «статический пароль» и «OTP» в FreeRADIUS трудно/невозможно;
- даже если FreeRADIUS как‑то получает plaintext (редко), MS‑CHAPv2 аутентификация уже использует этот единый «пароль» для вычисления ответа, и архитектурно трудно/надёжно выполнить две независимые проверки (AD static password + OTP через privacyIDEA) в надёжной последовательности.
Рабочие варианты / рекомендации
1) Рекомендованный и надёжный вариант — перейти на IKEv2 + EAP (например, IKEv2 с EAP‑MSCHAPv2 внутри PEAP) вместо L2TP/IPsec:
- Windows поддерживает IKEv2 с EAP.
- MikroTik (RouterOS, современные версии) поддерживает IKEv2.
- FreeRADIUS прекрасно работает с EAP/PEAP/MSCHAPv2 и получает cleartext (внутри защищённого EAP туннеля) или может обрабатывать пароль+OTP; privacyIDEA имеет модуль/возможность интеграции с FreeRADIUS (REST API), и вы сможете валидировать OTP как часть авторизации.
- Этот путь даёт стандартную, поддерживаемую 2FA интеграцию и избегает ограничений MS‑CHAPv2 для L2TP.
2) Если перейти на IKEv2 нельзя — возможные (но менее надёжные) подходы:
- «Password concatenation»: заставить пользователей вводить в клиенте «статический_пароль||OTP» в поле пароля. Настроить FreeRADIUS так, чтобы он распарсил получённый пароль, отдельно проверил статическую часть (напр., через LDAP/AD) и OTP через privacyIDEA. Минусы:
- с AD/ntlm_auth это обычно не работает, потому что ntlm_auth не даст FreeRADIUS чистый пароль для разбиения;
- это хрупкое и неудобное для пользователей решение.
- Использовать сторонний VPN‑клиент на Windows, который умеет передавать OTP отдельно или поддерживает EAP/IKEv2 — тогда можно оставить privacyIDEA/FreeRADIUS в роли полноценного 2FA сервера.
3) Другие подходы:
- Сертификаты (EAP‑TLS) + OTP отдельно (web/portal) — более безопасно, но архитектурно сложнее для пользователей.
- Двухступенчатая аутентификация: например, обязательная проверка клиента по сертификату (или по PSK), и отдельно web‑портал для личного доступа + OTP. Не всегда удобно.
Практические шаги, если пойдёте по рекомендованному пути (IKEv2 + EAP):
- Убедитесь, что RouterOS на MikroTik поддерживает ike2 и умеет проксировать EAP в RADIUS.
- Настройте в MikroTik ipsec profile/peer для ike2 и включите EAP.
- Настройте FreeRADIUS для EAP (PEAP/MSCHAPv2 или EAP‑TLS), добавьте privacyIDEA модуль/вызовы (privacyIDEA предлагает RADIUS интеграцию через REST; в FreeRADIUS это обычно rlm_rest или готовый модуль).
- Протестируйте с debug (freeradius -X) и privacyIDEA debug; проверьте цепочку: MikroTik → FreeRADIUS → privacyIDEA.
Если хотите — могу:
- Привести пример конфигурации FreeRADIUS (authorize/authenticate) для интеграции с privacyIDEA (REST вызов) и EAP;
- Подсказать параметры на MikroTik для передачи EAP в RADIUS;
- Помочь оценить, сможет ли ваша текущая версия RouterOS/клиенты поддержать IKEv2/EAP.
Хотите, чтобы я подробно расписал конфиг FreeRADIUS + privacyIDEA для EAP (PEAP/MSCHAPv2) и пример настроек на MikroTik?