Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-24051

Deleting a user does not remove the user from its LDAP group

      Jira team: I believe this to be a JIRA bug because this scenario does not reproduce in Confluence when it is linked to Crowd.

      • Add an LDAP directory to Crowd. Make sure to have the "jira-users", "jira-administrators" and "jira-developers" groups exist in LDAP.
      • Add Crowd Server as a directory to Jira, set it as the first directory.
      • Add a user in Jira. Notice that in the LDAP server, the jira-users group will show the new user.
      • Delete the user from Jira

      Expected: The entry in the jira-users group in LDAP to be deleted.

      Actual: The entry is not removed. "jira-users" group is left with an entry that does not point to any users.

            [JRASERVER-24051] Deleting a user does not remove the user from its LDAP group

            VitalyA added a comment -

            I've updated the priority based on JRA-38822

            VitalyA added a comment - I've updated the priority based on JRA-38822

            I've temporarily removed this issue from the backlog as we need to think about the best way to handle it. These discussions won't happen within the time for fixing LDAP issues.

            Eric Dalgliesh added a comment - I've temporarily removed this issue from the backlog as we need to think about the best way to handle it. These discussions won't happen within the time for fixing LDAP issues.

            I have worked on this throughout the day and I have traced the root cause of the issue to crowd's SpringLDAPConnector class which is the one that's actually responsible from removing the user record from the LDAP Directory.

            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.

            This needs to be adressed in crowd itself, will raise a crowd bug and link it to this issue.

            Oswaldo Hernandez (Inactive) added a comment - I have worked on this throughout the day and I have traced the root cause of the issue to crowd's SpringLDAPConnector class which is the one that's actually responsible from removing the user record from the LDAP Directory. 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. This needs to be adressed in crowd itself, will raise a crowd bug and link it to this issue.

            feedback from our customer provided in SAC:

            ...The issue is in the database only, as it should not be retaining these users details. The retention of the user details has privacy and storage (backups are bigger than they need be) implications. I was expecting that when we refined the directory filters it would remove the users from the database in the same way that it removes the AD groups, but they remain.

            The UI is not showing the shadowed users, and the instance is otherwise working as expected/intended.

            Bogdan Dziedzic [Atlassian] added a comment - feedback from our customer provided in SAC: ...The issue is in the database only, as it should not be retaining these users details. The retention of the user details has privacy and storage (backups are bigger than they need be) implications. I was expecting that when we refined the directory filters it would remove the users from the database in the same way that it removes the AD groups, but they remain. The UI is not showing the shadowed users, and the instance is otherwise working as expected/intended.

            This has no side effects in JIRA but should probably be fixed. Should this be done by the Embedded Crowd layer? Probably.

            Trevor Campbell (Inactive) added a comment - This has no side effects in JIRA but should probably be fixed. Should this be done by the Embedded Crowd layer? Probably.

              ohernandez@atlassian.com Oswaldo Hernandez (Inactive)
              farmas Federico Silva Armas [Atlassian]
              Affected customers:
              3 This affects my team
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: