SAML SSO VPN and VLAN

[Binaire]

Hello,

sorry for my english, i use google trad

Is it possible to have a SSL VPN with Azure SAML SSO authentication and at the same time a captive portal on a VLAN with Azure SAML SSO authentication ?

With 2 different Azure groups for authentication.

material: Fortigate 100F
Firmware: v7.0.12 build0523 (Mature)

Best regards, 

[pminarik]

Hi there, it is absolutely possible!

As a matter of fact, given how SAML is configured in FortiGates, you will need to configure two groups even if you use only one on the Azure side for it.

config user saml

"saml_1" -> uses SP URLs for SSL-VPN authentication (usually /remote/saml/login etc)
"saml_2" -> uses SP URLs for captive portal authentication (usually [...]:1003/saml/login/ etc)

config user group
vpn-group -> links to saml_2 and optionally specifies a certain group
captive-portal-group -> links to saml_2 and optionally specifies a certain group

relevant links:
https://docs.fortinet.com/document/fortigate/7.0.12/administration-guide/18013/outbound-firewall-aut...

https://docs.fortinet.com/document/fortigate-public-cloud/7.0.0/azure-administration-guide/584456

[Binaire]

Good morning,
Thanks for your help. I will test this as soon as possible.
Best regards,

[Binaire]

Hi there,
After several tries I still get stuck in the same place.
for the VPN it works perfectly, however for the captive portal I have a web page that opens asking me to connect and a second tab which is supposed to open the portal for me but I find myself with a certificate problem.
your connection is not private ...
the website login.microsoftonline.com ...
NET::ERR_CERT_AUTHORITY_INVALID

Thanks for your help

[Binaire]

I forgot to add:
“Exempt destinations/services”
login.microsoftonline.com
login.microsoft.com
login.windows.net
in interface configuration.

Now I'm still blocked but it's a blank page that appears instead of the login page, yet the address pointed to is https://login.microsoftonline.com/5........../saml2.....

[pminarik]

best I can suggest is to debug this using a Network Debugger in the browser (in Dev Tools). Take note of any request that fails, then check if it's exempted. Might need to be added.

[Binaire]

thank you very much for your help and sorry for the double post :\

I just checked and indeed another address had to be specified.

Now I'm coming on the O365 login page, I enter my login and password after I am redirected to the fortigate address specified in my app on Azure. So things are progressing well!
unfortunately it's a blank page with an error "this site is inaccessible"
https://xxx.xxx.xxx.xxx:1003/saml/login/
ERR_CONNECTION_TIMED_OUT

I don't understand. 

[pminarik]

The address looks OK ( [...]:1003/saml/login/ ). How long did it take you to finish the process? The FortiGate doesn't wait indefinitely, so maybe things merely timed out.

It timing is the issue, increasing remoteauthtimeout in config system global (CLI only), might help.

[Binaire]

Hello,

It works ! :D

The right link is this one: https://docs.fortinet.com/document/fortigate/7.4.1/administration-guide/33053/outbound-firewall-auth...

I just have one last concern regarding the certificate warning.
is it possible to have a valid certificate without having to install it on all clients?


Thank you very much for your help, it helped me a lot.

[pminarik · Accepted solution]

So I take it the correct URL pattern ended up being /remote/saml/..., is that right?
Some parts of the documentation seem to contradict each other here, unfortunately.

With regards to the certificate, right now this will default to using an IP for the ...:1003... URLs, for which you certainly won't be able to get a public certificate. You can customize the URL to use a specific FQDN/domain, for which you should be able to buy/obtain a certificate.

If this portal is set per-policy, the options are:
config firewall policy

edit <policy id>

set auth-cert <matching certificate for the FQDN>

set auth-redirect-addr <which FQDN to use>
end

If this configured on interface-level:
config system interface

edit <interface-with-portal>

set auth-cert <matching certificate for the FQDN>

set auth-portal-addr <which FQDN to use>
end

Don't forget to make sure that you have a DNS record configured for this FQDN, and that your clients can resolve it correctly. (it should point to the IP of the ingress/source interface)

Lastly, I'll add that this is applicable to redirects from plain HTTP (clients typically probe for portals with HTTP requests), and for loading the /remote/saml/... URLs.

Redirecting from HTTPS to a portal are impossible to do without MITM/deep SSL inspection, which would require importing your own CA to all relevant clients.