Forum Discussion

Rafa's avatar
Rafa
Icon for Joining the Conversation rankJoining the Conversation
1 month ago

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 encoun...
access
monitoring
network
sdp
  • Rafa's avatar
    Rafa
    Icon for Joining the Conversation rankJoining the Conversation
    1 month ago

    Hi Bizzle90,

    yes we have. We read up on the LDAP to SCIM migration but have some questions about the migration and how users will be identified since User Awareness relies on LDAP Directory Services.

    Instead of syncing the existing LDAP groups to Entra, could we create new groups in Entra, add the groups to the Cato SCIM enterprise app and add these groups to all the rules where the LDAP groups are configured to stage ahead of time? Then at some point after testing and when ready to migrate, add the users to the Entra ID groups previously created?

    Most desktops are Shared as operations runs multiple shifts and we don't install the Cato SDP client on workstations; we only install it on laptops since desktops are stationary. How will Cato identify users that don't have the Cato SDP client on a Shared computer since UA relies on Directory Services? We're not seeing LAN IP addresses inside Entra ID for login events so we don't understand how Cato will identify, correlate user, device to an IP.

    We have Always-On Policies and Windows RegKey to protect laptops when it goes off-prem. I'm assuming that both of these will need to be disabled in preparation for the migration and reenabled after the migration?

    Also, when cutting over one domain to SCIM, could we do this without affecting the child domain or should both top domain and child domain(s) be cut over at the same time?

    Thanks in advance for any feedback. 

    • bizzle90's avatar
      bizzle90
      Icon for Cato Employee rankCato Employee
      1 month ago

      Hey Rafa,

      Thank you for the questions. I will try to answer them as best as I can. I do want to add, however, I do recommend using our professional services for migration/deployment advice.

      So, the first and foremost, your migration/strategy plan is a good approach, just remember to test...test...and test!

      As mentioned in our KBs, please note:

      • User and group attributes (email, UPN, first name, last name) must be identical in both Entra ID and LDAP to prevent duplicate objects.
      • SCIM provisioned groups override LDAP groups with the same name.
      • Users are automatically removed from LDAP groups and added to SCIM groups when the migration occurs.

      Regarding UA identity, since you are not using an On-Prem server for user mapping and plan to use SCIM, you need to use the Identity Agent (IA) feature with Cato. This requires the Cato SDP client to be installed on your machines. 

      I have provided both KBs below, please do have a good read:

      https://support.catonetworks.com/hc/en-us/articles/13815807963293-Using-Cato-Identity-Agents-for-User-Awareness

      With the below KB, I believe this feature is still in EA (Early Access), so this may be something that could also interest you, where you don't need a ZTNA license for UA authentication:

      https://support.catonetworks.com/hc/en-us/articles/33142804221725-Using-Cato-Identity-Agents-for-User-Awareness-EA-Authentication-without-a-ZTNA-License

      So, regarding Entra logins, I believe that Entra ID login events don't contain internal LAN IP addresses; the IA reports data to the respective Cato PoP, which contains the user identity and the socket/site the user is connected to.

      I am aware that we have UA for shared hosts, but it requires an active on-prem AD, so I think it will not work in your scenario.

      Yes, you are correct. I would recommend disabling  Always-On during migration and re-enabling post-migration. 

      Finally, I am not a Windows Server expert (sorry to say), but logic/common sense tells me you should aim to cut over the parent/child domain together! I would recommend speaking with your respective experts internally on this, as I believe other factors may need some consideration, like group mappings (I.,E cross-domain nested groups, authentication etc).

      I hope this helps!