Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Back to discussions
Expand all | Collapse all

Accounting messages to Fortigate firewall

This thread has been viewed 3 times

  • 1.  Accounting messages to Fortigate firewall

    Posted Sep 24, 2014 09:06 PM

    Hi,

     

    We have configured Accounting server under AAA profiles. On the Accounting server (fortigate firewall) we receive several messages stating RADIUS start or interim-update packet received with missing or invalid profile specified

     

    Because of this reason some of the users are not put under the correct role on our Fortigate firewall. This happens every now and then for users and each time for different user. We are running code version 6.3.1.8

     

    We have to delete that particular user on aruba controller and when that user authenticates again the accounting messages sent properly and the user allocated correct role.

     

    Please advise.



  • 2.  RE: Accounting messages to Fortigate firewall

    Posted Sep 27, 2014 09:31 AM

    my advise, contact TAC.

     

    you might get lucky and someone has encountered it before but if you want a certain answer open a ticket with TAC. please so report the answer from TAC back here.

     

    be prepared to capture traffic from the ClearPass or at the Fortigate to determine if info is really missing. it could very well be there is a traffic issue in between which causes some packets to get lost. that is a downside of doing FSSO base on RADIUS like this.



  • 3.  RE: Accounting messages to Fortigate firewall
    Best Answer

    Posted Oct 05, 2014 04:18 PM

    I have read the release notes for ArubaOS 6.3.1.11 and it is stated:

     

    Symptom: When previously idle clients reconnected to the network, a configured CLASS attribute was
    missing from the accounting messages sent from the RADIUS server. This issue is resolved with the
    introduction of the delete-keycache parameter in the 802.1X authentication profile. When this
    parameter is enabled, it deletes the user keycache when the client's user entries get deleted. This
    forces the client to complete a full 802.1X authentication process when the client reconnects after an
    idle timeout, so the CLASS attributes will again be sent by the RADIUS servers.
    Scenario: This issue occurred in a deployment using RADIUS accounting, where the RADIUS server
    pushed CLASS attributes in the access-accept messages for 802.1X authentication. When an idle user
    timed out from the network, ArubaOS deleted the CLASS attribute for the user along with rest of the
    user data.

     

    I have updated to 6.3.1.11.

    I have enabled delete-keycache under Dot1x profile and will monitor it. Our school is close for another week and I will test it once school re-open.