Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-3138

Removing a User from an LDAP Read/Write Directory does not remove the group memberships for that user

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Medium Medium
    • None
    • 2.4.8
    • Directory - LDAP

      Currently, the implementation of SpringLDAPConnector.removeUser(String name) simply removes the LDAP entry for the user but it doesn't clean up the membership references to the user stored in the group entries.

            [CWD-3138] Removing a User from an LDAP Read/Write Directory does not remove the group memberships for that user

            Do any LDAP directories actually maintain referential integrity? AD? ... obviously OpenLDAP does not!

            That's exactly my concern. LDAP admins may be surprised if Crowd implements "delete on cascade" on LDAP dirs.

            Diego Berrueta added a comment - Do any LDAP directories actually maintain referential integrity? AD? ... obviously OpenLDAP does not! That's exactly my concern. LDAP admins may be surprised if Crowd implements "delete on cascade" on LDAP dirs.

            Do any LDAP directories actually maintain referential integrity? AD? ... obviously OpenLDAP does not!

            But seriously ... providing an option is the 'easy way out' ... just make a decision. If you delete a group, you delete the memberships for the group. You delete a user, you delete the memberships for that user. This aligns with how the internal directory works, and really I think the 99% case with people using LDAP directly is '&%$ why didn't LDAP remove the memberships for the user I just deleted!'.

            Justin Koke added a comment - Do any LDAP directories actually maintain referential integrity? AD? ... obviously OpenLDAP does not! But seriously ... providing an option is the 'easy way out' ... just make a decision. If you delete a group, you delete the memberships for the group. You delete a user, you delete the memberships for that user. This aligns with how the internal directory works, and really I think the 99% case with people using LDAP directly is '& % $ why didn't LDAP remove the memberships for the user I just deleted!'.

            Diego Berrueta added a comment - - edited

            It seems reasonable that removing a user or a group should propagate the deletion in cascade. It may be dangerous to leave orphaned memberships that may reappear if later on a user or a group is created with the same name.

            At the same time, Crowd should not surprise sysadmins used to low-level LDAP tools that do not propagate deletions. Also importantly, all directory types should behave consistently.

            There are several approaches to this fix, including:

            • Adding a "propagate deletions on cascade" checkbox to the directory settings.
            • Refusing to delete a user until all references have been removed.
            • Unconditionally deleting all references on cascade, possibly giving some feedback to the user.

            Diego Berrueta added a comment - - edited It seems reasonable that removing a user or a group should propagate the deletion in cascade. It may be dangerous to leave orphaned memberships that may reappear if later on a user or a group is created with the same name. At the same time, Crowd should not surprise sysadmins used to low-level LDAP tools that do not propagate deletions. Also importantly, all directory types should behave consistently. There are several approaches to this fix, including: Adding a "propagate deletions on cascade" checkbox to the directory settings. Refusing to delete a user until all references have been removed. Unconditionally deleting all references on cascade, possibly giving some feedback to the user.

              Unassigned Unassigned
              ohernandez@atlassian.com Oswaldo Hernandez (Inactive)
              Affected customers:
              10 This affects my team
              Watchers:
              16 Start watching this issue

                Created:
                Updated: