| Description |
This article describes the FortiGate behaviour when different types of remote authentication servers, TACACS+ and RADIUS, are used to authenticate administrators.
When an administrator username needs to be validated against multiple remote servers which use different authentication protocols such as TACACS+ and RADIUS and share different backend username databases, it is possible to define different destination servers inside the system administrator profile.
When a user tries to access the device, simultaneous authentication requests will be sent to the remote user group members (different authentication server types, TACACS+ and RADIUS), and the credentials will be checked against all members in the list until first success if received from any server.
Assuming the TACACS+ server does not have a user in the database, the server will reply with failure, but the RADIUS server has and will reply with success - FortiGate will receive a reply from both servers and allow user from the RADIUS server even if it received failure from the TACACS+ server. |
| Solution |
- Under the VDOM, create TACACS+ and RADIUS server profiles. For the RADIUS server, Go to User & Authentication -> RADIUS Servers-> Create New:
For the TACACS+ server, go to User & Authentication -> TACACS+ Servers-> Create New:
- Create a User Group. Go to User & Authentication -> User Groups -> Create New.
- In the Global mode, create an Administrator authentication profile. Go to System -> Administrators -> Create New:
- Testing the authentication with the user 'radius', which exists only in the database on the remote server - RADIUS_SERVER:
GUI and CLI:
Debug output:
2024-09-23 14:09:35 [329] __create_access_request-Compose RADIUS request
2024-09-23 14:09:35 [587] __create_access_request-Created RADIUS Access-Request. Len: 115.
2024-09-23 14:09:35 [1660] fnbamd_socket_update_interface-vfid is 2, intf mode is 0, intf name is , server address is 10.5.146.35:1812, source address is null, protocol number is 17, oif id is 0
2024-09-23 14:09:35 [765] __rad_rxtx-Sent radius req to server 'RADIUS_SERVER': fd=11, IP=10.5.146.35(10.5.146.35:1812) code=1 id=19 len=115
2024-09-23 14:09:35 [774] __rad_rxtx-Start rad conn timer.
2024-09-23 14:09:35 [393] is_sock_connected-tcp connected
2024-09-23 14:09:35 [500] build_authen_start-building authen start packet: authen_type=2(pap)
2024-09-23 14:09:35 [804] tac_plus_result-Authen sending request
2024-09-23 14:09:35 [408] pak_send-Encrypting pkt
2024-09-23 14:09:35 [1136] fsm_tac_plus_update_result-Continue pending for req 932659360
2024-09-23 14:09:35 [732] __rad_rxtx-fd 11, state 1(Auth)
2024-09-23 14:09:35 [734] __rad_rxtx-Stop rad conn timer.
2024-09-23 14:09:35 [777] __rad_rxtx-
2024-09-23 14:09:35 [365] __rad_udp_recv-Recved 38 bytes. Buf sz 8192
2024-09-23 14:09:35 [1136] __rad_chk_resp_authenticator-ret=0
2024-09-23 14:09:35 [1201] fnbamd_rad_validate_pkt-RADIUS resp code 2
2024-09-23 14:09:35 [804] __rad_rxtx-
2024-09-23 14:09:35 [1253] fnbamd_rad_process-Result from radius svr 'RADIUS_SERVER' is 0, req 932659360
Wireshark output:
Notes:
In this case, RADIUS Access-Accept arrived first and the firewall allowed the user. However, if the reply from the TACACS arrived first as a fail, the firewall would still wait for RADIUS response and would still allow the user based on the RADIUS Access-Accept response.
Related documents:
|
