Fortigate identity policies trouble-shooting

With fwpolicies that uses identity-based , you have a few means for diagnostics.

The 1st thing you need to do is to ensure that the expected-traffic is matching the policy that a user is having problems authenticating with. And ensure that traffic is arriving to the fortigate firewall. The easiest way for determining  this;

diag debug flow

or

diag sniffer packet 

The former is more acceptable.

If traffic is NOT hitting your policy,  than "Stop" and don't proceed until you ensure that any other network routing or filtering problems has been fixed.

I 've seen now on 1-to-2 dozen occasions or more, that a firewall engineer stumbles around just to find out a inside  interior  firewall or router ACL was preventing the traffic destine to the  identity-based firewall policies.

NOTE: With the diag debug flow, if you see "Denied by forward policy check",  than that  means you hit a policy with the action either set to  disable or  you have no policy to begin with.

If you are seeing a policy-id match that matches your traffic,  the following will be logged via the diag debug flow. This will show the policy-id  that's being matched, now you can dive in and find the problem.

e.g

msg="Allowed by Policy-124:"


Next, is this the policy-id that you have identity-based authentication set for? And does the group have the proper user defined ?

config firewall policy
    edit 124
        set srcintf "wan1"
        set dstintf "port1"
            set srcaddr "all"            
            set dstaddr "XXX_XXX_XXX_XXX"            
        set action accept
        set identity-based enable
            config identity-based-policy
                edit 1
                    set schedule "always"
                        set groups "consultant"                        
                        set service "TELNET"                        
                next
            end
    next
end


Next, you will need to inspect the user  and the  user-group that's defined  for the above firewall-policy-id. Here it would be my group named "consultant" and it has one member  "kfelixsslvpn"

config user group
    edit "consultant"
        set sslvpn-portal "full-access"
            set member "kfelixsslvpn"            
    next
end

and

config user local
    edit "kfelixsslvpn"
        set type password
        set passwd ENC VLrvImdmeB0GbZs5ZG+D5Wzhyhy0xNHyfo0lnX0YmATrFc2pAiZ7T8dcAbOfbi+k2WA1i3ydO2m4jyHLusuWU0kVJot8e518qzyIqzi1IvewXug1
    next
end

In my case we are using local authentication So this user is authenticated locally against the user database. If the user doesn't exist or does not exist for the group, you will fail authentication. Also if the password is incorrect, you will fail authentication.

So if you suspect problems with the end-user,  have her/him double check the login/password or create a new password for the login.

If the user is  authenticated off-appliance, you need to  diagnostic  the  remote authentication services.
 (   radius, ldap, etc... ). Most AAA authentication platforms have local tools for testing  user validation or credentials. Research your platform for any local tools or diagnostics.

NOTE: If you see a group with multiple users & only ONE user is having problems that you can narrow down your diagnostics with just that "user".

Lastly, you can use the displayed output when your intercepted for authentication. If your getting that the authentication block that you know the identity policy is being matched.


You can also use the diag debug app authd -1 to report the status also.


( telnet  )

( http )

So based on the policy and identity the  fortigate will challenge the user with a login.

 

config firewall policy
    edit 124
        set srcintf "wan1"
        set dstintf "port1"
            set srcaddr "all"            
            set dstaddr "XXX_XXX_XXX_XXX"            
        set action accept
        set identity-based enable
            config identity-based-policy
                edit 1
                    set schedule "always"
                        set groups "consultant"                        
                        set service "HTTP"                        
                next
            end
    next
end

With authentication  & identity-based policies, if the original session was via an un-encrypted services , than the authentication would also be un-encrypted. 

 What this means,  my above HTTP identity-based policy would authenticated me via "HTTP" and not "HTTPs".  The fortigate is actually intercepting the traffic src/dst and spoof'ing the  challenge on behalf of the destination.  Your NOT authenticating via the target but via the firewall and the packet spoof'ing.



Here's a tshark decode

No pun intended , but the user credentials clearly are in the clear ( username = sssss password = ssssssss )

This is bad thing ( lack of security ) but for diagnostics, you can packet capture the traffic and inspect the user credentials that's being presented.

A few useful authentication commands;

Diagnostic

 diag debug reset 
 dag debug en
 diag debug application authd -1

Operations & monitoring

 diag firewall iprope authuser
 diag firewall iprope resetauth

The former shows who authentication & from where. It will now show what policy-id trigger the authentication. The latter clears all authentications. Use with caution.

  diag firewall auth list

This will show you details about the user, timeout and policy-id that was triggered.


For my  very last item, you can adjust the authentication timeout. This can be done  from the webGu.

 user > device > authentication> setting 

or via the CLI;

config user setting
    set auth-cert "self-sign"
    set auth-timeout 436
end


NOTE: default timeout == 300secs


And for stricter and harsher controls, you can set the  authenticating parameters for blackout and the max failed-attempts. This is great protection for any  brute-force login attacks.

config user setting
    set auth-blackout-time 5
    set auth-invalid-max 3          < after 3  failures blacklist at above value 5mins.
end

NOTE: various  fortiOS exhibits failures on the blackout time value and it's ignored YMMV


I hope this gives you some ideals on identity-based authentications. IMHO  security methods exist such as 802.1x, FSSO , Radius SSO, Proxies or a combination with identity-based.

Ken Felix
Freelance Network/Security Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^    ^
 =( #  # )=
      @
      /   \