Description
This article describes a step-by-step guide on how to configure and set up a SAML SSO login for Wi-Fi SSID using Azure AD as the IdP.
Scope
FortiGate v7.0.5 and later. Tunnel Mode SSID (Bridge Mode SSID is not supported with SAML authentication).
Solution
In v7.0.5 and later, a new feature has been added where the SAML authentication for Wi-Fi SSID can be configured with FortiGate as the wireless controller: Wireless Authentication using SAML Credentials 7.0.5
This article focuses on using Azure AD as the IdP. The steps remain the same if any other IdP is used.
Topology:
Configure Enterprise Application (SAML SSO) on Azure:
Setup Single Sign-On:
Once done, the SAML-based Sign-On page will show up where the FortiGate SP details have to be entered in the Basic SAML Configuration step.
Identifier (Entity ID): http://<FortiGate internal IP address>:1000/saml/metadata/
Reply URL (Assertion consumer Service URL): https://<FortiGate internal IP address>:1003/saml/login/
Sign on URL: https://<FortiGate internal IP address>:1003/saml/login/
Relay State: Optional
Logout URL: https://<FortiGate internal IP address>:1003/saml/logout/
- Download (Base 64) the IdP certificate and install it on the FortiGate – it needs to be selected in the SAML SP configuration.
- Login to FortiGate WebUI and then System -> Certificates -> Import -> Remote Certificate -> and upload the downloaded SAML Certificate (Base64).
Optional: May change the imported remote certificate to make sense of the certificate name (default imported naming 'REMOTE_Cert#' where # is a number [1-9]).
- Note the AzureAD ID (EntityID) and Login/Logout URLs as they need to be configured on the FortiGate.
Configure SAML on FortiGate:
Before configuring SAML on FortiGate, note the following:
By default, FortiGate uses a global feature where the FQDN/URL address of the captive-portal can be configured:
config firewall auth-portal
set portal-addr ""
end
The first request for Captive-Portal authentication is going to the URL or FQDN configured in set portal-addr "" because this feature is global. Check that there is nothing previously configured there. Since v7.0.6, captive portal authentication can also be configured directly in the interface.
By default, FortiGate uses port 1000 (HTTP) and port 1003 (HTTPS) for captive portal authentication. If using any different port, note those ports' numbers.
To get the port number configured on FortiGate, use the below command:
sh full-configuration | grep auth-http
set auth-http-port 1000
set auth-https-port 1003
Use these port numbers for SAML SP configuration.
config user saml
edit "saml-ad"
set entity-id "http://10.10.90.1:1000/saml/metadata/"
set single-sign-on-url "https://10.10.90.1:1003/saml/login/"
set single-logout-url "https://10.10.90.1:1003/saml/logout/"
set idp-entity-id "https://sts.windows.net/abc_can_be_random_string/"
set idp-single-sign-on-url "https://login.microsoftonline.com/abc_can_be_random_string"
set idp-single-logout-url "https://login.microsoftonline.com/abc_can_be_random_string"
set idp-cert "REMOTE_Cert_2"
set user-name "username"
set group-name "group"
set digest-method sha1
next
end
- The IP 10.10.90.1 is the internal interface IP (interface of Wi-Fi SSID).
- 1000 and 1003 are the auth-http and auth-https port.
- The entity-id, single-sign-on-url, and single-logout-url are to be configured on FortiGate. Use the above template and change the IP add accordingly.
- idp-cert is the certificate that was imported from Azure AD.
- The IdP details are the details noted from Step 3 in Azure AD.
- The user-name is the attribute name of user.displayname from Azure AD.
- The group-name is the attribute name user.group from Azure AD.
- Configure appropriate user groups in the Azure AD User and Groups.
- If the requirement is to have specific user groups able to connect, then note down the Object ID of that group, it will be later used in the FortiGate configuration.
- Edit the existing Group claim to add Name 'group' under Advanced options > All Groups.
- So that Azure sends all the groups the user is part of and can be controlled to whom to allow from the FortiGate.
In the case that FortiGate acts as a DNS server translating the IP of the SSID internal interface involved in the SAML authentication, it is necessary to validate if this FQDN is not being associated with the global configuration of the captive portal, because it must be configured at the interface level and not globally (in this case).
For example, if FortiGate has a DNS database in which the domain is "fgtlabtest.com.co" and the hostname is "fortigate-wifi-saml" with the IP of the SSID interface involved in the SAML authentication as follows:
config system dns-database
edit "1"
set domain "fgtlabtest.com.co"
config dns-entry
edit 1
set hostname "fortigate-wifi-saml"
set ip 10.10.90.1
next
end
next
end
The final FQDN associated with the internal IP that will receive the SAML requests will be: fortigate-wifi-saml.fgtlabtest.com.co
Use this FQDN in the auth-portal address for this SSID, or the firewall policy "set auth-redirect-addr" and also in the saml urls.
SAML URLs (Using FQDN):
config user saml
edit "saml-ad"
set entity-id "http://fortigate-wifi-saml.fgtlabtest.com.co:1000/saml/metadata/"
set single-sign-on-url "https://fortigate-wifi-saml.fgtlabtest.com.co:1003/saml/login/"
set single-logout-url "https://fortigate-wifi-saml.fgtlabtest.com.co:1003/saml/logout/"
set idp-entity-id "https://sts.windows.net/abc_can_be_random_string/"
set idp-single-sign-on-url "https://login.microsoftonline.com/abc_can_be_random_string"
set idp-single-logout-url "https://login.microsoftonline.com/abc_can_be_random_string"
set idp-cert "REMOTE_Cert_2"
set user-name "username"
set group-name "group"
set digest-method sha1
next
end
Auth-portal address for this SSID (Using FQDN):
end
From this point on, the configuration continues with the IP for the SAML authentication URL, not with FortiGate being the DNS server.
Configure User Group on FortiGate with SAML IdP as Member:
config user group
edit "saml_grp"
set member "saml-ad"
config match
edit 1
set server-name "saml-ad"
set group-name "<object Id of the grp from Azure>"
next
end
next
end
group-name is the Object-ID that was noted from Azure ID for the specific group.
In this example, only one specific group is allowed to authenticate. If all users/groups are required to authenticate, then ignore the config match part.
For Example:
config user group
edit "saml_grp"
set member "saml-ad"
next
end
Configure Address group to exempt from captive portal:
As the clients try to connect to the SSID, a Microsoft login will be prompted.
Hence, those destinations must be exempted from the Captive Portal so that the user can connect and log in for captive portal authentication.
In the majority of cases, the Azure IdP queries login.microsoftonline.com and sts.windows.net for authentication. If using Okta, Duo, or any similar service for 2FA, those destinations need to be exempted as well.
config firewall address
edit "sts.windows.net-for-saml"
set type fqdn
set fqdn "sts.windows.net"
next
edit "login.microsoftonline.com-for saml"
set type fqdn
set fqdn "login.microsoftonline.com"
next
end
Configure Firewall Policy to exempt the services to IdP for Authentication:
config firewall policy
edit <policy Id>
set name "saml-exempt"
set srcintf "CFS HQ"
set dstintf "virtual-wan-link"
set action accept
set srcaddr "all"
set dstaddr "login.microsoftonline.com-for saml" "sts.windows.net-for-saml"
set schedule "always"
set service "ALL"
set nat enable
set captive-portal-exempt enable
next
end
Alternatively, the ISDB object 'Microsoft Azure' can also be used as a destination in exempt policy rather than the FQDN object.
Firewall policy to exempt Duo or any similar services for 2FA:
edit <policy ID>
set name "saml-exempt-duo"
set srcintf "CFS HQ"
set dstintf "virtual-wan-link"
set action accept
set srcaddr "all"
set internet-service enable
set internet-service-name "Cisco-Duo.Security"
set schedule "always"
set nat enable
set comments “”
set captive-portal-exempt enable
next
Note:
Configure set captive-portal-exempt enable in these firewall policies so that the clients can reach this destination for authentication purposes. Make this change from CLI.
Configure SSID on FortiGate:
- Create an SSID that needs to be configured with SSO, assign the Interface IP (10.10.90.1 in this case), set up the DHCP server as required.
- In the Security Mode, select Captive Portal and Portal Type Authentication.
- And further, select the User groups as the SAML group (saml_grp in this case).
edit "CFS HQ"
set ssid "CFS HQ"
set security captive-portal
set selected-usergroups "saml_grp"
set security-exempt-list "CFS HQ-exempt-list"
set schedule "always"
next
'CFS HQ-exempt-list' is the destination group comprising login.microsoftonline.com and sts.windows.net address objects that were created.
This object will be automatically created once the address object is added in the Exempt Destination/Services part in GUI.
Configure Firewall Policy to allow internet post-authentication:
edit <policy ID>
set name "CFS SAML"
set srcintf "<Wi-Fi SSID Interface>"
set dstintf "virtual-wan-link"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set nat enable
set groups "saml_grp"
next
Increase the remote authentication timeout:
config system global
set remoteauthtimeout 60
next
Troubleshooting:
If firewall authentication fails after successful login to Microsoft, collect samld debugs, and note down the timestamp of testing.
diag debug console timestamp enable
diag debug app samld -1
diag debug enable
