Service Desk customers created as Jira internal users can't update their password.

[Meta System S.p.A.]

JIRA Service Desk 3.16.1 + Jira Software 7.13.1

User Directories: Jira Internal Directory at the top + second in the list Microsoft Active Directory as read only

I created internal users for customers of a Service Desk project having these configurations 

• Who can raise requests? Customers who are added to the project
  
• Who can customers share requests with? Any customer or organization, by searching in this project

These customers do not have a Service Desk license assigned.

I would like them to be able to update their password, but whe they try do update their own profile they get the message 

"you cannot edit your name, password or e-mail because they are stored in a read-only user directory".

How can I set up Jira internal directory as Read&Write?

Directory Configuration as follows:

Directory ID: 1
Name: Jira Internal Directory
Active: true
Type: INTERNAL
Created date: Thu Feb 28 11:57:51 CET 2013
Updated date: Thu Feb 28 11:57:51 CET 2013
Allowed operations: [CREATE_GROUP, CREATE_ROLE, CREATE_USER, DELETE_GROUP, DELETE_ROLE, DELETE_USER, UPDATE_GROUP, UPDATE_GROUP_ATTRIBUTE, UPDATE_ROLE, UPDATE_ROLE_ATTRIBUTE, UPDATE_USER, UPDATE_USER_ATTRIBUTE]
Implementation class: com.atlassian.crowd.directory.InternalDirectory
Encryption type: atlassian-security
Attributes: "user_encryption_method": "atlassian-security"

Any suggestion is welcome!

[Meta System S.p.A. · Accepted solution]

OK, just to summarize: if both Jira Internal Directory and External authentication (like Active Directory in our case) are configured as user directories in Jira, despite the fact that Jira Internal Directory is at the top of the User Directories list, locally created users can't change their password or take advantage of the  forgot password link visible on the login screen.

This happens when in cog | System | General Settings | Edit settings | External user management is ON. 

Set it to OFF to unlock the password change feature

Don't worry about users in your External LDAP Directory, as long as you configure it as Read Only or Read only with local groups they won't be allowed to change their AD password via Jira application.

Hope this can save time to other Jira admins.

[Andy Heinzer]

Thanks for the great summary!  I'm sure it will help others that run across this.

[Andy Heinzer]

Hi,

I understand that you have both the Jira Internal user directory and another Active Directory in Jira, and that you want to allow your Service Desk customer users to be able to change their password in Jira.

That specific error message you see there happens when the user account exists in a read only directory.  While Jira allows you to have multiple user directories, and each of those directories could potentially have the exact same user names in them, Jira will only let individual users login using the credentials that exist in the top ordered directory within Jira.  This is noted in Managing multiple directories.

That said, I see you have the internal directory on top.   The only way you would see that specific "you cannot edit your name, password, ..." message is if that specific user only exists in the external user directory and not in the Jira internal directory. OR if that user logged into Jira when the other directory was on top, and while they are still logged in, a Jira admin re-orders the directories.  The Jira internal user directory is always in a read/write state, unless the internal directory has been disabled entirely.

We can try to confirm this likely cause by looking at the userbrowser in Jira, Cog -> User Management -> Users or the URL /secure/admin/user/UserBrowser.jspa   On this page search for the username in question.  If the user account exists in both AD and the Internal directory, the search results should show us that user name exists twice in Jira, and indicates the user directory.   It could also be something we can lookup via SQL if need be, but this method seems to be the easiest way to confirm if this is the problem here.  You should see results like this:

As for ways to correct this, well it might just be as simple as creating that user account in the Internal directory.  From there the user would need to know what their credentials where in Jira, but they could then change them as needed once they can login.   Alternatively, you could change the User directory settings within Jira to switch the directory from Read-only to Read/Write.  Just understand that this setting then allows all user account changes made in Jira for those accounts to write them back to the Active Directory itself.

Please let me know if you have any questions about this.

Andy

[Meta System S.p.A.]

Jira internal directory has always been on top, when user was created as well as when he logged in.

There is only one user entry for this specific user, never created in Active Directory but only in Jira ID.

The point is: if Service Desk customers don't own the SD license but they have been created as internal users in order to narrow the customer portal access, are they anyway allowed to change their password?

