Sergey Bezpalov's Blog

VPN с одним паролем в 2022-м уже не проходил аудит — а прямой «FortiGate → Azure MFA» без промежуточного RADIUS-сервера в экосистеме Microsoft не существует. Рабочая схема, которую я разворачивал не раз: FortiGate как NAS, Cisco ISE как policy/RADIUS proxy, два Microsoft NPS с Azure MFA Extension, AD для первого фактора, Azure MFA для второго. Ниже — пошаговый runbook без воды.

Архитектура

Цепочка запросов:

1. VPN-клиент отправляет credentials на FortiGate.
2. FortiGate шлёт RADIUS Access-Request на Cisco ISE.
3. ISE проксирует запрос на Microsoft NPS (можно зарегистрировать два NPS для HA).
4. NPS проверяет логин/пароль в Active Directory (первичная аутентификация).
5. NPS через Azure MFA Extension инициирует второй фактор; Azure MFA общается с пользователем напрямую (Authenticator, SMS, звонок).
6. При успехе Access-Accept идёт обратно: NPS → ISE → FortiGate → клиент получает туннель.

Два NPS лучше ставить в разные ДЦ — если один падает, RADIUS продолжает работать через второй. На ISE оба регистрируются как external RADIUS servers.

Общая логика Azure MFA: документация Microsoft.

Что понадобится

Шаг 1. Azure AD и MFA

1. В Azure Portal → Azure Active Directory → Security → MFA — включите MFA для нужных пользователей (per-user или через Conditional Access).
2. Убедитесь, что учётные записи VPN-пользователей синхронизированы (Azure AD Connect) или созданы в cloud-only AD.
3. Зарегистрируйте методы MFA (Microsoft Authenticator предпочтительнее SMS).

Без зарегистрированного метода второй фактор зависнет — пользователь получит reject или timeout.

Шаг 2. Microsoft NPS + Azure MFA Extension

На каждом сервере NPS (повторить на втором):

2.1. Роль NPS

Install-WindowsFeature NPAS -IncludeManagementTools

2.2. Azure MFA NPS Extension

1. Скачайте NPS Extension for Azure MFA с сайта Microsoft.
2. Установите на сервер NPS.
3. Запустите конфигурацию от имени администратора:

cd 'C:\Program Files\Microsoft\Azure MFA\Config'
.\AzureMfaNpsExtn.ps1

Скрипт запросит credentials Azure AD (Global Admin или Application Admin) и зарегистрирует extension.

2.3. RADIUS clients (FortiGate / ISE)

В NPS → RADIUS Clients and Servers → RADIUS Clients добавьте:

В типовой схеме клиентом NPS является ISE, не FortiGate.

2.4. Политики NPS

1. Connection Request Policies — разрешить запросы от ISE (Calling Station ID / Client Friendly Name).
2. Network Policies — аутентификация через Windows Authentication (AD), grant access.
3. В Azure MFA Extension registry (HKLM\SOFTWARE\Microsoft\AzureMfa) проверьте BypassMFADUoT и REQUIRE_USER_MATCH — для VPN обычно REQUIRE_USER_MATCH=1.

Перезапустите службу Network Policy Server после установки extension.

Шаг 3. Cisco ISE

3.1. External RADIUS servers (NPS)

Administration → Network Resources → External RADIUS Servers:

Добавьте оба сервера в RADIUS Server Sequence для failover.

3.2. Network Device (FortiGate)

Work Centers → Network Access → Network Devices:

• Name: FGT-VPN
• IP Address: management/source IP FortiGate для RADIUS
• Shared Secret: secret для FortiGate ↔ ISE
• Device Type: Fortinet:FortiGate

3.3. Policy Set

Создайте Policy Set для VPN/RADIUS:

1. Conditions: Device IP Equals FGT-VPN (или RADIUS Service-Type).
2. Authentication Policy → Use → External RADIUS Server Sequence (NPS).
3. Authorization — профиль доступа (VLAN, dACL, или PermitAccess для VPN).

В Live Logs → RADIUS включите мониторинг до первого успешного логина.

Шаг 4. FortiGate

4.1. RADIUS server

config user radius
    edit "ISE-RADIUS"
        set server "10.x.x.x"
        set secret ENC <encrypted>
        set auth-type pap
    next
end

auth-type — pap или mschapv2 в зависимости от того, что принимает ISE/NPS. Для большинства VPN-клиентов MS-CHAPv2; если ISE настроен на PAP proxy — используйте PAP.

4.2. User group

config user group
    edit "VPN-RADIUS"
        set member "ISE-RADIUS"
    next
end

4.3. VPN portal / IPsec

VPN → SSL-VPN Settings (или IPsec tunnel):

• Authentication/Portal Mapping или Peer Options → группа VPN-RADIUS.
• Убедитесь, что клиент запрашивает username/password (не certificate-only, если MFA на user credentials).

Шаг 5. Таймауты — критично для MFA

По умолчанию FortiGate ждёт ответ RADIUS 5 секунд. Push в Authenticator занимает 15–60 секунд — без правки таймаута VPN стабильно падает с timeout.

GUI: System → Settings → remoteauthtimeout → 60–90 (диапазон 1–300, default 5).

CLI:

config system global
    set remoteauthtimeout 90
end

Согласуйте таймауты на всех звеньях:

Проверка

1. FortiGate: diagnose debug application radiusd -1 + diagnose debug enable — видны Access-Request/Accept.
2. ISE: Live Log — запрос от FGT, proxy к NPS, result Accept/Reject.
3. NPS: Event Viewer → Custom Views → Server Roles → Network Policy and Access Services.
4. Azure: Sign-in logs — MFA requirement satisfied.

Тестовый сценарий: пользователь с зарегистрированным Authenticator → VPN login → push → Accept → туннель up.

Типовые проблемы

Итог

Схема не самая короткая, зато переиспользует ISE как единую точку policy для VPN и проводного доступа, а Azure MFA остаётся там, где ему место — на NPS Extension. Главный практический вывод: увеличьте RADIUS timeout на FortiGate до 90 секунд до первого теста, иначе будете отладку MFA проводить вслепую.