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

Delegated LDAP does not synchronise on login the memberships of remote groups if they are shadowed by a local group

    XMLWordPrintable

Details

    • Bug
    • Resolution: Answered
    • Low
    • None
    • 2.8.3
    • None

    Description

      Steps to reproduce

      1. Start a new instance of Crowd 2.8.3
      2. Add a Delegated LDAP directory (I use a local OpenLDAP), make sure “Synchronise user details” and “Synchronise group memberships” are checked
      3. Add the Delegated LDAP directory to the crowd application as the first directory.
      4. (Using an uncached Connector from Crowd or any LDAP tool) Create a user user and two groups group1 and group2 in LDAP. Add the user to both groups in LDAP.
      5. Using Crowd, create group2 in the Delegated directory, but not group1.
      6. Log in to Crowd as user.

      Expected result

      On login, the first group (group1) is copied to the Delegated directory in the database (is_local=false). The second group (group2) is not copied because it already exists locally (is_local=true) and therefore it is shadowed.

      The membership of user to group1 and group2 is synchronised to the database.

      Observed behaviour

      On login, the first group (group1) is copied to the Delegated directory in the database (is_local=false). The second group (group2) is not copied because it already exists (is_local=true).

      The membership of user to group1 is copied, but the membership of user to group2 is not copied. While not overriding the definition of the local group is the expected behaviour, not synchronising the membership is a bug.

      At the same time, in the console we see

      WARN [atlassian.crowd.directory.DelegatedAuthenticationDirectory] Remote group "group2" in directory "Delegated authentication directory" is shadowed by a local group of the same name and will not be imported..
      

      Workarounds

      • I've verified that manually changing the is_local field of the affected group from "true" to "false" and logging in again as the user brings the membership to Crowd. This change cannot be made using the UI, it must be made directly in the cwd_membership table of the database.
      • If the group does not have any valuable information attached to it, then delete the local group using the UI and it will be re-created when the user logs in again.
      • Uncheck the "Synchronise group memberships" option from the directory configuration and create the memberships manually after the user logs in.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              dberrueta Diego Berrueta
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: