Cannot save changes to User Directories or add new directories
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
When attempting to add, disable, enable, or modify a User Directory, the following error is shown in the browser, and logged to the atlassian-jira.log file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Exception thrown when encrypting: EncryptionParameters{plainTextPassword='<SANITIZED>', algorithm='AES/CBC/PKCS5Padding', algorithmKey='AES', algorithmParametersFilePath='null', keyFilePath='null', outputFilesBasePath='/opt/jira/data/keys/', saveAlgorithmParametersToSeparateFile='false', saveSealedObjectToSeparateFile='false'}
java.lang.RuntimeException: java.io.FileNotFoundException: /opt/jira/data/keys/javax.crypto.spec.SecretKeySpec_<13_DIGIT_NUMBER> (No such file or directory)
at com.atlassian.db.config.password.ciphers.algorithm.serialization.SerializationFile.createFileAndSave(SerializationFile.java:26)
at com.atlassian.db.config.password.ciphers.algorithm.AlgorithmCipher.getKeyOrGenerateNewAndGet(AlgorithmCipher.java:245)
at com.atlassian.db.config.password.ciphers.algorithm.AlgorithmCipher.encrypt(AlgorithmCipher.java:178)
at com.atlassian.db.config.password.ciphers.algorithm.AlgorithmCipher.encrypt(AlgorithmCipher.java:114)
at com.atlassian.crowd.crypto.ClusterAwareCipherWrapper.encrypt(ClusterAwareCipherWrapper.java:48)
at com.atlassian.crowd.crypto.DbConfigPasswordCipherEncryptor.doEncrypt(DbConfigPasswordCipherEncryptor.java:87)
at com.atlassian.crowd.crypto.DbConfigPasswordCipherEncryptor.changeEncryptionKey(DbConfigPasswordCipherEncryptor.java:71)
at com.atlassian.jira.crowd.embedded.encryptors.MissingKeyLoggerEncryptor.changeEncryptionKey(MissingKeyLoggerEncryptor.java:47)
at com.atlassian.crowd.crypto.CachedEncryptor.changeEncryptionKey(CachedEncryptor.java:101)
at com.atlassian.crowd.crypto.SaltingEncryptor.changeEncryptionKey(SaltingEncryptor.java:56)
at com.atlassian.crowd.crypto.MissingKeyHandlingEncryptor.encrypt(MissingKeyHandlingEncryptor.java:24)
at com.atlassian.crowd.crypto.PrefixBasedSwitchableEncryptor.encrypt(PrefixBasedSwitchableEncryptor.java:45)
at com.atlassian.crowd.crypto.ClusterLockingEncryptor.lambda$encrypt$1(ClusterLockingEncryptor.java:27)
at com.atlassian.crowd.lock.ClusterLockWrapper.run(ClusterLockWrapper.java:43)
at com.atlassian.crowd.crypto.ClusterLockingEncryptor.encrypt(ClusterLockingEncryptor.java:27)
at com.atlassian.jira.crowd.embedded.encryptors.JiraEncryptor.encrypt(JiraEncryptor.java:35)
<SNIP>Environment
Jira 8.14.0 or above
An external user directory (LDAP, AD, Crowd) is being used
Cause
As part of the Embedded Crowd and password encryption feature introduced in Jira 8.14.0, credentials for some remote directory servers are stored encrypted at rest in the database. The file listed in the error message is the encryption key used to encrypt and decrypt these directory credentials. Thus, Jira cannot decode the password without this file.
When the keyfile cannot be found, Jira will recreate it automatically and encrypt any new directory passwords entered with the new key. The "keys" directory itself, however, will not be automatically created, and it's absence results in the error noted above. The keys directory is JIRA_HOME/keys if Jira Server, JIRA_SHARED_HOME/keys if Jira Data Center.
The absence of this directory, and by proxy, keyfile can occur in a number of scenario:
Cause 1: The directory and key file were deleted from the file system of the Jira server
Cause 2: This environment was restored from an XML backup from another environment. The key file is not backed up via Jira's XML Backup feature, and therefore will not be present on the file system unless copied manually. This design prevents a stolen database backup from revealing the directory password.
Solution
Ensure that the directory listed in the error message exists (if not, create it) and that the OS level user running Jira has full permissions to it
If a copy of the specific key file listed in the error can be located (for example, from another environment or from a file system backup), copy the key back to the path specified in the error.
If you were not able to restore the specific key file listed in the error, visit ⚙ > User Management > User Directories, Edit the directory, and under the Server settings section, re-enter the password of the directory. (If the directory type is "Crowd", then re-enter the Application Password)
Save and Test your directory and check that authentication succeeds
In certain situations, Jira administrators might need to take a more aggressive means to replace the key file. In these circumstances, where the steps above do not resolve this issue, then you can follow these steps below to resolve this issue.
Access Jira using any means (such as starting Jira in Recovery Mode. )
Navigate to Settings > System
Click on "Advanced Settings"
Scroll down to the setting
crowd.encryption.encryptor.defaultChange the value for: crowd.encryption.encryptor.default to "DISABLED"
As a result, the password for the external directory will be disabled and can be updated. It's strongly recommended to re-enable this feature after recovery so that the password is re-encrypted with a new key file.
Was this helpful?