Cisco ISE radius account directly to FSSO collector

[Nick Mavrou]

Hi there,

I was wondering to see if there is away to get Cisco ISE to send radius accounting directly to an FSSO collector installed in an AD, so the fortigate can see the wifi user which was authenticated and authorized by Cisco ISE. I know that is doable via pxGrid but that integration sends only one SGT per an authz condition to fortimanager. The goal here is once the user has passed from Cisco ISE to be visible in FSSO collector cos Fortigate/Fortimager applies policies according to the domain groups received from the collector. 

Cheers

[Milos_Jovanovic · Accepted solution]

Hi @Nick Mavrou,

I don't know how exactly FSSO agent is working, but I would assume it doesn't work much different from what other vendors are implementing - read AD logs, understand which user is mapped behind which IP, either through WMI or some other mechanism, and feed that info back to where needed (e.g. FWs for identity-based policies). Having that said, and assuming I'm right, then I would say no, as that agent is most likely capable to process only certain type of logs.

ISE is capable of sending accounting logs as a syslog, but the qestion is what tool can process that information and how to feed that data where needed, upon successfull parsing of relevant data. This is basically what pxGrid does.

Kind regards,

Milos

[ahollifield · Accepted solution]

ISE Cannot do this, your only option is syslog, not RADIUS.  Aruba ClearPass can though ;). 

Your other option is to relay RADIUS Accounting from the NADs to the FSSO collector rather than from ISE.    Or integrate ISE to FortiManager via pxGrid.

[Nick Mavrou]

Hi @ahollifield yes indeed ISE cannot do that, so I added as an additional accounting server on cisco meraki the FSSO collector. pxGrid is an option which I have done it already, but it is not really convenience for the client as he will need to apply extra policies on the fortigate according to the SGT now. He wants to stick with the FSSO groups. 

Back now to radius accounting from the cisco meraki APs, it seems that it does not work. I mean The AP sends the info but I do not see anything on the FSSO collector. I have enabled also the the collector to listen for radius accounting messages on port 1813 but not luck. To be fair I am not really familiar with the collector even if it is not so difficult to configure it.

[ahollifield]

The FSSO collector may not like the RADIUS accounting format sent from Meraki.  Fortinet TAC would be your next contact for that.

[Nick Mavrou]

Hi @ahollifield yes indeed it did work with the radius accounting being sent by the AP to FSSO collector. Fortunately, FSSO has the ability to listen to accounting messages. So once it receives the message which includes the user and the IP address, it does include him to  FSSO logon users, and instead of dc-agent type it shows as radius accounting type. All good! My only concern is how the Cisco meraki APs send the accounting messages because when someone logins to WiFi and gets authenticated the message it sends does not include the IP address. He has to reconnect again in order the AP to generate a new radius message, and on the new message the IP address appears. 

I understand that during the authentication the clients does not have an IP address and after the successful login the device gets the IP. By that time, the AP has already sent the accounting message without the IP address. After the second login, it does include  the IP address because the client has been already authenticated?

There is an option of Accounting interim interval in cisco meraki and the default time I see is 10 minutes. Does it help if I Change that?

[ahollifield]

AFAIK there is no ability to customize the accounting behavior on Meraki.  It is either enabled or not.  I would reach out to Meraki TAC, they may have some backend support-only changes they could make for you.

[Nick Mavrou]

Cheefrs @ahollifield and @Milos_Jovanovic  thanks for all the help. Setup with radius accounting works as expected. Have the issue with the initial radius message which is being sent but thats another story. Will need to raise it up with cisco meraki team so see if there is a workaround

[Paccers]

Hey @Nick Mavrou sorry to dredge up an old thread. We've also had the same issue with the Meraki Accounting-Start not containing the 'Framed-IP-Address' attribute. We've achieved a form of fix implementing a RADIUS Accounting start delay timer via Meraki support to delay the sending of the Start packet a few seconds, even then it does still send too quick sometimes.

Did you end up going down this path as well or something different?

[Nick Mavrou]

Hi @Paccers Paccers,

How much delay did you ask the support to apply for the accounting-start packet. I think for us it was something close to half second. Since we changed that we didn't face any issue. I think half second is more than enough to allow the device to get the IP address  before the accounting-start packet is being sent. By all means, it depends on how fast your DHCP server provides the IP addresses so I assume that your network doesn't have issues anyway. You could also try to max the delay to more than half second. By the end of the day it is not a bad user experience...

[Paccers]

2 seconds currently seems to be our sweet spot, below that we get way more failures to include Framed-IP-Address value. Are you sending on to FSSO collector to set up FSSO sessions not RSSO on the FGT?

[Nick Mavrou]

Yes that's right, straight to FSSO collector. In that case to might need to dive deeper and run a wireshark and check why you are facing that issue. I have to say though that the integration in question is not something that I would recommend anyway. I was forced to do that trick cos in my case the WiFi devices were out of AD. I assume you are having the same case...  

[Paccers]

Yup, got to love BYOD!