Token Timed Out when Resetting Password via Email
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Symptoms
Attempting to reset the password via email will send an email with a token attached. This token will be authenticated against Jira, and if it is successful, one can proceed to resetting his/her password.
However, one may run into a message where the following is shown in the Jira instance upon click on the link in the email:
1
The reset password token you have provided has timed out.The following may also appear in the atlassian-jira.log after logging in:
1
TP-Processor7 ERROR anonymous 957x23725x1 1v59ct1 127.0.0.1 /rest/gadget/1.0/login[jira.security.login.LoginStoreImpl] com.atlassian.crowd.exception.OperationNotPermittedException: com.atlassian.crowd.exception.ApplicationPermissionException: Not allowed to update user attributes 'jalex' in directory 'JIRA Internal Directory'.Diagnosis
This happens when a Crowd instance (that was previously integrated with the JIRA instance) has been removed.
The following SQL query would return unexpected set of results:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
~$: select attribute_name from cwd_user_attributes;
attribute_name
-----------------------------
invalidPasswordAttempts
requiresPasswordChange
lastAuthenticated
invalidPasswordAttempts
requiresPasswordChange
lastAuthenticated
passwordLastChanged
requiresPasswordChange
invalidPasswordAttempts
passwordLastChanged
invalidPasswordAttempts
requiresPasswordChange
lastAuthenticated
passwordLastChanged
invalidPasswordAttempts
requiresPasswordChange
lastAuthenticated
invalidPasswordAttempts
requiresPasswordChange
lastAuthenticated
...From the resultset, it can be seen that the following properties are missing:
login.lastFailedLoginMillislogin.currentFailedCountlogin.lastLoginMillislogin.previousLoginMillislogin.count
Also, the following has been set in the JIRA instance:
Option | Status |
|---|---|
User Directory | Set to JIRA Internal Directory, and is in the top position. |
External User Management | Disabled. |
User and Group Memberships | Has been mapped to the JIRA Internal Directory. |
Cause
The most probable cause of this is when the Crowd instance has been removed from the JIRA instance, some of the database entries may not be inputted to cater for full JIRA internal directory management. This includes the ability to update users, groups and roles:
1
2
3
4
5
6
7
8
9
10
11
12
13
~$: select * from cwd_directory_operation;
directory_id | operation_type
--------------+------------------------
1 | UPDATE_GROUP
1 | DELETE_GROUP
1 | CREATE_ROLE
1 | DELETE_ROLE
1 | CREATE_USER
1 | UPDATE_USER
1 | DELETE_USER
1 | UPDATE_ROLE
1 | CREATE_GROUP
(9 rows)Solution
Resolution
The following can be applied in the database to ensure that any users in the JIRA internal directory can perform certain user management tasks. Remember to backup the database before performing the following steps.
Access the database via command line.
Execute the following query:
1select * from cwd_directory_operation;If the following does not exist from the results above, it needs to be included:
UPDATE_USER_ATTRIBUTEUPDATE_GROUP_ATTRIBUTEUPDATE_ROLE_ATTRIBUTE
Execute the next SQL query and restart JIRA:
1 2 3insert into cwd_directory_operation values (1,'UPDATE_USER_ATTRIBUTE'); insert into cwd_directory_operation values (1,'UPDATE_GROUP_ATTRIBUTE'); insert into cwd_directory_operation values (1,'UPDATE_ROLE_ATTRIBUTE');
Was this helpful?