Wireless Access

last person joined: 20 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Back to discussions
Expand all | Collapse all

Radius accounting with authenticated and unauthenticated users

This thread has been viewed 0 times

  • 1.  Radius accounting with authenticated and unauthenticated users

    Posted Feb 21, 2017 04:15 AM

    Hi,

     

    I have a customer who wants radius accounting for unauthenticated users and authenticated users.

     

    I am using elitecore aaa and aruba 7240 running 6.5.3.

     

    The way the elite core works is that when a user connects for the first time it sends a radius request with its mac-address to the aaa. The aaa responds with radius accept and the aruba user role "pre-auth". The user then registers through the splash page and logs in. At this point the user recieves a user role of authenticated and can browse the internet.

     

    The customer wants a accounting start when the user connects as an unauthenticated user and then a stop start when they login and become authenticated. 

     

    Does anybody know if this is possible?

     

    I am able to get an accounting start as soon as they connect by selecting "Captive Portal Check for Accounting" but i do not send a stop start when the user logs in. 

     

    It looks like the aruba only sends a stop when the session is cleared from the user table.

     

    I dont think this will work because the user is passing mac-auth so the aruba just sees it as a authenticated user even if its in pre-auth.

     

    if anyone can confrim that would be appriciated.

     

    thanks



  • 2.  RE: Radius accounting with authenticated and unauthenticated users

    EMPLOYEE
    Posted Feb 21, 2017 07:20 AM

    Typically how it works is that the accounting start is sent when the user logs in and stops when the user is aged out of the user table.  If you send the start upon user association, the data counting will start even before the user does anything.  With regards to the stop, it is sent after the user ages out of the user table.  If you would like the stop to be sent as soon as the user disassociates, you can set the user-idle-timeout in the captive portal authentication profile to zero:

     

    disassociation.png