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.
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-roleI 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.
For silent/inactive devices, you can set the inactivity-timeout in the user-role:
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,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.
inactivity-timeoutThe inactivity timeout period in seconds with a range of 300 to 4294967295 for the authenticatedclient for an implicit logoff.
Anyone have any perspective on this? Thanks!
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.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.