v5.2.1 and Identity Base Policy

[TuncayBAS]

me one, identity-based policies in v5.2.1 how it works. Is it possible to tell? Traffic continuous, comes from the following rules.

[TuncayBAS]

Rule No. 1, the bypass is going on. I did not understand a kind.

[Phuoc_Ngo]

Fortigate process all policy from the top down approach.  For policy#1, it only process all traffics destine for http/https and DNS.  Any traffic that is not http/https or dns, will get process by policy#2.

[Adrian_Buckley_FTNT]

Rule #1 has a source that includes a user.

Unless you re using some kind of passive authentication (FSSO or RSSO) then you are not authenticated, so you don't match the user on policy 1 .. so your source does not match and you fall down to policy #2.

Having authentication enabled on polciy #1 does NOT force users to authenticate.

To do that .. you need to EITHER have authentication on BOTH policies ... or set the security mode on the ingress interface to captive portal.

[TuncayBAS]

Friends, there was no problem when v5.0.x. But v5.2.x authentication logic works differently. I could not solve. Passive authentication, which is, that I want to use the rule I take with FSSO users. I do not want to use the Captive Portal.

[Janne]

yaba wrote:

Friends, there was no problem when v5.0.x. But v5.2.x authentication logic works differently. I could not solve. Passive authentication, which is, that I want to use the rule I take with FSSO users. I do not want to use the Captive Portal.

I think we have the same setup. And the upgrade to 5.2.2 broke our guest net.

If i disable captive portal the user gets denied byt the implicit deny and with captive portal the auth-redirect is broken (it doesnt redirect with fqdn, just the IP).

It seems that in 5.2 there is something wrong with the Identity based policies.

Anybody else have theese problems? Anbody have a solution?

We are using theese policies for out wifi-guest-net with Radius authentication.

[amitkor]

Going by this document:

http://docs.fortinet.com/uploaded/files/2021/fortigate-cookbook-52.pdf

The policy looks fine. I couldnt make it work either.

[garyxd]

Just remember in 5.2 there is always implicit policy fall-through, even if a LDAP or RADIUS group is referenced in the policy.  If you are going to use a later policy, make sure that the same source/destination pair isn't referenced.  If you want to use an 'all', instead use some combination of 'srcaddr-negate', 'dstaddr-negate', and 'service-negate'.  That way, you can make sure that later policies don't match your authentication policy.  The implicit fall-through shouldn't match the implicit deny though.