Updated Google iDP SAML Fortigate Captive Portal Setup Instrictions @agrakov

[microchipmatt]

@agrakov  Do you have clearer pictures for this article you created?
https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-Wi-Fi-configuration-with-Google-...

I cannot see the pictures properly for the settings. As well, do you have an updated article, that allows one to do this via the GUI since 7.XX.XX allows this to be done from the GUI? Since it's all command line I'm having trouble visualizing where some of the settings go. Any Help would be greatly appreciated. I would also need to modify it for my needs. Here are my needs:

1. Instead of only SSID Interface facing users, I would like ALL Internal Interface users to be forwarded to the Google Saml iDP as the captive portal for sign in. So the captive portal would be turned on, on the internal interface

2. There would be 2 Google groups, students and staff, when staff  authenticate they would be assigned a specific Secuirty profile for filtering, when Student log in they would get their own more strict Secuirty profile filter

3. Certain servers/services would have the option to completely BYPASS the captive portal and have the full access to the internet or access they need (Captive portal does not apply to them)

Any help would be greatly appreciated.

[amrit]

I would recommend checking these article and document links

1.https://docs.fortinet.com/document/fortiap/7.4.4/fortiwifi-and-fortiap-configuration-guide/806280/ca...

2. https://community.fortinet.com/t5/FortiGate/Technical-Tip-Wireless-Authentication-using-SAML-Credent...

3. https://docs.fortinet.com/document/fortigate/7.0.0/new-features/561062/wireless-authentication-using...

4. https://community.fortinet.com/t5/FortiGate/Technical-Tip-Setting-up-a-captive-portal-for-network/ta...

[microchipmatt]

Okay, I have it working 90%, and I switched it to a Pure Google SAML iDP setup instead of Azure. I also made my internal LAN port the Captive portal INSTEAD of the wireless-facing interface. That ALL went well, but I am still having a weird issue. I am having the same issue with the Google SAML iDP setup as I did with the Azure SAML setup. I thought it was an Azure SAML issue, but turns out it was not. Allow me to explain because maybe you have some ideas that can help me.

Once I set everything up, including the rules for the Groups and the bypass rule for Google DNS, web and Oauth, NO MATTER what site I go to, I have a certificate error on any website. This is NOT the certificate error that is related to the portal, as far as I can tell. The reason I say this is that I have an Internal DNS record set up for the Captive portal forwarding that is happening with SAML, and I am using a wildcard certificate. Basically, I have an internal DNS record that matches the SAN of the wildcard Certificate, As an example:

filter.mysystem.school A IPAddressOfInternalInterface (Captive portal DNS Record) [Not my real full DNS record for security reasons, but premise is the same]

Before I turn the captive portal on, this record has been tested, and it matches the wildcard certificate perfectly with NO complaints. it matches the SAN on the wildcard certificate, and it says everything is secure with NO warning messages from the browser (See screenshot). As soon as I turn on the Captive portal, EVERY website visited from the browser becomes insecure, and I can't bypass it. As far as I can tell, SAML is working, as it is trying to visit the sites, but EVERYTHING is marked as insecure even though the Certificate for the DNS records has been tested and is working. I am unsure as to why this is, since in my mind all my t's and i's seem to be crossed and dotted. This happened weather it was an Azure SAML or Pure Google SAML setup (We sync to both). In my mind, with the settings I have, the Google Login Oauth screen *should* become the captive portal. SAML should look at the DNS forwarder, for authentication, and immedatly forward to the Google Login screen if the user is NOT authenticated. If the user is authenticarted with google already and is a part of an Approved group, then the user should hit the Rule for that group on the fortigate and they the policy serttings and should surf at that point. But instead, I cam getting the insecure errors, even wioth the Matched SAN that was tested as working. Any ideas?