Pozn.: Popis v článku vychází z FortiGate FG-300E s FortiOS verzí 6.4.6. Který je nakonfigurovaný jako FGCP cluster a využívá VDOM.

Celé řešení je dost jednoduché, rychle se zprovozní a dobře popsané v dokumentaci. Takže zde se zaměříme spíše na různá úskalí a nedostatky. A na popis reálného chování.

Úvod a dokumentace

Základem je mít funkční SSL VPN, nastaven NPS server a vytvořeno RADIUS připojení z FortiGate. Než se pustíme do dalších kroků, tak je nutné mít ověřeno, že VPN funguje a uživatelé z AD DS domény se ověřují přes RADIUS. Tyto věci jsme popsali ve starších článcích, primárně:

• FortiGate autentizace RADIUS, skupiny a MS NPS
• FortiGate konfigurace SSL VPN

Microsoft má pěkný popis o integraci NPS s Azure AD MFA. Ale když čteme jen popis VPN, tak se nedozvíme o různých omezeních (musíme kouknout do dalších článků v sekci).

• Integrate your VPN infrastructure with Azure AD MFA by using the Network Policy Server extension for Azure
• Integrate your existing Network Policy Server (NPS) infrastructure with Azure AD Multi-Factor Authentication

Nějaký návod nalezneme (po složitějším hledání) také u Fortinetu.

• Configuring FortiClient VPN with multifactor authentication

Microsoft NPS Extension for Azure MFA

Než začneme plánovat instalaci a využití NPS Extension, tak musíme vědět, jak celé řešení funguje a jaké jsou známé nedostatky (omezení z principu designu).

Volba NPS serveru

Ve chvíli, kdy nainstalujeme a nakonfigurujeme NPS rozšíření pro Azure MFA na určitý NPS server, tak všechny autentizace RADIUS klientů (vůči tomuto serveru) vyžadují použití MFA. Takže pokud tento server používáme i pro další RADIUS autentizace, kde nechceme používat MFA, tak máme smůlu. Čekal bych, že se MFA bude zapínat na jednotlivých Network Policy, ale po instalaci se aktivuje globálně.

Řešením je instalovat nový NPS server, kde bude pouze MFA. Naštěstí se NPS role dá instalovat na libovolný Windows Server. Pokud máme někde již hotovou konfiguraci, tak můžeme využít export/import.

Je tu ještě určitá možnost v registrech nastavit, že se MFA použije pouze pro uživatele s aktivovaným Azure AD MFA. Popis Install and configure the NPS extension, Prepare for users that aren't enrolled for MFA.

HKLM\SOFTWARE\Microsoft\AzureMfa:REQUIRE_USER_MATCH

Jen zmínka, zda by se nedalo využít IP exceptions.

Podporované MFA ověřovací metody

Celkově Azure AD Multi-Factor Authentication (MFA), a také podporované metody pro druhý faktor ověření, jsme si popisovali v článku

• Azure AD přihlašování bez hesla a vícefaktorové ověření (MFA)

Když chceme využít NPS Extension for Azure MFA, tak můžeme použít některé metody jen za určitých podmínek. Z principu není možno využít přihlášení aplikací Microsoft Authenticator, tedy Passwordless Phone sign-in, kdy se nezadává uživatelské heslo.

Dále záleží, jakou použijeme autentizační metodu (Authentication Method) mezi RADIUS serverem a klientem. Podporováno je

• EAP (Extensible Authentication Protocol) - pouze spolu s MSCHAPv2 (Microsoft Challenge-Handshake Authentication Protocol version 2) nebo PEAP (Protected EAP) - je nejbezpečnější, FortiGate jej zde nepodporuje
• MSCHAPv2 (Microsoft Challenge-Handshake Authentication Protocol version 2) - obsahuje několik slabých míst
• PAP (Password Authentication Protocol) - je považován za slabé ověřovací schéma, je nešifrovaný

Všechny RADIUS autentizační metody podporují MFA metodu hlasový hovor (telefonát - phone call) a Microsoft Authenticator notifikaci (mobile app notification). V těchto případech není potřeba zadávat žádný vstup v druhém kroku ověření. Ke schválení dojde v Azure AD a informaci dostane NPS server. Problém je u metod, kdy se musí zadat ověřovací kód (verification code).

Pouze nejslabší PAP podporuje všechny MFA metody. K předchozím dvěma tedy přidává SMS (phone text message), OATH Hardware Token a ověřovací kód mobilní aplikace (mobile app verification code). Po ověření jména a hesla odesílá RADIUS server klientovi speciální RADIUS Reply-Message zprávu (Enter Your Microsoft verification code) a požaduje další vstup.

V případě, že je potřeba zadání ověřovacího kódu, musí RADIUS klient toto podporovat a uživateli zobrazit vstupní pole. FortiClient s tím nemá problém.

Oficiální popis Determine which authentication methods your users can use.

Přenos RADIUS atributů klientovi

Je tu ještě další problém, když splníme předchozí podmínky. Pokud chceme použít MFA ověřovací metodu, která vyžaduje zadání ověřovacího kódu. Tedy použijeme PAP. Tak i v případě, že je autentizace úspěšná a NPS server odpoví, že ověření proběhlo. Tak nepředá nastavené RADIUS atributy (RADIUS attributes) v Network Policy RADIUS klientovi (FortiGate).

To v praxi nejčastěji znamená, že se nepředá zařazení do skupiny, kterou následně používáme na FortiGate. Přihlášený uživatel tedy není zařazen do skupiny, která má povolenu komunikaci v rámci VPN. A tudíž se nepřihlásí.

Základní podmínky a princip NPS Extension for Azure MFA

Aby se dalo toto řešení využít, tak musíme splňovat některé hlavní podmínky

• provozovat On-Premises AD doménu
• uživatele synchronizovat do Azure AD
• uživatelé musí mít povoleno a nastaveno MFA (https://aka.ms/mfasetup)
• instalovaný Network Policy Server (NPS) - Windows server s instalovanou rolí Network Policy and Access Services (NPAS)

Při autentizaci se první faktor ověřuje vůči On-Premises AD a teprve druhý vůči Azure AD. Musíme mít stejné uživatele v obou AD a standardně se porovnávají podle User Principal Name (UPN). Pokud jsme při synchronizaci použili jiný atribut (pro Azure AD username) než UPN, tak musíme nastavit v registrech. Popis Alternate login ID.

HKLM\SOFTWARE\Microsoft\AzureMfa:LDAP_ALTERNATE_LOGINID_ATTRIBUTE

Průběh autentizace do SSL VPN

• uživatel (VPN klient) se hlásí k SSL VPN na FortiGate a zadává jméno a heslo
• FortiGate (RADIUS klient) pošle RADIUS zprávu Access-Request na NPS server (RADIUS server)
• NPS ověří primární autentizaci (jméno a heslo) vůči AD DS (pokud jsou splněny NPS politiky)
• pokud autentizace neprojde, tak NPS odpovídá RADIUS zprávou Access-Reject
• pokud je úspěšná, tak předává požadavek na NPS extension, které provádí sekundární ověření s Azure AD MFA
• Azure AD MFA získá údaje z Azure AD a provede sekundární ověření pomocí metody, kterou má uživatel nastavenu, v případě úspěchu vrací Security Token, který obsahuje MFA claim (vystaveno od Azure STS)
• pokud je ověření úspěšné (a celkově je spojení autentizované i autorizované), NPS server odesílá RADIUS zprávu Access-Accept

Průběh Azure AD MFA závisí na použité ověřovací metodě. Při notifikaci nebo telefonátu čeká MFA na potvrzení uživatelem (nebo timeout) a pak vrátí odpověď NFS rozšíření. Pokud jde o SMS nebo OATH token, vrátí NFS rozšíření zprávu, že je potřeba další validace. NFS server tuto informaci předá RADIUS klientovi a čeká na odpověď (ověřovací kód). Pokud přijde, tak se ověří v Azure AD MFA.

Chování RADIUS protokolu - opakované zprávy

RADIUS využívá UDP protokol. Pokud VPN server (FortiGate) nedostane odpověď do určité doby (timeout), tak předpokládá, že požadavek nedorazil na RADIUS server (NPS) a odešle jej znovu. Při standardním ověření odpovídá NPS server okamžitě, ale v případě MFA se čeká na určitou akci uživatele, která může trvat delší dobu. NPS server identifikuje další požadavky VPN serveru jako duplicitní a zahazuje je.

Když se podíváme do logů NPS serveru (Event log), tak můžeme vidět mnoho těchto zahozených požadavků. Je to normální chování. Oficiální popis RADIUS protocol behavior and the NPS extension. U zpráv je uveden důvod zahození požadavku.

The request was discarded by a third-party extension DLL file.

Microsoft doporučuje zvednout timeout na VPN serveru na 60 vteřin i více. FortiGate má defaultní hodnotu 5 vteřin a doporučuje nastavit 30 vteřin.

config user radius
    edit "Firma RADIUS"
        set timeout 30
    next
end

Odhaduji (možná se mýlím), že by se také měl zvednout globální timeout na vzdálené ověření.

config system global
    set remoteauthtimeout 60
end

Instalace a konfigurace NPS Extension for Azure MFA

Instalace

• stáhneme NPS Extension for Azure MFA ze stránek Microsoft
• spustíme soubor NpsExtnForAzureMfaInstaller.exe a projdeme krátkého průvodce

Konfigurace

Konfigurace spočívá ve spuštění PowerShell skriptu, který vytvoří self-signed certifikát podle zadaného Tenant ID a veřejný klíč přiřadí k Service Principal v Azure AD.

• spustíme Windows PowerShell jako administrátor

Pokud na serveru nemáme nainstalovaný Microsoft Azure Active Directory Module for Windows PowerShell (MSOnline), tak jej skript nejprve instaluje. K tomu je ještě potřeba NuGet provider. Pokud dostaneme chybu, že se jej nepovedlo stáhnout, tak je nejčastěji problém, že nemáme povoleno TLS 1.2 v .NET Framework. Povolíme pomocí

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

• spustíme skript

PS C:\> cd "c:\Program Files\Microsoft\AzureMfa\Config"
PS C:\Program Files\Microsoft\AzureMfa\Config> .\AzureMfaNpsExtnConfigSetup.ps1

• jako první se zobrazí přihlašovací dialog a musíme se přihlásit jako Azure AD administrátor

Connecting to Microsoft Azure. Please sign on as a tenant administrator.

• potom musíme do skriptu zadat Tenant ID (najdeme jej třeba v Azure Active Directory admin center - Overview)

Provide your Tenant ID For Self-Signed Certificate Creation:

• dokončí se nastavení a restartuje NPS služba

Od této chvíle je rozšíření aktivní a provádí druhé ověření v Azure MFA.

Kontroly, testy a troubleshootingcc

Network Policy Server

Pomocí Event Viewer (nebo PowerShell) se můžeme podívat na logy

• Network Policy and Access Services se nachází v Custom View - Server Roles
• NPS Extension for Azure MFA se nachází v Application and Services Logs - Microsoft - AzureMfa(hlavně AuthZ - AuthZOptCh)

Více info View Event Viewer logs for successful sign-in events, Troubleshooting.

FortiGate

Testy RADIUS na FortiGate jsme si popsali v článku FortiGate autentizace RADIUS, skupiny a MS NPS kapitole Troubleshooting (debug) RADIUS.

Autentizaci vůči RADIUS serveru můžeme vyzkoušet v GUI. Rozklikneme náš server a použijeme tlačítko Test User Credentials. Ale kompletně funkční je pouze pro metody notifikace nebo telefonát. Pokud je potřeba zadat ověřovací kód, tak se pouze zobrazí informace More validation is required, ale nedostaneme pole na zadání kódu. Vidíme zprávu z RADIUS serveru

AVP: l=40 t=Reply-Message(18) Value: 'Enter Your Microsoft verification code'

Pokud provedeme test příkazem v CLI, tak funguje i zadání ověřovacího kódu. V tom případě vidíme, že se nepředávají RADIUS atributy (třeba zařazení do skupiny). Pokud nemáme nastavený mechanismus PAP, tak spojení skončí na Failed (no response).

FW1 (FWINT) # diagnose test authserver radius "Firma RADIUS" pap bouska Heslo
Enter Your Microsoft verification code******
authenticate 'bouska' against 'pap' succeeded, server=primary assigned_rad_session_id=228953860 session_timeout=0 secs
idle_timeout=0 secs!

FortiClient SSL VPN přihlášení s NPS Extension for Azure MFA

Notifikace v mobilní aplikaci nebo telefonát

Jde o nejvíce použitelné MFA ověřovací metody. Ve FortiClient se standardně hlásíme jménem a heslem (můžeme mít nastaven i klientský (počítačový) certifikát). Začne připojování, které se zastaví na 45 %.

Pokud máme nastaveno ověření notifikací, tak nám na mobilním telefonu vyskočí schválení přihlášení.

Pokud máme vybrán telefonát, tak přijde automatický hovor z Microsoft Authentication. Sdělí nám, že přihlášení potvrdíme klávesou #. Pokud je vše v pořádku, tak se dokončí přihlášení a jsme připojeni do VPN.

Trochu hůře se chová přihlášení do webové VPN. Po odeslání přihlašovacího dialogu (Login) se nijak nezmění vzhled, takže nevím, zda se něco děje. Ale po potvrzení notifikace nebo telefonátu dojde k přihlášení.

Ověřovací kód - SMS, kód v mobilní aplikaci nebo hardware token

Přihlašování začne standardně, když se dostane na 45 %, tak se zobrazí zpráva (předaná z RADIUS serveru) a přidá se políčko Answer.

Pokud zadáme správný kód ze SMS, aplikace nebo HW tokenu, tak se dokončí přihlášení a jsme připojeni do VPN.

Nevýhoda, oproti standardnímu přihlašovacímu dialogu Azure AD MFA (a využití SAML) je, že se nám nezobrazují detaily. Třeba, že byla odeslána SMS na náš telefon nebo máme použít kód z aplikace. Stejně jako v předchozích případech, že se čeká na potvrzení v aplikaci.

Jak jsme si uvedli, tak tyto MFA ověřovací metody fungují pouze s RADIUS autentizací PAP. Pokud máme nastaveno něco jiného, tak se sice ve FortiClient zobrazí pole na zadání ověřovacího kódu, ale po jeho odeslání se posuneme na 50 % a nic neděje. Autentizace nakonec vyprší, navíc zobrazí zavádějící chybu RSA new pin wrong. (-7201).

Pokud máme použit PAP, ale z RADIUS serveru předáváme skupinu uživatele, která povolí přístup do VPN, tak připojení také neprojde, ale chyba se zobrazí rychle. V případě připojení do webové VPN vypadá trochu lépe.