Hello fellow Fortinet users,
I have a Cisco 55xx WLC that's currently using Cisco ISE for AAA.
Considering the fact that the ISE and fortigate are incompatible when it comes to accounting my only choice was to configure the WLC to send accounting messages directly to the fortigate.
While I can see all the different types of accounting messages from the WLC on the fortigate, it's unable to fingerprint users in the logs.
I went through support and they kinda gave up on me and said that the logs HAVE to come from a RADIUS server.
Has anyone got this working or can suggest a way for me to overcome this problem?
Cheers,
Vignesh
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hi,
not sure about ISE, never used it, but in general there is not important who is sending Accounting to FGT, but it has to come with certain fields populated (basically and in default FGT looks for Calling-Station-Id, Framed-IP-Address and Class).
Minimal config on FGT is then :
---
config user radius
edit "RAD_RSSO" set rsso enable next
end
config system interface edit "port1" set vdom "root" set ip 10.0.0.254 255.255.252.0 set allowaccess ping https ssh radius-acct set type physical set snmp-index 1 next end
config user group edit "RSSO" set group-type rsso <--- set sso-attribute-value "rsso-auth-group" <--- This string has to full match to content of AVP set in sso-attribute (Class by default) next end
As far as the source (NAS (WLC) or RADIUS server) is able to send those AVPs populated with correct data it will work.
Both user identification (set rsso-endpoint-attribute Calling-Station-Id) and profile/group match attribute string (set sso-attribute + set sso-attribute-value) are optional.
!! Content of the sso-attribute-value has to be found and string matching to what is received value of AVP set in sso-attribute !!
Troubleshoot:
- check WLC config that it is sending accounting to correct IP
- diag sniff packet / Wireshark the RADIUS traffic (default port is 1813) and check AVPs and the content
- diag test app radiusd X <--- where X is debug code , 0 for codes listing
- diag debug app radiusd -1
Kind regards,
Tomas
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Hi Tomas,
Thanks for your reply.
I'm not looking to do any group matching as yet to be honest.I just want to be able to see a username/ID in front of the IP in the logs ( like with the FSSO ).
Here's an excerpt of my configuration:
edit "INTERNAL-LAN" set vdom "DATA" set ip x.x.x.x 255.255.255.0 set allowaccess ping https ssh http fgfm radius-acct capwap ftm
edit "RADIUS-SSO" set rsso enable set rsso-radius-response enable set rsso-validate-request-secret enable set rsso-secret ENC lhzoQJnp7ZvUIDggrQhlWN3s/UqPZP0FOcC9D5Kquleu6Bxh8l//W06n6Jpk1aLhy8yjse5WRgqiEkXW6ud73V+1LU6HC5viTM476Jc+edFYJ0YqBRRqFnkyNGkW1hgvnGVZz+abVO67nvvGTVSx+oPE/bUr9+LWz/mZa/irWMy25mvLC0EOdVxe2vJU8+7Sv7b40g== set rsso-endpoint-attribute User-Name
edit "RADIUS-GROUP1" set group-type rsso set sso-attribute-value "GROUP1" next
From my packet capture, I can tell that the class attribute appears mangled and there sure is a problem and thereby I understand the group mapping will not work but I'm wondering why I don't see the username beside the IP in the logs.
To make this clear:
Please see
Screenshot-1: User-Name, called statid ID, calling station ID etc are visible.
Screenshot-2: For Framed-IP-Address 10.84.3.36 under logs, there's no user mapped to this.
Screenshot-3: Works perfectly for FSSO.
My question is, am I missing something here? I've set the set rsso-endpoint-attribute User-Name and this is what my account message is seeing but just does not log it. Please note that I do not see any RSSO under user monitor in the logs either.
Any help here would be greatly appreciated.
Cheers,
Vignesh
Hi,
not sure about ISE, never used it, but in general there is not important who is sending Accounting to FGT, but it has to come with certain fields populated (basically and in default FGT looks for Calling-Station-Id, Framed-IP-Address and Class).
Minimal config on FGT is then :
---
config user radius
edit "RAD_RSSO" set rsso enable next
end
config system interface edit "port1" set vdom "root" set ip 10.0.0.254 255.255.252.0 set allowaccess ping https ssh radius-acct set type physical set snmp-index 1 next end
config user group edit "RSSO" set group-type rsso <--- set sso-attribute-value "rsso-auth-group" <--- This string has to full match to content of AVP set in sso-attribute (Class by default) next end
As far as the source (NAS (WLC) or RADIUS server) is able to send those AVPs populated with correct data it will work.
Both user identification (set rsso-endpoint-attribute Calling-Station-Id) and profile/group match attribute string (set sso-attribute + set sso-attribute-value) are optional.
!! Content of the sso-attribute-value has to be found and string matching to what is received value of AVP set in sso-attribute !!
Troubleshoot:
- check WLC config that it is sending accounting to correct IP
- diag sniff packet / Wireshark the RADIUS traffic (default port is 1813) and check AVPs and the content
- diag test app radiusd X <--- where X is debug code , 0 for codes listing
- diag debug app radiusd -1
Kind regards,
Tomas
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Hi Tomas,
Thanks for your reply.
I'm not looking to do any group matching as yet to be honest.I just want to be able to see a username/ID in front of the IP in the logs ( like with the FSSO ).
Here's an excerpt of my configuration:
edit "INTERNAL-LAN" set vdom "DATA" set ip x.x.x.x 255.255.255.0 set allowaccess ping https ssh http fgfm radius-acct capwap ftm
edit "RADIUS-SSO" set rsso enable set rsso-radius-response enable set rsso-validate-request-secret enable set rsso-secret ENC lhzoQJnp7ZvUIDggrQhlWN3s/UqPZP0FOcC9D5Kquleu6Bxh8l//W06n6Jpk1aLhy8yjse5WRgqiEkXW6ud73V+1LU6HC5viTM476Jc+edFYJ0YqBRRqFnkyNGkW1hgvnGVZz+abVO67nvvGTVSx+oPE/bUr9+LWz/mZa/irWMy25mvLC0EOdVxe2vJU8+7Sv7b40g== set rsso-endpoint-attribute User-Name
edit "RADIUS-GROUP1" set group-type rsso set sso-attribute-value "GROUP1" next
From my packet capture, I can tell that the class attribute appears mangled and there sure is a problem and thereby I understand the group mapping will not work but I'm wondering why I don't see the username beside the IP in the logs.
To make this clear:
Please see
Screenshot-1: User-Name, called statid ID, calling station ID etc are visible.
Screenshot-2: For Framed-IP-Address 10.84.3.36 under logs, there's no user mapped to this.
Screenshot-3: Works perfectly for FSSO.
My question is, am I missing something here? I've set the set rsso-endpoint-attribute User-Name and this is what my account message is seeing but just does not log it. Please note that I do not see any RSSO under user monitor in the logs either.
Any help here would be greatly appreciated.
Cheers,
Vignesh
Hi Vignesh,
i know it's an old post but did you find a way to make this work?
I'm trying to do exacly the same thing!
Thanks!
Hi,
missed your post.
Have you checked in Wireshark that any one of your Class does contain mentioned "GROUP1" as string ?
Also, once your FGT receive RADIUS Accounting request it should write a debug output on console (SSH).
Class is AVP which can be present multiple times AFAIK.
But that should not prevent any debug.
My examples:
---
config user radius edit "RSSO Agent" set rsso enable set rsso-radius-response enable set rsso-validate-request-secret enable set rsso-secret <superpassword> set rsso-endpoint-attribute User-Name
.. note there is no sso-attribute as default is used, which is AVP Class next end
config user group edit "RSSO-1" set group-type rsso set sso-attribute-value "RSSO-1" next end
config system interface edit "port1" set vdom "root" set ip 192.168.50.251 255.255.255.0 set allowaccess ping https ssh snmp http fgfm radius-acct ftm next end
Used NTEadPing to send artificial RADIUS Accounting packets
[Screenshot]
FGT Debug:
FGVM_251 # diag debug app radiusd -1 Debug messages will be on for 30 minutes.
FGVM_251 # FGVM_251 # diag debug enable
FGVM_251 # diag sniff pack any 'port 1813' 6 0 a interfaces=[any] filters=[port 1813] Received radius accounting eventvd 0:root Add/Update auth logon for IP 10.10.10.1 for user userd DB 0 insert [ep='userd' pg='tets+RSSO-1' ip='10.10.10.1/32'] success 2021-08-04 09:17:43.307525 port2 in 192.168.32.1.62454 -> 192.168.32.251.1813: udp 60 0x0000 0000 0000 0001 0050 56c0 0001 0800 4500 .......PV.....E. 0x0010 0058 3c8e 0000 8011 3bba c0a8 2001 c0a8 .X<.....;....... 0x0020 20fb f3f6 0715 0044 4613 0401 003c c773 .......DF....<.s 0x0030 e9b8 8518 71f9 534e e895 fde6 550e 0107 ....q.SN....U... 0x0040 7573 6572 6428 0600 0000 012c 0731 3232 userd(.....,.122 0x0050 3634 0806 0a0a 0a01 1906 7465 7473 1908 64........tets.. 0x0060 5253 534f 2d31 RSSO-1
Following RADIUS packet is just confirmation back to sender, because of 'rsso-radius-response enable' is set
2021-08-04 09:17:43.307875 port2 out 192.168.32.251.1813 -> 192.168.32.1.62454: udp 20 0x0000 0000 0000 0000 000c 2974 c5a8 0800 4500 ........)t....E. 0x0010 0030 5833 0000 4011 603d c0a8 20fb c0a8 .0X3..@.`=...... 0x0020 2001 0715 f3f6 001c 833a 0501 0014 29cc .........:....). 0x0030 159b 0e37 e959 99b2 2125 dd83 eab9 ...7.Y..!%....
Received radius accounting eventDB 0 insert [ep='userd' pg='tets+RSSO-1' ip='10.10.10.1/32'] success
2 packets received by filter 0 packets dropped by kernel
Then let's check results.
FGVM_251 # di test application radiusd 3 RADIUS server database [vd root]: "index","time left","ip","endpoint","block status","log status","profile group","ref count","use default profile" 1,07:59:50,"10.10.10.1""userd","allow","no log","tets+RSSO-1",1,No
As you can see, two Class AVPs merged to one field of "profile group"
FGVM_251 # Received radius accounting eventvd 0:root Add/Update auth logon for IP 10.10.10.2 for user usere DB 0 insert [ep='usere' pg='random' ip='10.10.10.2/32'] success
FGVM_251 # di test application radiusd 3 RADIUS server database [vd root]: "index","time left","ip","endpoint","block status","log status","profile group","ref count","use default profile" 1,07:54:13,"10.10.10.1""userd","allow","no log","tets+RSSO-1",1,No 2,07:59:50,"10.10.10.2""usere","allow","no log","random",1,No
Sent another user with just "random" as Class string .. which is taken as possible group, but that group is not on FGT and so user will not match in policy and will be useless however it is logged
FGVM_251 # Received radius accounting eventMissing profile name.vd 0:root Add/Update auth logon for IP 10.10.10.3 for user userf
DB 0 insert [ep='userf' pg='n/a' ip='10.10.10.3/32'] success
FGVM_251 # di test application radiusd 3 RADIUS server database [vd root]: "index","time left","ip","endpoint","block status","log status","profile group","ref count","use default profile" 1,07:52:12,"10.10.10.1""userd","allow","no log","tets+RSSO-1",1,No 2,07:57:49,"10.10.10.2""usere","allow","no log","random",1,No 3,07:59:45,"10.10.10.3""userf","allow","no log","<default profile>",1,Yes
And the last user added, sent without any Class attribute, so from FGT point of view he has no groups, or more precisely will fall into default, that's why <default profile> and Yes at the end is mentioned.
However, unless as in traditional RADIUS group match, the RSSO allows you to change which AVP will be used to that group match! Default sso-attribute is Class, but it could be some other string based AVP .. Just go CLI and edit that RSSO radius user, and then .. "set sso-attribute ?" and that should list multiple default dictionary AVPs you can use.
I would also suggest to check that "rsso-endpoint-block-attribute" is unset, or set to some AVP which is not used and shown in Accounting packet. As if there will be any string like "b/B/block/Block" then record should be in block state, however that should still be visible in radiusd debug.
Tomas Stribrny - NASDAQ:FTNT - Fortinet Inc. - TAC Staff Engineer
AAA, MFA, VoIP and other Fortinet stuff
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1692 | |
1087 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.