Skip to main content
longwave
longwave
New Member
May 17, 2011
Solved

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

  • May 17, 2011
  • 10 replies
  • 7953 views
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.
    Best answer by rwpatterson
    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.

    10 replies

    rwpatterson
    rwpattersonAnswer
    New Member
    May 17, 2011
    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
    Kevin_Noble
    New Member
    June 3, 2011
    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
    billp
    New Member
    June 3, 2011
    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
    Kevin_Noble
    New Member
    June 3, 2011
    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
    billp
    New Member
    June 3, 2011
    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
    Kevin_Noble
    New Member
    June 3, 2011
    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
    billp
    New Member
    June 3, 2011
    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
    Maik
    New Member
    June 3, 2011
    maybe the following CLI switch might be helpful in your case: config system global set auth-policy-exact-match enable end
    Kevin_Noble
    Kevin_Noble
    New Member
    June 7, 2011
    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.
    Kevin_Noble
    Kevin_Noble
    New Member
    June 14, 2011
    Just though I' d let everyone know the only solution to this was to create a rule above that has a group for all the services and allow that outbound without any identity polices enabled. The rules above were working OK - the reason it looked like rules above were being affected by the identity policy was that DNS from our servers was using the fall through policy so it was being cut off so it affected HTTP/HTTPS attempts from other workstations using the rules above. As soon as that was moved to a rule above with other protocols then things worked OK. It is not as convenient as the way it worked with the older 3.0 firmware which allowed for a fall through policy to be after the identity policies but it can be made to work if you manage to figure out all the protocols your workstations need for outbound traffic.
    longwave
    longwaveAuthor
    New Member
    July 22, 2011
    As a basic rule learned as a best practice I work down the policies as follows: 1. - policies based on IP-addresses/IP-networks, from specific to less specific. 2. - policies based on FSAE with various sub rules for the different groups. I place these policies just before the final DENY policy of an interface pair. 3. - DENY policy for the interface pair. In this way the IP-address policies are being handled as before without being interfered by the FSAE policies. That is, when you need to have that security. I am sure there will be offices working with FSAE policies only... Bye.
    Terms & ConditionsAccessibility statement