Remote RADIUS Group and wildcard admin issues - 7.2.5

[rsteixeira]

Hello Team.

At the moment we are using Remote Group RADIUS + wildcard admin on Fortigates in our envoriorment the most part of then are using 7.0.12 FortiOS and and it´s works just fine, but when we are trying use the same configuration on Fortigates with 7.2.5 version the admin users receives authentication error o GUI. The debug shows that the RADIUS process auth occours correctly and without errors.

Any one are experimenting the same issue or have some tip to solve the problem in 7.2.5 version?

Follows RADIUS Remote + Wildcard configuration that are using and output of debug commands:

RADIUS Configs:

User RADIUS

config user radius
edit "RADIUS-XPTO"
set server "172.16.0.3"
set secret ENC ddddddddd
set all-usergroup enable
set nas-ip "10.10.1.1"
set auth-type ms_chap_v2
set source-ip "10.10.1.1"
next
end

User Group

config user group
edit "GRP-RADIUS-XPTO"
set member "RADIUS-XPTO"
next
end

Profile to user RADIUS

config system accprofile
edit "no-access"
next
end

System admin with wildcard

config system admin
edit "USR-ADMIN-RADIUS"
set remote-auth enable
set accprofile "no-access"
set vdom "root"
set wildcard enable
set remote-group "GRP-RADIUS-XPTO"
set accprofile-override enable
set password xxxxxxxx
next
end

Output of debug commands:

diagnose debug application fnbamd -1
diagnose debug application radiusd -1


[1890] handle_req-Rcvd auth req 803881880 for user@domain.corp in GRP-RADIUS-XPTO opt=00014001 prot=
11
[473] __compose_group_list_from_req-Group 'GRP-RADIUS-XPTO', type 1
[616] fnbamd_pop3_start-user@bancoob.br
[342] fnbamd_create_radius_socket-Opened radius socket 11
[342] fnbamd_create_radius_socket-Opened radius socket 12
[1454] fnbamd_radius_auth_send-Compose RADIUS request
[1411] fnbamd_rad_dns_cb-172.16.0.173->172.16.0.173
[1383] __fnbamd_rad_send-Sent radius req to server 'RADIUS-XPTO': fd=11, IP=172.16.0.173(172.16.0.173:1812) code=1
id=92 len=229 user="user@domain.corp" using MS-CHAPv2
[319] radius_server_auth-Timer of rad 'RADIUS-XPTO' is added
[760] auth_tac_plus_start-Didn't find tac_plus servers (0)
[1718] fnbamd_ldap_init-search filter is: sAMAccountName=user@domain.corp
[1728] fnbamd_ldap_init-search base is: DC=sicoobsp,DC=corp
[1150] __fnbamd_ldap_dns_cb-Resolved XPTOSP:192.168.1.17 to 192.168.1.17, cur stack size:1
[925] __fnbamd_ldap_get_next_addr-
[1155] __fnbamd_ldap_dns_cb-Connection starts XPTOSP:192.168.1.17, addr 192.168.1.17
[880] __fnbamd_ldap_start_conn-Still connecting 192.168.1.17.
[636] create_auth_session-Total 2 server(s) to try
[1931] handle_req-r=4
[1108] __ldap_connect-tcps_connect(192.168.1.17) is established.
[986] __ldap_rxtx-state 3(Admin Binding)
[363] __ldap_build_bind_req-Binding to 'CN=fortigate,CN=Users,DC=domain,DC=corp'
[1083] fnbamd_ldap_send-sending 87 bytes to 192.168.1.17
[1096] fnbamd_ldap_send-Request is sent. ID 1
[986] __ldap_rxtx-state 4(Admin Bind resp)
[1127] __fnbamd_ldap_read-Read 8
[1233] fnbamd_ldap_recv-Leftover 2
[1127] __fnbamd_ldap_read-Read 14
[1306] fnbamd_ldap_recv-Response len: 16, svr: 192.168.1.17
[987] fnbamd_ldap_parse_response-Got one MESSAGE. ID:1, type:bind
[1023] fnbamd_ldap_parse_response-ret=0
[1053] __ldap_rxtx-Change state to 'DN search'
[986] __ldap_rxtx-state 11(DN search)
[750] fnbamd_ldap_build_dn_search_req-base:'DC=Domain,DC=corp' filter:sAMAccountName=user@domain.corp
[1083] fnbamd_ldap_send-sending 101 bytes to 192.168.1.17
[1096] fnbamd_ldap_send-Request is sent. ID 2
[986] __ldap_rxtx-state 12(DN search resp)
[1127] __fnbamd_ldap_read-Read 8
[1233] fnbamd_ldap_recv-Leftover 2
[1127] __fnbamd_ldap_read-Read 82
[1306] fnbamd_ldap_recv-Response len: 84, svr: 192.168.1.17
[987] fnbamd_ldap_parse_response-Got one MESSAGE. ID:2, type:search-reference
[1023] fnbamd_ldap_parse_response-ret=0
[1127] __fnbamd_ldap_read-Read 8
[1233] fnbamd_ldap_recv-Leftover 2
[1127] __fnbamd_ldap_read-Read 82
[1306] fnbamd_ldap_recv-Response len: 84, svr: 192.168.1.17
[987] fnbamd_ldap_parse_response-Got one MESSAGE. ID:2, type:search-reference
[1023] fnbamd_ldap_parse_response-ret=0
[1127] __fnbamd_ldap_read-Read 8
[1233] fnbamd_ldap_recv-Leftover 2
[1127] __fnbamd_ldap_read-Read 66
[1306] fnbamd_ldap_recv-Response len: 68, svr: 192.168.1.17
[987] fnbamd_ldap_parse_response-Got one MESSAGE. ID:2, type:search-reference
[1023] fnbamd_ldap_parse_response-ret=0
[1127] __fnbamd_ldap_read-Read 8
[1233] fnbamd_ldap_recv-Leftover 2
[1127] __fnbamd_ldap_read-Read 14
[1306] fnbamd_ldap_recv-Response len: 16, svr: 192.168.1.17
[987] fnbamd_ldap_parse_response-Got one MESSAGE. ID:2, type:search-result
[1023] fnbamd_ldap_parse_response-ret=0
[1244] __fnbamd_ldap_dn_next-No DN is found.
[1053] __ldap_rxtx-Change state to 'Done'
[986] __ldap_rxtx-state 23(Done)
[1083] fnbamd_ldap_send-sending 7 bytes to 192.168.1.17
[1096] fnbamd_ldap_send-Request is sent. ID 3
[785] __ldap_done-svr 'XPTOSP'
[755] __ldap_destroy-
[724] __ldap_stop-Conn with 192.168.1.17 destroyed.
[2774] fnbamd_ldap_result-Continue pending for req 803881880
[1428] fnbamd_auth_handle_radius_result-Timer of rad 'RADIUS-XPTO' is deleted
[1862] fnbamd_radius_auth_validate_pkt-RADIUS resp code 2
[362] extract_success_vsas-FORTINET attr, type 6, val super_admin
[323] extract_success_vsas-FORTINET attr, type 1, val Firewall_Admins
[1454] fnbamd_auth_handle_radius_result-->Result for radius svr 'RADIUS-XPTO' 172.16.0.173(1) is 0
[1616] fnbam_user_auth_group_match-req id: 803881880, server: RADIUS-XPTO, local auth: 0, dn match: 0
[277] find_matched_usr_grps-Passed group matching
[209] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 803881880, len=2640
[792] destroy_auth_session-delete session 803881880
[755] __ldap_destroy-
[1764] fnbamd_ldap_auth_ctx_free-Freeing 'XPTOSP' ctx

