Description
This article describes how to leverage SAML authentication for Wireless Captive Portal authentication using Azure as SAML IdP.
The configuration example provided encompasses Azure SAML application configuration with multiple groups.
Scope
FortiGate v7.0.5+ and Azure as SAML IdP.
Tunnel Mode SSID (Bridge Mode SSID is not supported with SAML authentication).
Solution
SAML authentication is immensely deployed in FortiGate's SSL VPN and Administration.
Starting with v7.0, it is possible to authenticate users for forward traffic in firewall policies and proxy traffic in explicit and transparent proxy features.
Starting with v7.0.5, users can also authenticate to Wireless SSIDs using their Azure AD Credentials using the SAML method.
This document will focus on Wireless Authentication with Microsoft Azure as SAML IDP.
Additionally, multiple-group scenarios will be described to allow for more granular control for UTM Security Profiles applied to users based on their group membership.
Example Environment:
Clients: 172.16.70.240 and 172.16.70.241
FortiGate SSID Interface IP: 172.16.70.15
User sales@robertao.me is member of Azure group Sales Group
User development@robertao.me is member of Azure group Development Group
SAML SP: FortiGate
SAML IdP: Microsoft Azure
Configuration Steps for Microsoft Azure SAML Application.
Note.
This configuration assumes users and groups are already created in Azure. Some steps are performed concurrently on the FortiGate
- Create a non-gallery application as per below and define a name for it:
- Once the application has been deployed, select it and assign users and groups as desired:
Note.
Depending on the Azure AD plan, groups cannot be directly assigned to the SAM application, and users will have to be individually assigned.
However, group membership can still be used for SAML Assertions; therefore, multiple-group scenarios can be configured in FortiGate.
- Make a note of the group Object ID that can be used for group matching in FortiGate:
- Configure the SSO URLs for the SAML Application newly created:
Reply URL (Assertion Consumer Service URL) will contain the IP Address and port of the FortiGate Captive portal.
By default, the captive portal IP address will be the FortiGate Interface IP of the SSID to which clients are connecting. Additionally, the default Captive portal for HTTPS connection is 1003.
config system global
set auth-https-port 1003
end
- Configure the Attribute and Claims for the SAML Application newly created:
A username claim is mandatory, but a group claim is optional.
However, the claim name must match with 'user-name" and "group-name' attributes/claims configured in FortiGate.
Note.
Claim names are case-sensitive attributes.
- Username claim details.
- Group claim details.
Note.
For group claims, if the claim name is not customized as screenshot above, Azure will prepend the Namespace to the claim name, and that may cause a mismatch in the attribute configured in FortiGate.
- Download the certificate in Base64 format to be imported later on to FortiGate.
- Make a note of the IdP URLs that will be used in the FortiGate configuration.
Configuration steps in FortiGate.
- Import IdP certificate as downloaded in previous step 8). Import it under the 'Remote Certificate' option.
Note.
The new certificate appears under the Remote Certificate section with the name REMOTE_Cert_(N).
Optionally, rename the certificate in the CLI to give it a more recognizable name:
config vpn certificate remote
rename REMOTE_Cert_3 to AZURE-SAML-Wireless
end
2. Enable Captive Portal Option as per screenshot
3. Create a new Single Sign-On server matching the IdP settings configured previously in Azure.
Note.
Starting with FortiOS 7.0.2 it is possible to create SAML server from GUI; however, the SP URL's will populate automatically and will be needed to be modified after saving it.
Optionally, the new Single Sign-On server can be created from CLI as per below:
config user saml
edit "azure-saml-wireless"
set cert "Fortinet_Factory"
set entity-id "https://172.16.70.15:1003/saml/metadata"
set single-sign-on-url "https://172.16.70.15:1003/saml/login"
set single-logout-url "https://172.16.70.15:1003/saml/logout"
set idp-entity-id "https://sts.windows.net/0a356c-55e6-4e3a-98-726a910b175/"
set idp-single-sign-on-url "https://login.microsoftonline.com/0a356c-55e6-4e3a-98-726a910b175/saml2"
set idp-single-logout-url "https://login.microsoftonline.com/0a356c-55e6-4e3a-98-726a910b175/saml2"
set idp-cert "AZURE-SAML-Wireless"
set user-name "username"
set group-name "group"
set digest-method sha1
next
end
Note.
As with any other command to be pasted in FortiGate CLI that contains a question mark '?', there is the need to press 'CTRL + V' right before pasting the special character '?'.
This will not work from the CLI java console and will need a terminal software such as Putty with SSH or a Console connection.
4. Create user groups to assign to different firewall policies:
From CLI:
config user group
edit "SAML-AZURE-Development-Wireless"
set member "azure-saml-wireless"
config match
edit 1
set server-name "azure-saml-wireless"
set group-name "8cd85213-773b-46dc-afd3-5cc8edcfc18"
next
end
next
end
config user group
edit "SAML-AZURE-Sales-Wireless"
set member "azure-saml-wireless"
config match
edit 1
set server-name "azure-saml-wireless"
set group-name "433c2809-4ae2-4589-80e1-7cfc3fac2a57"
next
end
next
end
5. Create the SSID or modify the existing one as desired, and set the authentication type to Captive Portal.
Note.
If the 'DNS Server' option under the 'DHCP Server' section is set to 'Same as Interface IP', make sure the SSID Interface is added under Network>>>DNS Servers.
It may be necessary to enable the option 'DNS Database' from System -> Feature Visibility.
Alternatively, this can be done from CLI as per the example below. Replace 'SAML-WiFi' with the SSID name created.
config system dns-server
edit "SAML-WiFi"
next
end
6. Create an outbound firewall policy to exempt the Microsoft Azure IdP Login page from the Captive portal.
Note.
ISDB Object 'Microsoft Azure' can be used as a destination rather than those three FQDNs; however, that will cause Captive Portal to not pop up automatically upon connection to SSID.
However, it would come up whenever the user initiates web browsing to non-Azure URLs.
Note.
For 'Advanced' options to be displayed in firewall policies in GUI, the feature visibility option 'Policy Advanced Options' needs to be enabled.
This includes the option 'Exempt from Captive Portal'.
Alternatively, it can be done from the CLI option 'set captive-portal-exempt enable' as per below.
config firewall policy
edit 6
set name "SAML-AZURE-Wireless-Captive-Portal"
set srcintf "SAML-WiFi"
set dstintf "wan1"
set action accept
set srcaddr "all"
set dstaddr "login.microsoftonline.com" "sts.windows.net" "aadcdn.msauth.net"
set schedule "always"
set service "HTTPS"
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set logtraffic all
set nat enable
set captive-portal-exempt enable
next
end
config firewall address
edit "sts.windows.net"
set type fqdn
set fqdn "sts.windows.net"
next
end
config firewall address
edit "login.microsoftonline.com"
set type fqdn
set fqdn "login.microsoftonline.com"
next
end
config firewall address
edit "aadcdn.msauth.net"
set type fqdn
set fqdn "aadcdn.msauth.net"
next
end
7. Create outbound firewall policies as desired for all other traffic after authentication is complete.
config firewall policy
edit 5
set name "SAML-AZURE-Wireless-Development"
set srcintf "SAML-WiFi"
set dstintf "wan1"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set av-profile "SAML-Wireless-Development"
set webfilter-profile "SAML-Wireless-Development"
set logtraffic all
set nat enable
set groups "SAML-AZURE-Development-Wireless"
next
end
config firewall policy
edit 7
set name "SAML-AZURE-Wireless-Sales"
set srcintf "SAML-WiFi"
set dstintf "wan1"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set av-profile "SAML-Wireless-Sales"
set webfilter-profile "SAML-Wireless-Sales"
set logtraffic all
set nat enable
set groups "SAML-AZURE-Sales-Wireless"
next
end
8. Configuring the user authentication setting.
When a user connects to the SSID and initiates traffic matching previously created firewall policies, FortiGate will redirect the user to the firewall authentication captive portal before redirecting them to the SAML IdP portal.
After the SAML IdP responds with the SAML assertion, the user is again redirected to the firewall authentication captive portal.
If the firewall portal’s certificate is not trusted by the user, the user will receive a certificate warning.
Use a custom certificate that the user trusts to avoid the certificate warning.
To configure a custom certificate:
- Go to User & Authentication -> Authentication Settings.
- For the Certificate, select the custom certificate. The custom certificate’s SAN field should have the FQDN or IP from the SP URL.
Note.
Alternatively, assigning a CA certificate allows the FortiGate to automatically generate and sign a certificate for the portal page.
This will override any assigned server certificate. In this example, the built-in Fortinet_CA_SSL is used.
To assign a CA certificate:
config user setting
set auth-ca-cert "Fortinet_CA_SSL"
set auth-secure-http enable
set auth-timeout 2
set auth-ssl-min-proto-version TLSv1-2
end
Go to System -> Certificates and download the certificate and install the certificate into the client’s certificate store.
Note.
If the Captive portal is already being used for other features, redirection can be enabled per firewall policy by setting 'auth-redirect-addr. as per the related article below:
Additionally, starting with v7.0.5 and v7.2.0, the certificate and portal address can be configured per SSID directly under the SSID settings in CLI.
config wireless-controller vap
edit "SAML-WiFi"
set auth-cert "Wildcard_Colombas"
set auth-portal-addr "wifi.colombas.lab"
end
Verification of Configuration and Authentication Workflow.
- The user connects to the SSID and initiates traffic matching previously created firewall policies.
- The FortiGate redirects to the local captive portal port (default is 1003) and then redirects the user to the SAML IdP.
- The user connects to the Azure login page for the SAML authentication request.
- The SAML IdP sends the SAML assertion containing the user and group.
- The browser forwards the SAML assertion to the SAML SP.
- If the user and group are allowed by the FortiGate, the user is allowed to access the internet.
On the client, connect to the SSID. The default web browser will be launched with the Azure login page. Enter the user credentials. If the login attempt is successful, the user is allowed to access the internet according to group membership and firewall policies defined.
To verify user login logs, go to Dashboard -> Users & Devices and select the Firewall Users widget.
Alternatively, list users from CLI as per the commands below:
FGT61F-LEFT (root) # diag firewall auth filter method fw
FGT61F-LEFT (root) # diag firewall auth list
172.16.70.240, development@robertao.me
src_mac: 30:d1:6b:ec:a5:61
type: fw, id: 0, duration: 461, idled: 25
expire: 275, allow-idle: 300
flag(100): wsso
server: azure-saml-wireless
packets: in 10631 out 7298, bytes: in 10496942 out 1397557
group_id: 4
group_name: SAML-AZURE-Development-Wireless
172.16.70.241, sales@robertao.me
src_mac: 06:34:46:de:43:07
type: fw, id: 0, duration: 8, idled: 3
expire: 297, allow-idle: 300
flag(100): wsso
server: azure-saml-wireless
packets: in 929 out 631, bytes: in 854518 out 70233
group_id: 5
group_name: SAML-AZURE-Sales-Wireless
----- 2 listed, 0 filtered ------
To verify user login logs, go to Log & Report -> System Events and select the User Events card.
Alternatively, list from CLI commands below:
FGT61F-LEFT (root) # execute log filter category event
FGT61F-LEFT (root) # execute log filter field subtype user
FGT61F-LEFT (root) # execute log display
119 logs found.
10 logs returned.
2.0% of logs has been searched.
date=2022-09-11 time=14:36:43 eventtime=1662932203656627740 tz="-0700" logid="0102043008" type="event" subtype="user" level="notice" vd="root" logdesc="Authentication success" srcip=172.16.70.241 dstip=172.16.70.15 policyid=0 interface="SAML-WiFi" user="sales@robertao.me" group="SAML-AZURE-Sales-Wireless" authproto="HTTPS(172.16.70.241)" action="authentication" status="success" reason="N/A" msg="User sales@robertao.me succeeded in authentication"
date=2022-09-11 time=14:29:11 eventtime=1662931751149409120 tz="-0700" logid="0102043008" type="event" subtype="user" level="notice" vd="root" logdesc="Authentication success" srcip=172.16.70.240 dstip=172.16.70.15 policyid=0 interface="SAML-WiFi" user="development@robertao.me" group="SAML-AZURE-Development-Wireless" authproto="HTTPS(172.16.70.240)" action="authentication" status="success" reason="N/A" msg="User development@robertao.me succeeded in authentication"
An example of a failed attempt is if the group ID object sent in the SAML assertion does not match the one configured in the FortiGate group.
date=2022-09-11 time=14:23:28 eventtime=1662931408325814000 tz="-0700" logid="0102043009" type="event" subtype="user" level="notice" vd="root" logdesc="Authentication failed" srcip=172.16.70.240 dstip=172.16.70.15 policyid=0 interface="SAML-WiFi" user="development@robertao.me" group="N/A" authproto="HTTPS(172.16.70.240)" action="authentication" status="failure" reason="No matched SAML user or group name in auth resp" msg="User development@robertao.me failed in authentication"
