Captive portal Authentication with Google

[VirgilW]

I am trying to configure an Captive Portal employee SSID on a Fortigate 60F that would allow users to sign-in with their Google Workspace email address to sign them in. Is it possible? Any help would be appreciated. We don't have FortiAuthenticator so option will not work for us. FortiGate FortiManager 

[dbu]

Hi @VirgilW ,

Have a look at this article and let me know if this is the solution you are looking for. 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-Wi-Fi-configuration-with-Google-...

[microchipmatt]

Do you think I could replace the SSID IP Interface (SP) with the IP address on the Internal Facing Interface and turn on the Captive portal on that, and then Google SAML SSO will because the captive portal for ALL users hitting that interface (SP)? That way, all users who are part of a Google group are automatically authenticated with a Security Profile applied to those groups, which means they could then get different security.  I could also exempt any devices that I want to have internet access no matter what. That way, I am applying different levels of a security profile, for instance, Student and Staff groups, once authenticated (And since Google is the SAML SSO if they are already logged in, they just get their security profile based on their group), and then all exempt Subnets get approval. I think switching it this way is possible, but I just want to conform.  

[Emandel]

Hi! I have the same scenario and I have a problem that I couldn't resolve.

I allowed Google-Web services for the login, but this allow the access to connectivitycheck.gstatic.com too. So, Android phones not know that they have to login in captive portal.

I tried some configurations: blocking URL, changing DNS resolutions, etc, but couldn't resolve that. Could you?

[dbu]

Hi @Emandel ,

I am not sure what do you mean with "allow the access to connectivitycheck.gstatic.com too. So, Android phones not know that they have to login in captive portal." 

Can you try with a different browser on your android phone ?

Usually, errors happen due to misconfiguration. Verify your configuration with the link above and try to run the debugs at the end of the article as you might understand more about the issue of failure.  

[Emandel]

Hi! Thanks for your answer.

The problem is Android phones check Internet connectivity doing a GET to http://connectivitycheck.gstatic.com/generate_204.

- If it returns OK, it means the wifi network is working OK (Android says "Connected")

- If it returns a redirect (302), it means the wifi network is forwarding to a captive portal (the mobile phone detects that you have to login and says "Sign in to network")

- If it hasn't response, it means there isn't connectivity ("Connected without Internet")

If you allow the "Google-Web" Internet Service, you are allowing this GET too... so, Android doesn't know that you have to sign in and says "Connected". The users connect to the network and don't know they haven't Internet until they want to navigate. Certainly, they try to navigate on HTTPS pages, which causes the redirection to the captive portal to warn of an invalid certificate. If only Android could natively open the portal, this wouldn't happen.

I tried denying the destination with a FQDN Address but the IP address is shared with accounts.google.com and users can't login.

[dbu]

Thank you for clarifying. 

It looks like when the google authentication policy is enabled it overlaps with some FQDN that android needs to check regarding the captive portal. 
If android in your case is using HTTP to perform his checks you can try a possible workaround to specify only "HTTPS" on the Google's authentication policy and see the behavior.

[Emandel]

Hi, thank you very much! Finally I tried creating the policy allowing *.google.com and *.gstatic.com only with HTTPS service. This worked very good!!

Thank you very much

[Emandel]

Hello again, just wanted to mention that I was having some issues with certain devices (Mac and Chromebook). Using an old FortiAuthenticator documentation, I seem to have found the ultimate solution:

1. Firewall policy allowing DNS request
2. Firewall policy allowing HTTPS service to the next destinations:
   1. www.googleapis.com
   2. accounts.google.com
   3. ssl.gstatic.com
   4. fonts.gstatic.com
   5. 172.217.9.0/24
   6. 216.58.192.0/19
   7. accounts.google.com.ar (because I am from Argentina)

We are still testing, but it seems to be working fine now!!

Hopefully, it will be useful to someone.