Thank you in advance!
#Fortigate #RadiusWildcard

[dbhavsar]

Hello @rsteixeira ,

would it be possible to provide the pcaps from both the ends? I see RADIUS responded with code 2 but still can you try with default authentication method?

[rsteixeira]

Unfortunately is not allowed for me share one pacap file once it will show confidential informations.
I didn´t understand what you mean about default authentication method. You mean use a local admin user to authentication on Firewall?
If yes, the local auth works fine or if we create the local user pointing to remote radius group its also works.

RADIUS server logs shows always sucess, if we try user test connection on gui on radius server configuration the test is also works. The same behavior if we try "diag test authserver radius " command by cli and work fine.

[maulishshah]

Hi @rsteixeira, In this scenario, you might have to open a case with the TAC so we can troubleshoot the issue to verify why Radius authentication failed.  

Thank you. 

Best Regards, 

Maulish Shah

[Markus_M]

Hi,

debug shows the authentication works fine (as you know already). So the GUI should give you a no-access message and profile. You can test changing the no-access to something that has access to test against the access-profile.

Run debug differently in this way:

diag debug console timestamp enable
diag debug app fnbamd -1
diag debug app httpsd -1
diag debug enable

httpsd will be the web server that seems to fail, since the authentication as the other part works.

Best regards,

Markus

[Debbie_FTNT]

Hey rsteixeira,

from the debug, it does look like RADIUS returns both a group, Firewall_Admins, and an admin profile, super_admin; this should override the no_access admin profile you've set as default in the wildcard admin.

I'm not seeing any issue with the RADIUS side of things.

It is strange that FortiGate is also trying to authenticate the user to LDAP - do you have a second wildcard admin configured, or anything of the sort? In the group itself "GRP-RADIUS-XPTO" I do not see an LDAP server referenced. The fact that LDAP is also queried indicates to me that perhaps there's a second group/wildcard admin somewhere, and FortiGate has issues matching the login to the correct group or wildcard admin maybe?

Can you gather fnbamd debug from a working 7.0 FortiGate and compare? Assuming they have the same configuration, you should see roughly the same output, and it would be interesting to know if there is also LDAP involved in that case.