Pre-requisites are: Active Directory can't be R/W, customers can't have a SD license assigned, Customer Portal access has to be limited as much as possible.

Thank you for your help

[Andy Heinzer]

Thanks for the more details here.  

In this setup, the end user can change their password for Jira, if Jira is configured to use an outgoing SMTP mail server.  With this setup, all users, even Service Desk Customers that can only access the customer portal, do at least have the ability to access the "Forgot Password" function in Jira.

• For Internal Jira users, they can reset their passwords using this "Forgot Password" function.
• For users in Read only directories, like LDAP or AD, they cannot reset their passwords using the "Forgot Password" function in Jira, but it still might appear to them as an option.  They tend to get an error when trying to change the password this way.

In cases like this were Jira only has this single account in the Internal, and does not display the account as coming from another directory, there is no method possible for Jira to change that user's credentials in LDAP.   Only if you were using the Read/Write directory option would Jira have the potential to be able to change the password for an account in LDAP.

I hope this helps to explain the behavior here.  Please let me know if you have any additional concerns here.

Regards,

Andy

[Meta System S.p.A.]

Ok, got it.

I was trying to use the wrong feature (edit user profile -> change password, supposed it was possible for internal users), I will test forgot password link instead.

Thank you

[Meta System S.p.A.]

Hello Mr Heinzer,

I tried the forgot password link as you suggested, but then my SD customer created as Jira Internal User gets the answer "This instance does not support password reset. Please contact the system administrator."

Then I read something about this here : https://jira.atlassian.com/browse/JSDSERVER-4116  and it describe exactly my issue, although it seems to date back from 2016.

Anyhow, in the end, I still haven't found neither a solution to my problem or my mistake...

Any further suggestion? Thank you

[Andy Heinzer]

I created a support case to dig deeper into this problem in https://getsupport.atlassian.com/servicedesk/customer/portal/3/SDS-45404

However right after I did this, I considered a possibility that might explain this behavior.   As a Jira admin, could you please navigate to the Cog Icon -> System -> General Configuration, then Edit these settings.  Scroll down to the 'External user management'   What value do you have here?

By default this setting is off in Jira.  However if you have turned this ON, then Jira does not have an expectation to manage users internally.   More details on this setting can be found in Configuring Jira application options.

In your situation, I would expect this to be OFF as long as you have at least 1 internal user.   If this is not the solution here, then perhaps it would be better for us to gather some more logs and investigate this problem that way in the support case.

Regards,

Andy

[Meta System S.p.A.]

Actually the 'External user management' is ON. In fact we do manage Internal Users (for instance our partners or suppliers who don't have an account in our Active Directory are locally created as Internal Users and they have a Jira Software license assigned).

The matter is about Service Desk Curtomers: I do expect some features to be available for Cutomers as well, whithout having to assign a Service Desk License.

Might be this point the misunderstanding?

[Andy Heinzer]

Yes.  I think this External user management feature setting in Jira is commonly misunderstood as well.  When that feature is ON, Jira is not expecting to be able to manage user accounts in the Internal user directory.  But when it is OFF, it can do so.  

In your scenario, you have some users in the LDAP user directory and some other users in the Internal user directory.  You need to keep this setting OFF, so that Jira can continue to manage those internal user accounts.  LDAP users can still login to Jira, even when that setting is in the OFF position.  The only time this setting should be ON, is when all your Jira user accounts are in external user directory.  Try turning this OFF, then scroll to the bottom of the page and update the settings.  Then see if that service desk users can edit their profile.   I fear that with this setting ON, the Jira internal user directory is acting like a read-only directory that end users can't make changes to.

As for service desk user accounts features, the unlicensed users in the customer role do not need a license seat.  They will only have access to the customer portal, but even there they should be able to update their profile details and change their password if their account is in a user directory that permits that action.

Please let me know the results.

Andy

[Meta System S.p.A.]

Hi Andy, thank you so much.

It seems you hit the target. Changing the "External user management" solved the problem.

[Andy Heinzer]

Great, glad to hear this is resolved.  You can accept this answer if it helped solve the problem, or even post a new, more concise answer if you like and we can accept that one.   Perhaps this way other users that come across this same configuration issue will be able to learn from our past troubleshooting here.

Cheers,

Andy