| Description |
This article discusses the traffic logs reception with Action Deny: policy violation, using FSSO authentication and LDAP as the active authentication method. |
| Scope | FortiOS 6.2, 6.4 and earlier. |
| Solution |
In some environments, customers use FSSO as a passive authentication method to receive all logins from groups of their AD but also use LDAP as an active authentication method to those users out of the AD domain, i.e Linux or MAC box, and for situations when lost logons from FSSO.
In this sort of configuration, the FSSO policy must be on TOP of the firewall policies and the LDAP in BOTTOM.
Traffic with src.ip authenticated by FSSO will match the firewall policies on TOP configurated on their respective Group, but traffic unauthenticated in FSSO, will match on the first LDAP policy on BOTTOM and it will trigger the active authentication method sending a Captive Portal to the user.
Once the user has been authenticated with Portal Captive, of course against the LDAP server, the FortiOS will select the right policy of the Group to which the user belongs, I meant LDAP policies.
The process of the match LDAP policy selection is important to understand since when the LDAP user has not still authenticated in FortiGate, the traffic will match on the first policy located from TOP -> BOTTOM and after the user has been authenticated against LDAP the Group will be discovery and traffic will be associated to the right policy/group among all the LDAP policies.
If the user failed on the LDAP authentication, the log will be Deny: policy violation displayed on the policy-id of the first firewall-policy with LDAP authentication, instead of policy implicit 0 or instead of the firewall policy where the user of the LDAP policy/group belongs.
Why is there a lot of traffic with Deny: policy violation?
When the PC still has not been authenticated by FSSO or LDAP, the PC could be running some software in the background trying to update or send info to the internet, all of these connections will match on the LDAP firewall policy without able to gain authentication to FG since are not applications with user interaction, as would be a browser tool (chrome, firefox, safari, etc).
1) On the AD, the following group and user membership.
group1 -> user1 group2 -> user2
Note: user1 will be authenticated using FSSO user2 will be LDAP since is a Linux box.
2) In Fortigate the following FSSO and LDAP association to local groups.
#edit "fsso-group1" #set group-type fsso-service #next #set group-type fsso-service #next
#edit "ldap-group1" #set member "ldap-ad1" #next #end #next #set member "ldap-ad1" #edit 1 #next #end
3) The firewalls policies in Fortigate using FSSO on TOP and LDAP on BOTTOM.
4) User authenticated in Fortigate.
5) Once the user has been authenticated, traffic matching on the right firewall policy/group.
6) Traffic from src.ip with users unauthenticated will match on the first LDAP firewall policy (ID 4), the Action Deny: policy violation since the user didn't get authenticated.
7) By reports you could avoid this kind of traffic Deny: policy violation in a firewall policy of regular use as policy id 4.
You can create a Group in your AD without any user associated and set in a firewall policy on TOP of LDAP firewall policies, forcing all the unauthenticated traffic match on it, then you can exclude this policy from your reports.
Create a local group associated with the unauthenticated user group in LDAP. #edit "unath-group" #set member "ldap-ad1" #edit 1 #next #end
8) Create e firewall policy that belongs to the unauth-group of LDAP and set it on TOP of LDAP firewall policies.
9) The traffic unauthenticated traffic matching in policy ID 7.
Additional info:
Why does the traffic of user1 (192.168.81.100) unauthenticated still show the user into the logs?
Because Fortigate enabled devices identification on LAN interfaces and the authentication traffic (Kerberos) is seen by Fortigate.
|
