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

Could not add the following missing users to group

    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Low Low
    • None
    • 2.5.3
    • Core features
    • None
    • Standalone Server in a ESX 5.1 virtual environment the OS is Linux Debian 6.0

      We have rename the user (Pra-kuebler) in the Windows LDAP and now we get the error message every 60 minute in the Logfile:

      2013-06-03 11:59:45,236 QuartzWorker-0 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] Could not add the following missing users to group [ DG_Intranet_CTI ]: [Pra-kuebler]
      2013-06-03 11:59:45,236 QuartzWorker-0 INFO ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] added [ 0 ] user members to [ DG_Intranet_CTI ] in [ 0ms ]
      2013-06-03 11:59:45,237 QuartzWorker-0 INFO ServiceRunner [directory.ldap.cache.AbstractCacheRefresher] found [ 1148 ] remote user-group memberships, [ 0 ] remote group-group memberships in [ 0ms ]
      2013-06-03 11:59:45,267 QuartzWorker-0 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] Could not add the following missing users to group [ DG_Intranet_DE_RAT ]: [Pra-kuebler]
      2013-06-03 11:59:45,267 QuartzWorker-0 INFO ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] added [ 0 ] user members to [ DG_Intranet_DE_RAT ] in [ 0ms ]
      2013-06-03 11:59:45,268 QuartzWorker-0 INFO ServiceRunner [directory.ldap.cache.AbstractCacheRefresher] found [ 617 ] remote user-group memberships, [ 0 ] remote group-group memberships in [ 0ms ]
      2013-06-03 11:59:45,278 QuartzWorker-0 INFO ServiceRunner [directory.ldap.cache.AbstractCacheRefresher] found [ 1382 ] remote user-group memberships, [ 0 ] remote group-group memberships in [ 0ms ]
      2013-06-03 11:59:45,325 QuartzWorker-0 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] Could not add the following missing users to group [ DG_Intranet_HRM_All ]: [Pra-kuebler]

            [CWD-3337] Could not add the following missing users to group

            Got same problem with IDM (freeIpa server), just tried connect my Jira to OpenLDAP server.

            Could not add the following missing users to group [ jira-software-users ]: [uid=username23,cn=users,cn=accounts,dc=DOMAIN,dc=com] 

            Do NOT use any OpenLDAP driver, neither even Generic Posix/RFC2307 driver.
            My Jira works fine now only with this driver: Apache Directory Server 1.5.x

            Pavel Bryazgin added a comment - Got same problem with IDM (freeIpa server), just tried connect my Jira to OpenLDAP server. Could not add the following missing users to group [ jira-software-users ]: [uid=username23,cn=users,cn=accounts,dc=DOMAIN,dc=com] Do NOT use any OpenLDAP driver , neither even Generic Posix/RFC2307 driver. My Jira works fine now only with this driver: Apache Directory Server 1.5.x

            As a hint: we have seen the same messages (and lots of them) in our log. In our case they appear since we have set the User Object filter in our Crowd server to exclude a group of users 

            (&(!(cn=<sometext>*))(objectClass=inetOrgPerson))

            These users are not synched into Confluence, JIRA and Bitbucket, but since they are still in the groups we need to sync, this message appears in our logs "pretty often" (we excluded about 10k users...).

             

            Is there a way to suppress this message?

            Benjamin Horst added a comment - As a hint: we have seen the same messages (and lots of them) in our log. In our case they appear since we have set the  User Object filter  in our Crowd server to exclude a group of users  (&(!(cn=<sometext>*))(objectClass=inetOrgPerson)) These users are not synched into Confluence, JIRA and Bitbucket, but since they are still in the groups we need to sync, this message appears in our logs "pretty often" (we excluded about 10k users...).   Is there a way to suppress this message?

            Hello Sorin. Can you please include step-by-step instructions to reproduce this issue, either with JIRA or with Crowd? Please also indicate which LDAP server you're using (is it Active Directory?). Debug logs would be useful, and if possible, please check if the user exists in the cwd_user table.

            Diego Berrueta added a comment - Hello Sorin. Can you please include step-by-step instructions to reproduce this issue, either with JIRA or with Crowd? Please also indicate which LDAP server you're using (is it Active Directory?). Debug logs would be useful, and if possible, please check if the user exists in the cwd_user table.

            Please reopen this issue, I do see this consistently on JIRA 6.4.12 logs, and obviously these are coming from Crowds. I can profile DEBUG logs if you need them.

            Sorin Sbarnea (Citrix) added a comment - Please reopen this issue, I do see this consistently on JIRA 6.4.12 logs, and obviously these are coming from Crowds. I can profile DEBUG logs if you need them.

            There's not enough information for us here to be able to determine what we need to fix; for example, the log snippets here are only at INFO level (rather than DEBUG or TRACE), and the instructions to reproduce this are mostly missing (what kind of user and group structure was present before the rename, was only the username changed as part of the rename, etc).

            Additionally, Crowd 2.7.0 and later have rename detection for LDAP servers (including Active Directory), such that when a user is renamed in a connected LDAP directory then Crowd will recognise this and deal with it appropriately when the cache is next sync'd.

            Because of this, I'm going to mark this issue as Obsolete. If this is still a problem for you after upgrading to the latest version of Crowd, please contact support and they'll be happy to help you out.

            Caspar Krieger (Inactive) added a comment - There's not enough information for us here to be able to determine what we need to fix; for example, the log snippets here are only at INFO level (rather than DEBUG or TRACE), and the instructions to reproduce this are mostly missing (what kind of user and group structure was present before the rename, was only the username changed as part of the rename, etc). Additionally, Crowd 2.7.0 and later have rename detection for LDAP servers (including Active Directory), such that when a user is renamed in a connected LDAP directory then Crowd will recognise this and deal with it appropriately when the cache is next sync'd. Because of this, I'm going to mark this issue as Obsolete. If this is still a problem for you after upgrading to the latest version of Crowd, please contact support and they'll be happy to help you out.

              Unassigned Unassigned
              463fea63753e Joffrey Maar
              Affected customers:
              1 This affects my team
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: