Technical Tip: Wildcard admin profile does not work on FortiGate

[anoushiravan]

Description	This article describes one of the the reason that GUI/SSH access is failed for the admin which is part of a remote group in remote server like LDAP, radius, etc. When the admins are part of a remote group on any remote server, the wildcard option in admin profile is enabled to match the admin credential with the enabled remote group under admin profile.  config system admin   edit <admin profile>    set wildcard enable <<-----   end
Scope	FortiGate.
Solution	On FortiGate, as per the current design, only the global wildcard admin accounts (which has "root" vdom as enabled vdom) will be examined to match the admin credential and other configured wildcard admin profiles (which the root vdom is not enabled as vdom) will be ignored: config system admin     edit <admin profile>         set wildcard enable <-----         set vdom root <----- global admin profile sincethe management VDOM 'root' has been enabled.   end config system admin     edit <admin profile>         set wildcard enable         set vdom sales <----- VDOM-based admin profile since the management vdom 'root' is not enabled.   end In the following example, the requirement is that the admin 'soniya' must be able to have access only to the VDOM named 'sales', but this admin is only able to log in to the 'root' VDOM.   The admin 'soniya' is a member of both enabled remote groups 'fac.tacacs.group' and 'server.tacacs.group' on both admin profiles, but as the debugging shows, the admin 'soniya' can only access the VDOM named 'root' since only the global wildcard admin profiles are sent to the FNBAMD daemon to match the user group, and the VDOM-based wildcard admin profile is ignored: config system admin     edit "fac.tacacs.admin"         set remote-auth enable         set accprofile "super_admin"         set vdom "root" <----- Global wildcard admin profile.         set wildcard enable <-----         set remote-group "fac.tacacs.group"     next     edit "server.tacacs.admin"         set remote-auth enable         set accprofile "super_admin"         set vdom "sales" <----- This is not a global wildcard admin profile because the management VDOM 'root' has not been enabled.         set wildcard enable <-----         set remote-group "server.tacacs.group"     next end config user tacacs+     edit "fac.tacas+"         set server "10.125.5.135"         set key ENC EVvOGEr40yyHIZv71sRZmgcssI4wvb91QnkmbsVu6JBSoLaAbfNoa3FAXzKOUDtsx/F4nNfxAXr0qW+NSPkPJ2eGADJWORzdSfuIgXfnKiL3RP++rF8NzUedl8wf774D0jzcWnZPa1wJQwgioPvrNR2jUcmrVwQzr3Fe3XdlkH8IO8di4xOV/5lzXBoFZ0AHnfoNbw==     next     edit "server.tacas+"         set server "10.160.5.136"         set key ENC EVvOGEr40yyHIZv71sRZmgcssI4wvb91QnkmbsVu6JBSoLaAbfNoa3FAXzKOUDtsx/F4nNfxAXr0qW+NSPkPJ2eGADJWORzdSfuIgXfnKiL3RP++rF8NzUedl8wf774D0jzcWnZPa1wJQwgioPvrNR2jUcmrVwQzr3Fe3XdlkH8IO8di4xOV/5lzXBoFZ0AHnfoNbw==     next end config user group     edit "fac.tacacs.group"         set member "fac.tacas+"     next     edit "server.tacacs.group"         set member "server.tacas+"     next end As shown in debugging logs, only the remote group 'fac.tacacs.group' under the global wildcard admin profile 'fac.tacacs.admin' is checked by FortiGate to match the admin 'soniya', as a result, the user will be able to access only the 'root' VDOM. And the group 'server.tacacs.group' will be ignored since only the global wildcard admin profile will be used to match the admin credential as explained above: Spoke1 # diagnose debug disable Spoke1 # diagnose debug reset Spoke1 # diagnose debug console timestamp enable Spoke1 # diagnose debug application fnbamd -1 Debug messages will be on for 30 minutes. Spoke1 # diagnose debug application httpsd -1 Debug messages will be on for 30 minutes. Spoke1 # diagnose debug enable Spoke1 # 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] fweb_debug_init[417] -- New POST request for "/logincheck" from "172.26.61.4:52881" 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] fweb_debug_init[419] -- User-Agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0" 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] fweb_debug_init[421] -- Handler "logincheck-handler" assigned to request 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] logincheck_handler[421] -- entering vdom for login_attempt (vdom='root') 2024-03-06 12:26:05 [1916] handle_req-Rcvd auth req 471980690 for soniya in fac.tacacs.group opt=00014001 prot=11 2024-03-06 12:26:05 [475] __compose_group_list_from_req-Group 'fac.tacacs.group', type 1 2024-03-06 12:26:05 [616] fnbamd_pop3_start-soniya 2024-03-06 12:26:05 [2255] fnbamd_user_ldap_create-LDAP servers are created, vfid=0, total=1 2024-03-06 12:26:05 [378] radius_start-Didn't find radius servers (0) 2024-03-06 12:26:05 [1068] __tac_plus_try_next_server-Try fac.tacas+:10.125.5.135 2024-03-06 12:26:05 [358] __tac_plus_dns_cb-Resolved fac.tacas+:10.125.5.135 to 10.125.5.135, cur stack size:1 2024-03-06 12:26:05 [278] sock_connect-connecting fac.tacas+:10.125.5.135: 10.125.5.135 2024-03-06 12:26:05 [491] ldap_start-Didn't find ldap servers 2024-03-06 12:26:05 [642] create_auth_session-Total 1 server(s) to try 2024-03-06 12:26:05 [390] is_sock_connected-tcp connected 2024-03-06 12:26:05 [497] build_authen_start-building authen start packet: authen_type=2(pap) 2024-03-06 12:26:05 [763] tac_plus_result-Authen sending request 2024-03-06 12:26:05 [405] pak_send-Encrypting pkt 2024-03-06 12:26:05 [1210] fsm_tac_plus_update_result-Continue pending for req 471980690 2024-03-06 12:26:05 [773] tac_plus_result-Authen receiving reply 2024-03-06 12:26:05 [462] pak_recv-read all header, data len 6 2024-03-06 12:26:05 [1210] fsm_tac_plus_update_result-Continue pending for req 471980690 2024-03-06 12:26:05 [773] tac_plus_result-Authen receiving reply 2024-03-06 12:26:05 [557] parse_authen_reply-authen result=1(pass) 2024-03-06 12:26:05 [1658] fnbam_user_auth_group_match-req id: 471980690, server: fac.tacas+, local auth: 0, dn match: 0 2024-03-06 12:26:05 [286] find_matched_usr_grps-Passed group matching 2024-03-06 12:26:05 [216] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 471980690, len=2092 2024-03-06 12:26:05 [798] destroy_auth_session-delete session 471980690 2024-03-06 12:26:05 [1077] tac_plus_destroy-fac.tacas+ 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] logincheck_handler[523] -- login attempt OK, VDOM updated to 'root' 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] logincheck_handler[529] -- login_attempt (method=5, vdom='root', name='soniya',admin_name='fac.tacacs.admin', auth_svr='fac.tacas+')  < 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] output_response[58] -- sent response (status='1', buf='document.location="/prompt?viewOnly&redir=%2F"; ') 2024-03-06 12:26:05 [httpsd 10613 - 1709724365 info] fweb_debug_final[306] -- Completed POST request for "/logincheck" (HTTP 200) 2024-03-06 12:26:06 [httpsd 10613 - 1709724366 info] fweb_debug_init[417] -- New GET request for "/api/v2/monitor/web-ui/node-auth" from "172.26.61.4:52881" 2024-03-06 12:26:06 [httpsd 10613 - 1709724366 info] fweb_debug_init[419] -- User-Agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0" 2024-03-06 12:26:06 [httpsd 10613 - 1709724366 info] fweb_debug_init[421] -- Handler "api_monitor_v2-handler" assigned to request To stop the above debugs, run the following CLI commands: Spoke1 # diagnose debug disable Spoke1 # diagnose debug reset In order to match the admin credential at the same time with both the 'global wildcard admin profile' and 'vdom-based wildcard admin profile', the customer needs to submit an NFR. Otherwise, an individual admin profile with the exact name of the remote user should be created on FortiGate, in this case, FortiGate will check the individual admin profile before a wildcard admin profile. Related documentation: Configuring wildcard admin accounts - FOrtiGate 6.2.17 handbook