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. Doplněno pár novinek z FortiOS 7.0.5.
Konfigurace spočívá v nastavení Azure AD, což znamená vytvoření Enterprise Application. A v nastavení FortiGate, kde vytvoříme SAML server, definujeme skupiny a vytvoříme nebo upravíme konfiguraci SSL VPN. Zde vyjdeme z toho, že máme SSL VPN nastavenu (podrobně jsme probrali v předchozích článcích) a budeme vytvářet nový SSL VPN Realm. Takže nám zůstane zachována VPN s původním ověřováním a přidáme nové připojení, kde se bude provádět SAML SSO vůči Azure AD.
Nejprve jsem zkoušel toto nastavení na FortiOS 6.2.9, ale vůbec nefungovalo. Debug SAML byl prázdný při všech pokusech. Když jsem provedl upgrade na FortiOS 6.4.6, tak vše začalo rovnou fungovat. Užitečné novinky přinesl další upgrade na FortiOS 7.0.5.
Nějaké zmínky uvádí, že plná podpora SAML je ve FortiClient od verze 6.4.0. Já jsem primárně testoval s FortiClient VPN 7.0.0.
Dokumentace
Řada věcí byla popsána v minulém článku.
Microsoft má pěkný článek, ale neřeší všechny detaily pro FortiGate.
Kdybychom nechtěli použít SAML, tak je tu ještě možnost pluginu na RADIUS server (Microsoft NPS).
Fortinet oficiální dokumentace.
- Configuring SAML SSO login for SSL VPN web mode with Azure AD acting as SAML IdP
- FortiOS 6.4.0 - SAML SP for VPN authentication
Nějaké návody z internetu.
- FortiGate SSL VPN with Azure MFA using SAML
- Azure SAML authentification for FortiGate SSL VPN (with Azure MFA)
Videa o konfiguraci na YouTube
- YouTube - Configure Fortigate SSL VPN to use Azure AD as SAML IDP (MFA / Conditional Access)
- YouTube - Implementation Guide - FortiGate SSL VPN with Microsoft Azure SAML 2FA
Konfigurace Azure AD
Konfigurace je docela dobře popsána v Microsoft článku Tutorial: Azure Active Directory single sign-on (SSO) integration with FortiGate SSL VPN. Navíc je tato část velmi podobná popisu v minulém článku FortiGate Admin HTTPS přihlášení pomocí SAML SSO vůči Azure AD.
Vytvoření Enterprise application z galerie
- Azure Active Directory admin center - Enterprise applications
- New application - vytvoříme novou aplikaci
- v galerii vyhledáme aplikaci FortiGate SSL VPN a klikneme na ni
- zadáme jméno (můžeme nechat originální) a klikneme na Create
Přiřazení uživatelů
- pod Manage klikneme na Users and groups
- přidáme Azure AD uživatele nebo skupiny, kteří se budou moci přihlásit do této aplikace (potažmo do SSL VPN)
Na FortiGate můžeme všechny uživatele zařadit do jedné skupiny a chovat se k nim stejně. Nebo využít skupiny v Azure AD, tento údaj předávat na FortiGate a podle něj vytvořit odpovídající skupiny.
Při použití skupin potřebujeme znát jejich Object Id. Po přidání skupiny ji rozklikneme a zkopírujeme si ID.
Nastavení SAML SSO
- pod Manage klikneme na Single sign-on
- jako SSO metodu vybereme SAML
Nastavíme jednotlivé části konfigurace kliknutím na Edit.
1 Basic SAML Configuration
Vytvoříme si nové FQDN, které použijeme pro SSL VPN Realm jako Virtual Host. Tento DNS záznam směrujeme na veřejnou IP adresu, kde FortiGate poslouchá pro SSL VPN. V příkladech použijeme vpn-sso.firma.cz
. Toto hostname použijeme v cestách níže. Kde to lze, musí být zatrženo Default.
- Identifier (Entity ID):
https://vpn-sso.firma.cz/remote/saml/metadata
- Reply URL (Assertion Consumer Service URL):
https://vpn-sso.firma.cz/remote/saml/login
- Sign on URL:
https://vpn-sso.firma.cz/remote/saml/login
- Logout Url:
https://vpn-sso.firma.cz/remote/saml/logout
2 User Attributes & Claims
- přidáme nový Add new claim, jméno
username
a hodnotu Source attribute vyberemeuser.userprincipalname
- editujeme existující claim s hodnotou
user.groups
a zadáme jménogroup
3 SAML Signing Certificate
- stáhneme a uložíme certifikát Certificate (Base64)
4 Set up FortiGate SSL VPN (je zde použit název aplikace)
- hodnoty odsud budeme potřebovat pro nastavení na FortiGate
- jde o SAML adresy Azure AD
Konfigurace FortiGate
Nahrání certifikátu
- (Global/VDOM) > System > Certificates - Import - Remote Certificate
Nahrajeme certifikát, který jsme stáhli z Azure AD. Dostane automatické jméno, které můžeme volitelně změnit v CLI.
FW (global) # config certificate remote FW (remote) # rename REMOTE_Cert_1 to Azure_SSO_VPN
Vytvoření SAML server záznamu pro Azure AD aplikaci
Nastavujeme připojení na Azure AD. Je to stejné jako konfigurace LDAP nebo RADIUS serveru (ale musíme provést v CLI, ve FortiOS 7.0 již lze i v GUI). Potřebujeme různé údaje z předchozích kroků, které použijeme v jednotlivých parametrech. Hodnoty musí přesně odpovídat údajům v Azure AD. Záznam si nějakým způsobem pojmenujeme (zde Azure.AD
) a název budeme používat při vytváření skupin.
config user saml edit "Azure.AD" set entity-id "https://vpn-sso.firma.cz/remote/saml/metadata" set single-sign-on-url "https://vpn-sso.firma.cz/remote/saml/login" set single-logout-url "https://vpn-sso.firma.cz/remote/saml/logout" set idp-entity-id "https://sts.windows.net/bb9528c8-3d14-4888-91fd-baeeb2XXXXXX/" set idp-single-sign-on-url "https://login.microsoftonline.com/bb9528c8-3d14-4888-91fd-baeeb2XXXXXX/saml2" set idp-single-logout-url "https://login.microsoftonline.com/bb9528c8-3d14-4888-91fd-baeeb2XXXXXX/saml2" set idp-cert "Azure_SSO_VPN" set user-name "username" set group-name "group" next end
Nastavované hodnoty
- první tři hodnoty jsou adresy FortiGate (zadávali jsme je v Azure AD aplikaci pod Single sign-on krok 1)
- další tři hodnoty Identity Provider (IdP) zkopírujeme z Azure AD aplikace Single sign-on krok 4
- následuje název certifikátu, který jsme nahráli na FortiGate (Single sign-on krok 3)
- poslední dvě hodnoty odpovídají pojmenování claimu z Azure AD aplikace Single sign-on krok 2
Volitelně můžeme také nastavit certifikát, který použije FortiGate při připojení k Azure AD.
set cert "Fortinet_Factory"
Vytvoření uživatelských skupin mapovaných na skupiny z Azure AD
Skupiny musíme vytvořit v CLI. Po vytvoření se skupina zobrazuje v GUI, ale nemá uvedené členy.
Zadáme odpovídající název skupiny a jako členy nastavíme definovaný SAML server, kterého jsme vytvořili v předchozím kroku. Pokud nám stačí jedna skupina, tak je to vše. Všichni uživatelé, kteří se ověří v rámci Azure AD aplikace, budou členy této skupiny.
Když chceme vytvořit více skupin, odpovídajících skupinám v Azure AD, tak definujeme pravidlo, kde jako Group Name zadáme Object Id skupiny v Azure AD.
config user group edit "G VPN VIP Azure" set member "Azure.AD" config match edit 1 set server-name "Azure.AD" set group-name "46a6ad2e-b977-4428-baa2-ff19e6fXXXXX" next end next end
Pozn.: Pokud k existující SSL VPN chceme přidat možnost přihlášení (nebo na něj přejít) přes Azure AD, tak je nejjednodušší k existující skupině doplnit SAML uživatele (a případně patřičný filtr). Nemusíme pak upravovat nastavení SSL VPN a politiky a vše rovnou funguje. Nevýhoda je, že u uživatelů nepoznáme, kde se ověřili (pokud máme ve skupině třeba LDAP a SAML, tak uvidíme pouze název skupiny). Pokud vytvoříme novou skupinu pro nový způsob ověření, tak podle jejího názvu rozlišíme způsob autentizace.
Vytvořené nového SSL VPN Realm
Můžeme používat pouze defaultní (root) VPN Realm, pak nemusíme řešit. Zde si vytvoříme speciální VPN Realm (URL adresu) pro přihlašování pomocí Azure AD.
- (VDOM) > VPN > SSL-VPN Realms
Vlastní VPN Realm můžeme vytvořit v GUI (musíme mít tuto vlastnost zobrazenu - Feature Visibility). Zadáme jeho jméno (zde sso
) a můžeme upravit přihlašovací obrazovku pro web (třeba změnit jméno pro jednodušší identifikaci). Pak musíme jít do CLI a nastavit Hostname (Virtual Host).
config vpn ssl web realm edit "sso" set virtual-host "vpn-sso.firma.cz" next end
Nastavení SSL VPN - přiřazení Realm a skupin
- (VDOM) > VPN > SSL-VPN Settings
V Authentication/Portal Mapping vytvoříme nové přiřazení skupiny, která obsahuje uživatele z Azure AD, VPN Realm, který jsme vytvořili v předchozím kroku, a připraveného VPN Portal (určuje specifické vlastnosti VPN připojení).
Úprava Firewall Policy - politiky pro komunikaci VPN klientů
- (VDOM) > Policy & Objects > Firewall Policy
Do existující politiky, pro komunikaci VPN klientů, přidáme skupinu uživatelů, která obsahuje uživatele z Azure AD. Případně vytvoříme novou politiku. Politika musí mít vstupní interface SSL-VPN Tunnel Interface
a jako zdroj zadáváme uživatelské skupiny a adresní rozsahy. Dokud není uživatel (skupina) součástí patřičné politiky, tak se nemůže přihlásit do VPN.
Nastavení časového limitu na přihlášení
Když použijeme SAML Login ve FortiClient, tak se otevře přihlašovací dialog z externího systému (Azure AD). Defaultně je zde nastaven timeout 10 vteřin. Za tu dobu řada lidí nestihne zadat své přihlašovací údaje, takže je nutné tuto hodnotu zvětšit.
config system global set remoteauthtimeout 60 end
Debug SSL VPN a SAML
Pro řešení problémů je nejlepší zapnout v CLI debug režim pro určitou oblast. Základní je debug vlastního SAML protokolu.
diagnose debug application samld -1
K tomu můžeme přidat debug SSL VPN.
diagnose debug application sslvpn -1
Volitelně také debugování autentizace Remote user authentication (fnbamd
je Fortinet non-blocking authentication daemon). To zobrazuje zprávy ze všech metod vzdáleného ověření (je jich většinou mnoho).
diagnose debug application fnbamd -1
Můžeme povolit zobrazení času u jednotlivých záznamů a celkově zapneme debug.
diagnose debug console timestamp enable diagnose debug enable
Pro vypnutí debug režimu můžeme použít.
diagnose debug disable diagnose debug reset
Přihlášení do SSL VPN pomocí SAML SSO
Webové rozhraní
Pokud máme na daném SSL VPN Realm definovánu pouze ověřovací metodu SAML (přiřazeny skupiny mapované na SAML), tak po otevření stránky dojde automaticky k přesměrování na SAML přihlášení. Pokud máme skupiny z různých autentizačních metod, tak se zobrazí přihlašovací dialog doplněný o tlačítko Single Sign-On.
FortiClient VPN
Připojení ve FortiClient vytvoříme tak, že zadáme adresu, kterou jsme definovali pro VPN Realm (Remote Gateway), a zatrhneme Enabel Single Sign On (SSO) for VPN Tunnel.
Při připojování se nezadává jméno a heslo, ale je zde tlačítko SAML Login, které vyvolá vzdálené ověření u Microsoftu.
Důležité je to, že pro autentizaci se neotevírá nějaký prohlížeč instalovaný v OS, ale integrovaný prohlížeč ve FortiClient. Ten se v Azure AD identifikuje jako Chrome 69.0.3497 (stejně z Windows, Linux i MacOS).
Použití vícefaktorové autentizace (MFA) pomocí Conditional Access
Jedním z důvodů, proč nastavovat ověřování VPN uživatelů vůči Azure AD, může být snaha zvýšit bezpečnost přihlašování. Dnes je stále více požadována vícefaktorová autentizace. Tu můžeme řešit i přímo na FortiGate, jak je popsáno v FortiGate dvoufaktorová autentizace s použitím OTP. Ale Azure AD nabízí více možností.
MFA (Multi-Factor Authentication) v Azure AD můžeme mít zapnuto na vše nebo řídit pomocí Conditional Access policies a zapnout jen pro určité aplikace. Obecné informace v článku Azure AD přihlašování bez hesla a vícefaktorové ověření (MFA).
Dobrá možnost je vytvořit Conditional Access politiku, která vyžaduje MFA (Require multi-factor authentication). Tu nastavit na naši Enterprise aplikaci, kterou jsme zde nazvali FortiGate SSL VPN. Detailnější postup je uveden v Azure AD Conditional Access.
Identifikace firemních zařízení při přístupu do VPN
Myslím, že je legitimní požadavek (některé normy vyžadují, že do interní sítě můžeme pustit pouze spravovaná zařízení), když chceme dovolit připojení do (určitého typu) VPN pouze z firemních či schválených počítačů. Ale jak je při připojení identifikovat?
Kontroly na klientovi
Jedna možnost by mohlo být provádět určité kontroly na klientovi (Host Check). Na to ale potřebujeme placenou verzi FortiClient (není podporováno ve verzi zdarma FortiClient VPN 6.2 a novější).
Podle informací bylo opět doplněno do zdarma verze FortiClient VPN 7.0.3 - FortiGate-powered host check for free VPN client.
Ověření počítačovým certifikátem
Další možnost je vystavit daným počítačům certifikát. Na VPN připojení se nastaví jeho vyžadování. Ve FortiClient se certifikát vybere a ten jej na začátku spojení použije (následuje standardní přihlášení jménem a heslem).
Problém ovšem je, když chceme využít SAML. Jakmile ve FortiClient zatrhneme Enabel Single Sign On (SSO) for VPN Tunnel, tak zmizí možnost vybrat Client Certificate. Zkoušel jsem vše nastavit přes XML konfigurační soubor, ale FortiClient certifikát při připojení na FortiGate nepoužije.
Conditional Access a Azure AD Joined nebo Compliant zařízení
Tuto oblast jsem nově popsal v článku Fortigate SSL VPN s Azure AD MFA z počítačů v doméně.
- How To: Require managed devices for cloud app access with Conditional Access
- Azure AD Conditional Access
Jako nejlepší mi připadá využít vlastností Azure AD. V Conditional Access politice můžeme povolit přístup pouze z určitých zařízení (Compliant Device Requirement).
Jsou zde dvě hlavní volby
- Require Hybrid Azure AD joined device
- Require device to be marked as compliant
Při přihlášení dojde také k ověření zařízení (Device Authentication) a celá autentizace projde, pokud se úspěšně ověří uživatel a jsou splněny dané podmínky. V politice tedy můžeme nastavit, že pro přihlášení do FortiGate SSL VPN je požadováno zařízení připojené do domény (Hybrid Azure AD Join). Pokud použijeme Microsoft Edge a přihlásíme se do webové SSL VPN. Tak se ze zařízení v doméně připojíme. Pokud v doméně není, tak dostaneme informaci a nepřipojíme se.
Doplněno. Pokud máme nové verze FortiOS i FortiClient, tak je to opravdu nejlepší možnost. Doplňoval jsem informace níže a nyní mám prakticky odzkoušeno. Pro autentizaci využijeme externí (defaultní) prohlížeč. Podporován je Edge, Chrome i Firefox (vše na Windows, podle dokumentace má něco fungovat i na macOS, ale to jsem zatím nerozchodil). V Conditional Access politice povolíme přístup pouze z Hybrid Azure AD joined device (asi stejně by fungovalo vyžadování compliant pomocí Intune). Při přihlašování dojde k Device Authentication, a pouze pokud projde, tak jsme přihlášeni. Hodit se může, upravit v Conditional Access politice položku Session - Sign-in frequency, na nějakou rozumnou hodnotu (několik hodin). Protože jinak, ve většině případů, probíhá mnoho dní automatické přihlášení (SSO). Což do VPN nemusí být úplně bezpečné (pokud nemáme super zabezpečené počítače a příhlášení do nich).
Problém je, když se zkusíme připojit pomocí FortiClient. I když se připojujeme ze správného zařízení, tak se nepřipojíme. Dostaneme informaci, že náš prohlížeč není podporován.
Zjištění podrobností specifických pro zařízení (Device-Specific Details) vyžaduje ověření zařízení (Device Authentication). To je podporováno pouze na určité kombinaci operačního systému a prohlížeče Supported browsers. Na Windows 10 je podporován Microsoft Edge (uživatel v něm musí být přihlášen), Internet Explorer a Google Chrome po instalaci rozšíření Windows 10 Accounts.
Doplněno - podpora byla přidána také do Firefox od verze 91. Musí se nejprve povolit v nastavení Privacy & Security - Allow Windows single sign-on ... (Windows SSO).
Problém je, že FortiClient používá integrovaný prohlížeč, který nepodporuje zjištění informací o zařízení. Nemůžeme tedy využít těchto omezení v Azure AD.
Doplněno 27.8.2021 - FortiClient SAML autentizace v externím prohlížeči
Zjistil jsem, že do FortiClient 7.0.1 byla doplněna možnost (zatržítko v konfiguraci VPN připojení) Use external browser as user-agent for saml user authentication
. Ta je k dispozici, pokud zapneme Enable Single Sign On (SSO) for VPN Tunnel. Případně se dá nastavit v XML konfiguraci
<use_external_browser>1</use_external_browser>
Našel jsem pěkný popis v článku Using a browser as an external user-agent for SAML authentication in an SSL VPN connection. Bohužel je potřeba i konfigurace na FortiGate, která je k dispozici až od FortiOS 7.0.1.
config vpn ssl settings set saml-redirect-port 8020 end
Takže jsem to prakticky nevyzkoušel. Pokud se nastaví FortiClient 7.0.1, tak k žádné změně nedojde a stále se otevírá integrovaný prohlížeč.
Doplněno 4.4.2022 - provedl jsem upgrade na FortiOS 7.0.5 (kde je řada problémů) a vyzkoušel, že opravdu funguje použití defaultního prohlížeče. FortiClient otevírá v prohlížeči adresu https://127.0.0.1:8020
(podle definovaného portu na FortiGate).
Kvůli testům jsem zkusil Host Check a FortiClient VPN 7.0.1 (a SAML autetnizaci), kde by tedy neměl fungovat a neměl bych se připojit do VPN. K mému překvapení jsem se bez problémů připojil. Zkusil jsem hledat a v mnoha verzích FortiClient je uveden bug 709001 SSL VPN host check validation does not work for SAML user.
Zkusil jsem jinou autentizaci a nepřipojil jsem se. Ale přijde mi, že bug ve FortiClient by neměl obejít kontrolu na FortiOS. Navíc ve FortiClient 7.0.1 mělo být opraveno. Tak nevím.
Skúsil som to na FortiGate 61E - 6.4.6 + FortiClient 6.4.1 a funguje to až prekvapivo dobre. Ďakujem za super článok ;-)
Mám otázku: dajú sa vo firewalle aplikovať pravidla podľa užívateľov?
Teraz môžem pracovať len so skupinami
Nefunguje připojení z FortiClienta 7.0.7 při aktivní kontrole host-check (known issue #727695).
"Když chceme vytvořit více skupin, odpovídajících skupinám v Azure AD, tak definujeme pravidlo, kde jako Group Name zadáme Object Id skupiny v Azure AD" - mozte mi to prosim niekto vysvetlit? Lebo ked pridam dalsiu skupinu tak mam chybu "SAML group mismatch". Uzivatelia s prvej funguju ale z druhej skupiny nie.
odpověď na [4]Tomas: Když to nastavíte správně, jak je uvedeno v popisu, tak to funguje. Předáváte správně atribut skupiny? Případně jestli jsou skupiny správně definovány na obou stranách.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Azure-SAML-group-mismatch-getting-error-remote/ta-p/204991
Dobry den,
omylom som dal rovnake Object ID. Uz to funguje. Dakujem za pomoc ;-)
Ahoj, diky za super navod, vse funguje perfektne, akorat mam problem, pri prihlaseni pres saml to napise invalid certificate a musim dat continue unsafe, v ssl settings mam certifikat fortinet_factory, je potreba si vygenerovat lets encrypt? Bohuzel mame jen jednu public ip a na ni je mail server. Setkal jste se s timto problemem? Dekuji
Super clanek, stale aktualni, diky. Funguje to 99% OK, momentalne resim to 1% :))) jednoho uzivatele (forticlient v.7.4.0.1658), ktery ma problem, v SAML response AD posila misto jednotlivych skupin proste "groups.link" (s odkazem na microsoft graph)...
Nasel jsem
Notes:
If the number of groups the user is in goes over a limit (150 for SAML, 200 for JWT) then an overage claim will be added the claim sources pointing at the Graph endpoint containing the list of groups for the user.
zdroj: (https://learn.microsoft.com/en-us/entra/identity-platform/reference-saml-tokens)
ale muj uzivatel zda se nepresahuje 150 skupin... takze resim dal...
odpověď na [8]Martin57: Toto je zajímavá informace a možná jsem narazil na to samé. Používáme spoustu on-prem skupin a někteří uživatelé jsou členem třeba 80. Řešil jsem již problémy s Kerberos SSO www.samuraj-cz.com/clanek/kerberos-autentizace-a-clenstvi-ve-skupinach/.
Replikaci do Entra ID jsme dělali postupně. Až jsme si řekli, že tam dáme vše a v tu chvíli přestalo několika lidem fungovat přihlášení do VPN. Napadla mne hned souvislost s počtem skupin, tak jsem nedůležité vyřadil z replikace a přihlášení zase fungovalo.
Dále jsem nepátral. A řekl bych, že 150 skupin jsme nedosáhli. Ale s počtem skupin to bude souviset.