What i am puzzled here is the different combination og fimers from Clearpass, Roles such as LUR, and switch-port
* The session timer that can be returned from Clearpass, terminates a session. Some seem to think it's a reauthentication timer. it's an authentication that happens and not a re-authentication. The reason for this, is that when you set a session timer, the switch "show port-access xxxx" will list it as session and not reauthentication
Apparently it's the only timer available that you can set via RADIUS
* Then theres the actual reauthentication timer that only seems to be possible to set on the actual switch port and via a LUR. On the port og in the LUR you cant set an actiual session timeout, only reauthentication
* Then theres the client-inactivity timer, that can only be set in a LUR
Combos are here.
If a LUR is used, the radius session timer is ignored.
The question here is
Why use a session timeout at all???? i can understand a reauth timer and a inactivity timer
But i an trying to find a combo here of authentication and inactivity on 3 cases
1. 1. Dynamic devices such as clients, smartphones etc.
2. 2. Active network devices, specifically Access Point
3. 3. Semi active devices such as printers.
Original Message:
Sent: May 17, 2023 07:53 AM
From: Herman Robers
Subject: Client re-auth / timeout best practices.
For silent/inactive devices, you can set the inactivity-timeout in the user-role:
inactivity-timeoutThe inactivity timeout period in seconds with a range of 300 to 4294967295 for the authenticatedclient 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.
Original Message:
Sent: May 16, 2023 10:32 AM
From: Jason Mc
Subject: Client re-auth / timeout best practices.
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
------------------------------