Joining the Conversation
Joining the ConversationHi Andri
We also face Cato client connectivity issues when users go on MFLA as our company policy is to disable the users account once they start their leave. Cato then detects that the users account is disabled and removes it from CMA. When the user returns and the account is enabled, our helpdesk teams have to uninstall the cato client and reinstall it from their workstation as the SDP client detects a different profile preventing the users from successfully connecting. It make it challenging for the user as they have to leave or ship their laptop to IT. Therefore we have updated SOP's for different teams when users go on MFLA.
Can Cato find a way to streamline this process as most of our users tend to work remotely or sites are in different geographical locations and does not make sense to ship the laptop to corporate office and back to user?
Joining the ConversationOh yes, thats another issue we have. So far the solution is to reinstall the Cato client like you said. Given the Always On policy enabled, its not easy to access the user machine in this case.
Hope Cato can add exceptions or bypass for Always On policy.
Staying InvolvedWe’ve seen this issue as well (we use SCIM provisioning from Entra ID). One would think that a user that is disabled in the source catalog is merely disabled in Cato as well, ready to be seamlessly re-enabled when the user returns. Likely the issue is that we are removing those temporarily disabled users from the synced group (as they otherwise still consume a license in Cato) and as such will be recreated as a new user object when added back to the group (requiring a reinstall). Kind of makes sense I guess, even if the need to reinstall the client appears a bit excessive - Cato should be able to link up to the same UPN.
