Fortigate wifi external portal authentication with FortiAuthenticator

[Fabio]

My Fortigate environment for wifi guest user is a external authentication portal by FortiAuthentication; i replace the Fortinet certicate SSL with my own CA ( Sectigo ) to avoid warning certificate from browser.
The workflow begin with the external page of FortiAth " https://fac.xxzxzxzxx.YY/portal"; authentication is processed by Fortiauth but the browser goes redirect at internal page in this url "10.12.0.1:1000/fortiauth.... " without also the HTTPS form... This is the IP internal interface of Fortigate for the specific SSID. The browser warning that it's insecure because it's not in HTTPS and show the warning to trasmit the credential in a non secure channel...
How do I avoid this warning and continue the protected session?

[jhussain_FTNT]

You can enable the auth secure settings with below command to redirect the captive portal with  https page

config user setting
set auth-secure-http enable  (default = disable)
end

[Fabio]

No, not going. Until the request goes to FortiAuth is ok but after the authentication it's redirect to Fortigate and an error page shows.. and the url change the port "10.12.0.1:1003/fortiauth" ( before was 10.12.0.1:1000/fortiauth)  

[Fabio]

and the problem it's also for the replace messages that don't they are no longer reachable.. maybe for the change port..?

[Markus_M]

Hello Fabio,

the port 1000 is the HTTP port on FGT, the port 1003 is the HTTPS variant, as indicated by the previous poster.

On FAC, inside the portal settings, top right, you will see an excellent explanation of the complete captive portal flow. The flow roughly is (ignoring TLS):

1) DNS request for IP of some external page

2) HTTP connect to that IP

3) FGT blocks the request, replies with a 302/303 redirect that contains https://fac.xxzxzxzxx.YY/portal

4) DNS request for IP of fac.xxzyzyzyy.YY

5) HTTP request to fac.xxzyzyzyy.YY/portal

6) HTTP redirect from FAC with 301 (moved) to instruct client to go to http://fac.xxzyzyzyy.YY/portal/

7) Same as 4)

8) HTTP request to fac.xxzyzyzyy.YY/portal/

You can of course save some step 6-7 if you add the / after your link.

A packet capture will help you greatly to see when the error comes up and what resource is requested, what port is the client then talking to and to want device.

Best regards,

Markus

[Fabio]

Hello Markus,

thank you for your answer.

I didn't find on top of the roght in FAC the portal setting and the workflow as you describe.

My Fac is 6.4.0 release, it's right?

I will upgrade to 6.4.2 in few days.

Thank you for replay

[Debbie_FTNT]

In addition to Markus' update, one common fix is as follows:

On FortiGate, define a URL for its own captive portal:
#config firewall auth-portal

#set portal-addr <portal.domain.com>
#end
Also specify HTTPS and an appropriate certificate in user settings:
#config user setting
#set auth-secure-http enable
#set cert <cert matching portal URL above>
#end
-> This takes care of FortiGate captive portal being trusted

On FortiAuthenticator, you need to adjust the portal policy a bit; the Access Point entry in the portal policy needs to contain the FortiGate's portal address, not interface IP.
The flow will be roughly:
-> user hits FortiGate captive portal (with HTTPS/URL/trusted cert)
-> user gets redirected to FortiAuthenticator portal (with HTTPS/URL/trusted cert)
-> user authenticates
-> FortiAuthenticator sends back to FortiGate portal (HTTPS/URL/trusted cert)
-> FortiGate directs to specified URL or original request

There can be issues if FortiGate captive portal is on HTTP and FortiAuthenticator on HTTPS, for example; after authentication FortiAuthenticator would direct back to an HTTP page, and many browers do not allow redirect from an HTTPS page to HTTP.
If on the other hand you're using HTTPS captive portal on FortiGate, then there's certificate issues if default certificates are used.

[Fabio]

thank you, I will trie your solution.. I will approche a parallel enviroment to test this solution..
you will soon have some news

[Fabio]

Debbie it’s OK, works and i don’t have anymore warning in the browser for Windows notebook but for Apple device ( macOS and iOS)  don’t start the captive portal for authentication even if I open a browser.. any idea ..? 

[Fabio]

i find this :

Apple devices make use of Captive Network Assistant (CNA) which can detect the use of a captive portal. The apple device attempts to visit the page captive.apple.com. If the apple device is successful, the CNA doesn't load, but if it unsuccessful, then it launches a browser to prompt the user with the login page from the captive portal. When this browser is inadvertently closed or ignored, the device is disconnected from the network. Often times the user is unaware and does not know why email and updates are not being downloaded.

fonte: https://docs.fortinet.com/document/fortigate/5.4.0/cookbook/937300/captive-portal-bypass-for-apple-u...