Fall through for a policy that works with Identity Based Policy and FSAE

[longwave]

Hi all, As I am relatively new to the subject, please ignore the simplicity of the question: We have a fortigate 110C with 4.0 MR1 Patch7. Recently we installed the FSAE package on our MS-domain controllers to be able to alllow/block access based on AD-users or AD-groups (that is at least what I understand what should be able). Now, if I configure a policy with the Identy Based Policy option activated, I can add a previously AD-group defined to have access to a certain service, for example HTTP/HTTPS. However, all other users not belonging to the selected group are blocked to the HTTP/HTTPS service, while my expectation would be a fall through to the next policy, which would give me the same way of working with IP-based policies. The group used in the Identity Based Policy option is a Directory Service group created through the User, User Group options that includes a group from the AD-server Thanks in advance.

[rwpatterson · Accepted solution]

Welcome to the forums. With identity based policies, you need to include all options/groups in the policy. Any policy below with the same source/destination pair will never get hit. It' s somewhere in the notes.

[Kevin_Noble]

I seem to have the same issue since upgrading from 3.0 to 4.0 MR1 Patch 7. I want to apply identity based policy on certain protocols like HTTP and HTTPS but not on other protocols since we are still wanting to use other protocols for other application like Exchange etc. since our firewall is in between us and the rest of our city organization where the email server resides. How can I just apply authentication for Internet access and let other protocols flow without it? It used to work OK on 3.0 with the rule order taking care of things, but now that doesn' t seem to work so how can get back the functions I had working with 3.0.

[billp]

How can I just apply authentication for Internet access and let other protocols flow without it?

You can create firewall policies that allow specific protocols to pass without any authentication. You just define the source, destination and the " Service" -- TCP/UDP and port range. You can use common predefined services or create your own. Then move them to the top of your policy lists so that they are hit before your HTTP and HTTPS policies that require authentication.

[Kevin_Noble]

I tried that and it seems as if the Identity based Policy is even affecting rules that are above the policy I have authentication on. The traffic log shows that PCs in question are definitely using the rule above (with no authentication or Identity Based Policy turned on at all), but they lose Internet access when I turn on the fall through rule with Identity Based Policy that is way at the bottom of my policy. If I remove Identity based Policy from the fall through rule and leave everything else, then everything starts working again, so I know it is the Identity Base Policy part that is the issue. It is almost like the Identity Based Policies are applied first and override the normal rule order. The firewall in question is in transparent mode - I don' t know if that would affect things or not - it was also in transparent mode before the 4.0 upgrade with 3.0 firmware and this all worked great.

[billp]

Interesting. I don' t use Transparent mode, but can' t see why that would affect this. Just a couple of wild ideas. . . 1. Bad firmware or config upgrade, maybe? I know there is a certain sequence that is required when moving from one major firmware to the next. You might try formatting your firmware from scratch and then reinstalling 4.2.7 or 4.1.9. I once had part of my config file trashed during a firmware upgrade. So you might want to see if your config looks reasonably whole. 2. Reduce the problem to the barest minimum. Two firewall rules: One FTP rule with no auth. One HTTP with local password auth. If that didn' t work, you could post those firewall rules here for a quick sanity check. Then determine whether the firmware installed incorrectly or no. Hope that helps.

[Kevin_Noble]

Good ideas - I will have to pull out our spare unit and to try some of these things as troubleshooting this on a live network is a bit of a problem. Hopefully if I put my workstation in a transparent link with the spare, I can see if I can replicate it with a simpler set of rules. I have tried putting my IT technician workstation rule (a select group of workstations allowed out to ALL with ANY protocol) right at the top of the policy and then tried recreating the ALL to ALL rule using HTTP/HTTPS and Identity Policies at the bottom of the policy list and it still cuts access when enabled, so I guess the next steps are to see if I can replicate it on another Fortigate box.

[billp]

Good luck. Experimentation is probably your best bet. I would think that if this were a widespread problem, there would be lots of posts here on this. I' ve also been amazed at how often a day' s rest will allow me to see into a problem that seemed impenetrable the day before

[Maik]

maybe the following CLI switch might be helpful in your case: config system global set auth-policy-exact-match enable end

[Kevin_Noble]

It looks like I already had that CLI switch enabled according to my config. I have logged a call with Fortinet support to see if they can provide any other suggestions.