Security

 View Only
last person joined: 10 hours ago 

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

Client re-auth / timeout best practices.

This thread has been viewed 20 times
  • 1.  Client re-auth / timeout best practices.

    Posted May 16, 2023 10:32 AM

    Client re-auth / timeout best practices.

    This may be a better question for the "Wired" group but does relate to CPPM so I figured I would start here.

    I have a CPPM deployment that I am primarily do 802.1X authentication, however I have a number of devices I am having to MAC auth as well.  I ran into my first issue as we have been bringing sites onto the new platform.  It is concerning a printer and industrial controller type device.  It appears when these devices are idle for some time I am catching some sort of timeout.  After being idle for a while the devices are unreachable.  I know this is not a firewall or routing issue as one of the devices is on the same VLAN as the workstation trying to communicate with it.

    So here's the question.  Should I set a re-auth periodically for 30 to 60 minutes?  What is the best practice around forcing reauthentication or quiet time?

    Thanks in advance.  Let me know if you all think I should move this to the Wired Community but would like to know what the experts think here as well.

    PS.  All switches are CX using roles to map ports to VLANs.



    ------------------------------
    Thanks,
    Jason
    ------------------------------


  • 2.  RE: Client re-auth / timeout best practices.

    EMPLOYEE
    Posted May 16, 2023 08:15 PM

    i think the main thing is to know your wired clients and then your org's security policy.
    You can have "reauth period" based on switch port, VLANs and user-role
    I suggest to have the reauth period based on user-roles that way you can fine tune it without impacting other things.
    The choices you have are
    - authentication reauth period (default is 3600 sec) again you should set this based on your sec policy
    - authentication cache-reauth period (default is 30 sec)  as an example you can set it to 86400 sec <<<<this is mainly for Auth surviveability when RADIUS server is offline.

    quite-period, is the time for which the switch wont attempt to authenticate a rejected client.
    generally in this case you have enabled "port-access onboarding-method concurrent enable" command, so you need for the device to have a restricted access on the network and get DHCP/DNS and perhaps to enroll in something that needs IP connectivity.

    Generally you can start with " quiet-period 30" and see if that provides enough time.



    ------------------------------
    If my post was useful accept solution and/or give kudos.
    Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.
    ------------------------------



  • 3.  RE: Client re-auth / timeout best practices.

    EMPLOYEE
    Posted May 17, 2023 07:53 AM

    For silent/inactive devices, you can set the inactivity-timeout in the user-role:

    inactivity-timeout
    The inactivity timeout period in seconds with a range of 300 to 4294967295 for the authenticated
    client for an implicit logoff.

    Setting the session-timeout (RADIUS) or reauth period determines when a reauthentication should occur. For silent devices that are MAC authenticated that doesn't work because a MAC authentication only happens when the client generates traffic. By default, if you have the reauth/session-timeout on let's say 300 seconds, then 300 seconds after the authentication, the port will go unauthorized again, then at first traffic seen from the device again it will do the MAC auth and authorize the port. For silent devices, on most switches (that don't have the inactivity timeout) the advice would be to set the reauthentication interval as long as possible or disable reauthentication, so the client port will not get unauthorized, or only as few as possible. With the inactivity-timeout on CX the port should stay authorized and trigger a new authentication only when the client sends traffic.



    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------



  • 4.  RE: Client re-auth / timeout best practices.

    Posted May 17, 2023 09:21 AM

    Herman,

    Thanks for your response.  This is exactly the information I was seeking.

    In my reading last night I had found the inactivity command and had applied it to some of the roles in the switch as a test.  This seems to have resolved our issues.  This just leaves a couple of lingering questions in my mind.

    1) I used the "client-inactivity timeout none" form of the command.  Does this represent any issues in the term of security or other unforseen issues?
    2) Since the organization I am working for, I would consider a connectivity over security mindset, I really can't think of any reason I would use reauth unless there is a reson I am overlooking.

    Thanks to both Herman and aryiap.  It is greatly appreciated.




  • 5.  RE: Client re-auth / timeout best practices.

    Posted May 21, 2023 11:10 PM

    Anyone have any perspective on this?  Thanks!




  • 6.  RE: Client re-auth / timeout best practices.

    EMPLOYEE
    Posted May 25, 2023 10:56 AM

    For 1, I would say no because if the client comes online again it will reauthenticate. The only point I could think of is that without a client-inactivity timeout the port will also send traffic to the client forever as the role will not be removed. With a timeout, after the timeout the port should be fully deauthorized and not even receive broadcast/multicast traffic on that port. But given the statement 'connectivity over security', this setting would match that.
    For 2, it may be the balance of security. If you never reauth, you also may not see what devices are active on the network as with a reauth you can see the authentication in your RADIUS server (like ClearPass). If it is connectivity over every risk, then you are correct. However the usual procedure is to analyze the risk and balance that with the amount of security measures you put to that risk to mitigate. Ignoring each and every risk is quite uncommon.



    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------