Fortigate v5.4.0 Authentication in Policy

[AlexandreL]

Hi folks I'm trying to use user authentication in policy and it seems it's not working at all. Actually i'm trying to force authentication to a random website (sfr.fr) I have a FSSO account with few user and also a LDAP super group with the same user.    edit 10         set uuid 010e1876-0d54-51e6-9f1c-33c8dbd09562         set srcintf "PARROTHQ"         set dstintf "CERBER"         set srcaddr "Parrot_DeepInspection"         set dstaddr "sfr.fr"         set action accept         set schedule "always"         set service "HTTP" "HTTPS"         set utm-status enable         set logtraffic all         set ntlm enable         set groups "FSSO_Test "LDAP_Test"         set comments "sfr.fr"     next

Actually nothing works, my user authentified by FSSO (i can see him in the monitor) is'nt able to access sfr.fr. The user which is not logged in doesn't receive any popup for authentication

Any idea ?

[Luiz_Alberto_Camilo]

Hi Alexandre, 

Can you find this session filtering by source and destination maybe ? on the session information you will find the policy ID wich will point you if your traffic is passing through the right policy. 

"diag sys session filter sadd x.x.x.x" 

"diag sys session filter dadd x.x.x.x" 

"diag sys sesison list" 

I suspect that on this case your user is matching another policy. 

Also check the order of your policies. The policy that you mentioned above, needs to be above any other internet outgoing policy. 

Also check if your FQDN object is resolving it's DNS to IP. 

Best regards. 

[AlexandreL]

I can't find any session for HTTP/ HTTPS trafic (denied by a subsequent rule)

Here is a session list :

FG200D4615805460 # diagnose sys session list

session info: proto=1 proto_state=00 duration=20 expire=40 timeout=0 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3 origin-shaper= reply-shaper= per_ip_shaper= ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0 user=al.lefebvre state=log may_dirty br npu none acct-ext statistic(bytes/packets/allow_err): org=120/2/1 reply=120/2/1 tuples=2 speed(Bps/kbps): 0/0 orgin->sink: org pre->post, reply pre->post dev=164->165/165->164 gwy=0.0.0.0/0.0.0.0 hook=pre dir=org act=noop 172.20.70.22:1->80.125.163.172:8(0.0.0.0:0) hook=post dir=reply act=noop 80.125.163.172:1->172.20.70.22:0(0.0.0.0:0) misc=0 policy_id=11 auth_info=0 chk_client_info=0 vd=0 serial=07faeeb3 tos=ff/ff app_list=0 app=0 url_cat=0 dd_type=0 dd_mode=0 npu_state=0x003000 npu info: flag=0x81/0x81, offload=6/6, ips_offload=0/0, epid=7/6, ipid=6/7, vlan=0x8064/0x8064 vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0 total session 1

Here is the seq of my rules :

[emnoc]

Agreed and i would use the diag debug flow to validate what the policy is doing.

( here's a blog I finally posted a few years back on tips/trick with id-policy t-shooting ) most of this is this relevant in FSSO

http://socpuppet.blogspot...-policies-trouble.html

[Luiz_Alberto_Camilo]

Also try to edit the implicit rule ( last one ) and log dropped packets.

might help you have more visibility of what's going on. 

[AlexandreL]

I'll get a look to your blog emnoc.

I get more logs, If i understand it right, the firewall is going trough my policy (10, 11 and 8) and only match on the policy 8.

Policy 10 allow access to sfr.fr for my ip & my username PROTO HTTP/HTTPS

Policy 11 allow access to sfr.fr for my ip PROTO icmp

Policy 8 block access to sfr.fr for my ip PROTO ALL

Weird issue is the previous log show me (IP&username matching policy 11 for ping)

here is the additionnal logs :

2016-05-09 16:47:47 id=20085 trace_id=109 func=print_pkt_detail line=4681 msg="vd-root received a packet(proto=6, 172.20.70.22:64346->80.125.163.172:443) from PARROTHQ. flag [ S ], seq 1613040934, ack 0, win 8192" 2016-05-09 16:47:47 id=20085 trace_id=109 func=init_ip_session_common line=4832 msg="allocate a new session-07fd4739" 2016-05-09 16:47:47 id=20085 trace_id=109 func=iprope_dnat_check line=4641 msg="in-[PARROTHQ], out-[]" 2016-05-09 16:47:47 id=20085 trace_id=109 func=iprope_dnat_check line=4654 msg="result: skb_flags-01800000, vid-0, ret-no-match, act-accept, flag-00000000" 2016-05-09 16:47:47 id=20085 trace_id=109 func=iprope_fwd_check line=695 msg="in-[PARROTHQ], out-[CERBER], skb_flags-01800000, vid-0" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_tree_check line=543 msg="gnum-100004, use addr/intf hash, len=8" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-100004 policy-12, ret-matched, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check line=1924 msg="gnum-1, check-ffffffffa00a3c9a" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-1 policy-4294967295, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check line=1943 msg="gnum-1 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_user_identity_check line=1526 msg="ret-no-match" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-100004 policy-14, ret-matched, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check line=1924 msg="gnum-1, check-ffffffffa00a3c9a" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-1 policy-4294967295, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check line=1943 msg="gnum-1 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_user_identity_check line=1526 msg="ret-no-match" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-100004 policy-10, ret-matched, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check line=1924 msg="gnum-1, check-ffffffffa00a3c9a" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-1 policy-4294967295, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check line=1943 msg="gnum-1 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_user_identity_check line=1526 msg="ret-no-match" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-100004 policy-11, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-100004 policy-8, ret-matched, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_user_identity_check line=1526 msg="ret-matched" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check line=1924 msg="gnum-4e20, check-ffffffffa00a3c9a" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=109 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=22016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1700 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check line=1943 msg="gnum-4e20 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000" 2016-05-09 16:47:47 id=20085 trace_id=110 func=__iprope_check_one_policy line=1895 msg="policy-8 is matched, act-drop" 2016-05-09 16:47:47 id=20085 trace_id=110 func=iprope_fwd_auth_check line=747 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-8" 2016-05-09 16:47:47 id=20085 trace_id=110 func=br_fw_forward_handler line=522 msg="Denied traffic from 'PARROTHQ' to 'CERBER' by forward policy check (policy 8)"

[emnoc]

Qs:

1>

fwolicy-id #14 what is that?

2>

The last line bothers me ( fwpolicy-#8 ) are you  allowing all  types HTTP/HTTP/icmp and then ALL protocols? I never seen it done that way, if the use doesn't pass   the other fwpolicies they would be denied by default  ( fail authentication or FSSO )

What you could do, is to look at the FSSO status for that user

e.g

diag debug reset

diag debug authd fsso refresh-logons

diag debug applica authd -1

diag debug authd fsso filter  user  <username_xyz>

diag debug authd fsso list

And see what happen after the use has show up in the login and after execution of new traffic. Try to drill into one  user for that  group and see what happens.

We typically stroke a test vm-machine with a test-account just for this and allow or restrict policy for that machine, could do that also by setting a policy ahead of the mentioned earlier and run all of the diagnostic against that policy.

ken

[AlexandreL]

1> fwolicy-id #14 is another policy for my IP with only FSSO group (not FSSO + LDAP group)

2> the policy 8 is the policy to deny the trafic for my computer, there is sbsequent rule which allow https for all URL after. I wanted to new for sure i was not using this "all access" policy if it was working.

Here is the output of diag debug authsd fsso list :

----FSSO logons---- IP: 172.20.70.22 User: al.lefebvre Groups: CN=Alexandre Lefebvre,OU=~,DC=~,DC=~ Workstation: MemberOf: FSSO_TestAlexandre Total number of logons listed: 1, filtered: 9 ----end of FSSO logons----

Seems i'm recognized by the firewall, but still no access to sfr.fr

[emnoc]

Okay so FSSO is working and we know that's not the cause of the failure. Can you run the authd debug as listed earlier and after you clear your table? I'm assuming al.lefebvre ( src machine also )   is the user your testing on?