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

Crowd doesn't create new users automatically in other directories when he first login, but after sometime

XMLWordPrintable

      When a user first authenticates against

      {JIRA, FECRU, Confuence or Bamboo}

      , the user's credential are correctly validated and the user is automatically added to the local Crowd cache for that directory.

      However, the other Atlassian servers do not have the new user's credential in their local user directory information. Hence, the user login fails on JIRA, etc. and the user is given a system error message.

      The problem is self corrected within an hour typically as the other Atlassian servers synchronize their user directories and pick up any incremental user and group information since the last sync.

      This should be done automatically when a new user is added to the local Crowd cache for all applications which are using Crowd authentication.

            [CWD-2650] Crowd doesn't create new users automatically in other directories when he first login, but after sometime

            Lukasz Pater added a comment -

            CONF-23957 should be visible once again.

            Lukasz Pater added a comment - CONF-23957 should be visible once again.

            Ralf Martin added a comment -

            Me too: seems to be an "internal" permission

            Ralf Martin added a comment - Me too: seems to be an "internal" permission

            Michael Alphonso added a comment -

            @Lukasz Pater - I'm unable to view: CONF-23957

            Michael Alphonso added a comment - @Lukasz Pater - I'm unable to view: CONF-23957

            Lukasz Pater added a comment -

            Hi all.

            We've identified two bugs that might be causing this behaviour:

            • during authentication when the user is missing, we should create the user, and add him to all the groups that he or she belongs to in the remote directory. However if the user belonged to a group that didn't exist in the local cache yet, the group membership was not copied over, until the next synchronisation
            • when using SSO through the Crowd SSO connector (JIRA/Confluence) a missing user wasn't copied at all

            Going through the comments and support cases related to this issue, most seem to be related to the latter.

            Both of these will be fixed in Crowd 2.10. However to actually see the problem fixed in products (notably JIRA/Confluence, which were suffering from the latter issue) they'll need to integrate the updated Crowd libraries. Please watch the related issues JRA-60747 and CONF-23957 for the exact versions that will include those.

            Lukasz Pater added a comment - Hi all. We've identified two bugs that might be causing this behaviour: during authentication when the user is missing, we should create the user, and add him to all the groups that he or she belongs to in the remote directory. However if the user belonged to a group that didn't exist in the local cache yet, the group membership was not copied over, until the next synchronisation when using SSO through the Crowd SSO connector (JIRA/Confluence) a missing user wasn't copied at all Going through the comments and support cases related to this issue, most seem to be related to the latter. Both of these will be fixed in Crowd 2.10. However to actually see the problem fixed in products (notably JIRA/Confluence, which were suffering from the latter issue) they'll need to integrate the updated Crowd libraries. Please watch the related issues JRA-60747 and CONF-23957 for the exact versions that will include those.

            Ralf Martin added a comment -

            Just to clearify things:
            This cannot be corrected in Crowd directly. The problem is at the (crowd = sso) seraph authenticators of each application. So Atlassian has to fix at least the ones for JIRA and Confluence. As far as I remember Bitbucket Server doesn't have the problem. I don't remember for Bamboo.

            What to to:
            The seraph-authenticator has to store the user in local cache of the app (JIRA, Confluence, ...) after he succesfully authenticated against crowd. That's all and shouldn't be too hard to fix!

            Ralf Martin added a comment - Just to clearify things: This cannot be corrected in Crowd directly. The problem is at the (crowd = sso) seraph authenticators of each application. So Atlassian has to fix at least the ones for JIRA and Confluence. As far as I remember Bitbucket Server doesn't have the problem. I don't remember for Bamboo. What to to: The seraph-authenticator has to store the user in local cache of the app (JIRA, Confluence, ...) after he succesfully authenticated against crowd. That's all and shouldn't be too hard to fix!

            Tim Eddelbüttel added a comment -

            The problem is self corrected within an hour typically

            Thats, right but in a service desk environment (with Crowd + LDAP) this is a bad behavior and needs to be fixed.

            Example:
            A customer (e.g. a new employee who needs something to start his work on the first day) is going to report an issue trough service desk and get's another issue because he is not in jira-service-desk-users. When this issue is solved (forced sync or self corrected), maybe by email because he can't login into JIRA and report his issue
            But only if he knows who is the JIRA Administrator or who can help.

            Regards,
            Tim

            Tim Eddelbüttel added a comment - The problem is self corrected within an hour typically Thats, right but in a service desk environment (with Crowd + LDAP) this is a bad behavior and needs to be fixed. Example: A customer (e.g. a new employee who needs something to start his work on the first day) is going to report an issue trough service desk and get's another issue because he is not in jira-service-desk-users. When this issue is solved (forced sync or self corrected), maybe by email because he can't login into JIRA and report his issue But only if he knows who is the JIRA Administrator or who can help. Regards, Tim

            Derek Sheeman added a comment -

            My Crowd license renewal is coming up soon, and we are considering other options. Since this issue is a really ugly pain point and constantly causes problems for new users. Really it is something that should have been fixed a long long time ago. Such a basic piece of functionality being broken should be a major embarrassment for the Crowd application team.

            What is the point of a user database system that causes more problems than it solves?

            Derek Sheeman added a comment - My Crowd license renewal is coming up soon, and we are considering other options. Since this issue is a really ugly pain point and constantly causes problems for new users. Really it is something that should have been fixed a long long time ago. Such a basic piece of functionality being broken should be a major embarrassment for the Crowd application team. What is the point of a user database system that causes more problems than it solves?

            Kutsal Berberoglu added a comment -

            3 years 1 month and 18 days since this was opened. @Atlassian, any chance for a fix at some point?

            @Ralf Martin, would you care to elaborate on your fix so we can try it here at Domino's? I've encountered this (and CONF-23957 which is related) while building our new DevOps infrastructure.

            Kutsal Berberoglu added a comment - 3 years 1 month and 18 days since this was opened. @Atlassian, any chance for a fix at some point? @Ralf Martin, would you care to elaborate on your fix so we can try it here at Domino's? I've encountered this (and CONF-23957 which is related) while building our new DevOps infrastructure.

            Caspar Krieger (Inactive) added a comment -

            Thanks spocksbeard - our Crowd workflow is perhaps a little more open than it should be, but generally it hasn't been a problem. Anyway, I've reverted the issue to the correct state of Verified.

            Caspar Krieger (Inactive) added a comment - Thanks spocksbeard - our Crowd workflow is perhaps a little more open than it should be, but generally it hasn't been a problem. Anyway, I've reverted the issue to the correct state of Verified.

            Ralf Martin added a comment -

            Hey Atlassian - what about your workflow - anonymous can start progress???

            Btw - we fixed that here at Volkswagen at our laboratory. @Atlassian get in contact with us if you're interested in details...

            Ralf Martin added a comment - Hey Atlassian - what about your workflow - anonymous can start progress??? Btw - we fixed that here at Volkswagen at our laboratory. @Atlassian get in contact with us if you're interested in details...

              lpater Lukasz Pater
              rgadami Rodrigo Girardi Adami
              Affected customers:
              36 This affects my team
              Watchers:
              39 Start watching this issue

                Created:
                Updated:
                Resolved: