| Solution | - Test user is 'test1'.
- 'test1' user is part of 'group1' and 'group2'.
 - Captive portal is enabled on the interface port2 where the captive portal user is located.
'group1' and 'group2' have been added under user-restricted groups, which are the groups that the 'test1' user is part of. 
- To confirm if the user is being redirected to the captive portal page, inspect the session list:
chewbacca-kvm22 # diagnose sys session list session info: proto=6 proto_state=06 duration=1 expire=3 timeout=3600 refresh_dir=both flags=00000004 socktype=4 sockport=10102 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/0
state=redir local may_dirty auth cap ---> The flag auth indicates that authentication takes place, cap indicates that it was being sent to captive portal.
statistic(bytes/packets/allow_err): org=0/0/0 reply=6682/9/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 4640/37
orgin->sink: org pre->post, reply pre->post dev=5->4/4->5 gwy=10.56.247.254/0.0.0.0
hook=pre dir=org act=noop 10.119.3.197:58958->172.172.255.217:443(0.0.0.0:0)
hook=post dir=reply act=noop 172.172.255.217:443->10.119.3.197:58958(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=0 pol_uuid_idx=0 auth_info=0 chk_client_info=0 vd=0
serial=0063b0e1 tos=00/00 app_list=0 app=0 url_cat=0
sdwan_mbr_seq=2 sdwan_service_id=1
rpdb_link_id=ff000001 ngfw_id=n/a duplicaton_id=0
npu_state=0x000100
no_ofld_reason: redir-to-av auth
hrx info: valid=0/0, qid=0/0, npuid=0/0, sublink=0/0 - With this configuration, once the 'test1' user authenticates via the captive portal, the FortiGate will detect all the groups that the 'test1' captive portal user belongs to.
It is possible to check it as well via cli by running this command: diagnose firewall auth list.  |
