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

LDAP users from delegated directory cannot change their information though JIRA UI

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Won't Do
    • None
    • None
    • JIRA 4.4.4, Postgres 9.0, OpenLDAP
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      When creating a "Internal with LDAP authentication" directory in JIRA, we have the message:

      Configure Internal with LDAP Authentication User Directory

      JIRA can use LDAP for user authentication only. To be able to log in to JIRA with this configuration, users must either be created first in JIRA, or the option 'Copy User on First Login' can be checked to automatically add them to JIRA's internal directory. Copied users can subsequently be modified in Confluence, but modifications will not be reflected on the LDAP server.

      Groups and memberships from the LDAP server will not be used. However, users from LDAP can be added to groups maintained in JIRA's internal directory.

      Let's say the user's info is the following:

      • uid=testuser
      • mail=testuser@ldapemail.com

      If we try to change an attribute for one of the users in this delegated directory, for example, the email address (changing from testuser@ldapemail.com to testuser@jiraemail.com), next time the users logs in JIRA, the email address is set to the testuser@ldapemail.com.

      This behaviour also can be observed by editing the user's Full Name.

            [JRASERVER-27223] LDAP users from delegated directory cannot change their information though JIRA UI

            Kerrod Williams (Inactive) added a comment -

            Thanks for taking the time to raise this issue.

            Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts. In part, that means concentrating on those issues that resonate the most with our users.

            I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue.

            Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me.
            Kind Regards,
            Kerrod Williams
            JIRA Product Management
            kerrod.williams at atlassian dot com

            Kerrod Williams (Inactive) added a comment - Thanks for taking the time to raise this issue. Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts . In part, that means concentrating on those issues that resonate the most with our users. I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue. Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me. Kind Regards, Kerrod Williams JIRA Product Management kerrod.williams at atlassian dot com

            Christian Schulz added a comment -

            We do need the other way around. Such information should not be editable.
            In my opinion it makes sense to create for this a new permission.

            Christian Schulz added a comment - We do need the other way around. Such information should not be editable. In my opinion it makes sense to create for this a new permission.

            Pawel Wysocki added a comment -

            Any chance to get it fixed in 6.0?

            Cheers
            Pawel

            Pawel Wysocki added a comment - Any chance to get it fixed in 6.0? Cheers Pawel

            Matt Vanchura added a comment - - edited

            This is also a deviation from how JIRA previously worked prior to the new Directory Admin UI addition (I guess in 4.3?).

            For instance in JIRA 3.13, you could have multiple LDAP providers in the authentication chain but regardless of which one successfully matched and authenticated against, the JIRA internal account information was unaffected and unchanged.

            It is nice that this LDAP information is used to intially populate the JIRA directory account if the JIRA account does not already exist when the "Copy User on First Login" is selected.

            It would be also nice if the current behavior was configurable per user or if in a specified "Internal" JIRA group as sometimes this is actually desirable.

            Maybe something like either a Per user property:

            Allow One-way Synchronization of JIRA account profile info from LDAP provider? Yes / NO

            or something like an option for the Advanced Directory Configuration:

            Specify JIRA Group for LDAP One-way JIRA account profile information synchronization

            Then any users in that group would not be able to modify their JIRA profile information, but would have it synchronized with whatever LDAP authenticator authenticated them.

            Users not in that group would not have synchronization and LDAP would be used for authentication only.

            Administrators would then have the option of making this one of the default JIRA groups new users are placed in if the "Copy User on First Login" is selected.

            Matt Vanchura added a comment - - edited This is also a deviation from how JIRA previously worked prior to the new Directory Admin UI addition (I guess in 4.3?). For instance in JIRA 3.13, you could have multiple LDAP providers in the authentication chain but regardless of which one successfully matched and authenticated against, the JIRA internal account information was unaffected and unchanged. It is nice that this LDAP information is used to intially populate the JIRA directory account if the JIRA account does not already exist when the "Copy User on First Login" is selected. It would be also nice if the current behavior was configurable per user or if in a specified "Internal" JIRA group as sometimes this is actually desirable. Maybe something like either a Per user property: Allow One-way Synchronization of JIRA account profile info from LDAP provider? Yes / NO or something like an option for the Advanced Directory Configuration: Specify JIRA Group for LDAP One-way JIRA account profile information synchronization Then any users in that group would not be able to modify their JIRA profile information, but would have it synchronized with whatever LDAP authenticator authenticated them. Users not in that group would not have synchronization and LDAP would be used for authentication only. Administrators would then have the option of making this one of the default JIRA groups new users are placed in if the "Copy User on First Login" is selected.

              Unassigned Unassigned
              cgauterio Clarissa Gauterio (Inactive)
              Votes:
              4 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: