LDAP To SCIM Migration
We are planning to migrate from Cato Directory Services LDAP & User Awareness to Cato SCIM user provisioning and looking to get some feedback if anyone has performed this migration and if they encountered any issues during the migrations. We currently have a few domains, over 3500 users and not everyone has an SDP lic, a mixture of Entra joined and non-Entra joined devices. SSO for VPN Users. I'm trying to understand how users are going to be mapped to the workstations they are logging in from and identified since Cato currently taps into DC's Event viewer to map users to computers and LAN IP's. We have Shared computers where an SDP license is not needed as these are fixed computers. We see the user login events, but not the details for the system they are logging in from and LAN IP. Will there be problems if we migrate 1 domain first and wait a week or two to iron out any bugs? Should Always-On Windows RegKey be removed from all systems prior the migration?
Visit website with error(HTTP Version Not Supported) with Cato
HTTP Version Not Supported Your client is using HTTP version 1.1, which is not supported. This service requires HTTP/2. Please update your client or contact support Reply from Cato Support : I have confirmed internally that HTTP/2 is not supported yet.
Endpoint Device DNS Resolution
When Cato is handling DHCP and DNS for all devices within an account across multiple vlans, across multiple sites, is it possible for a device to resolve the IP of a hostname outside of the local subnet that the device is on, using Cato DNS to resolve the hostname? We historically have had on-prem Windows AD providing DHCP/DNS which reliably provided name resolution from hostname to IP, but also reverse DNS for IP back to hostname. We are moving to Entra ID/Intune+Auto Pilot managed devices with the outlook to retire our on-prem servers entirely. We have various use cases where we need to resolve a hostname to have the IP returned, but also for the IP to resolve back to hostname via reverse DNS. This has become difficult for Entra ID managed devices unless the device is on the same local subnet where the site switch manages the resolution via the local mac table. Is mDNS the right approach and where I should focus my attention or is there an alternative I should consider? As is looks like mDNS is restricted to vlans within the same site, it may not work in our scenario where we need to resolve across sites. Any advice or recommendations are greatly appreciated.
Identifying the Cause of LDAP Synchronization Failure
Hello, We have been synchronizing accounts with an on-premises LDAP server. The synchronization worked normally until July 2nd, but it stopped working from July 3rd. We want to identify the cause, but it is difficult to investigate because the source IP shown in the web UI is different. Does anyone have any ideas on how to perform something like a traceroute from the source IP used for LDAP synchronization? Thank you for your assistance.Policy Rule Not Hitting When Destination is Set to 'Any' – Expected Behavior?
Hi all, I ran into a situation with a security policy in Cato and would like to hear if anyone else has experienced something similar. Here is the scenario: I created a policy where the source site is set to "Site A", the destination is set to "Any", and the application is defined as a specific IP address, for example 192.168.1.1. In this setup, the rule does not match and traffic is not allowed as expected. However, when I change the destination from "Any" to the specific site where 192.168.1.1 is located, the rule starts working correctly and the traffic is matched. My questions: Is this expected behavior in Cato? Does using "Any" as the destination somehow prevent matching traffic to a specific internal IP? Is there something else I might be missing? Appreciate any insights or experiences. Thanks!
