I am using the Services Standard Build (SSB) for IdentityIQ. After performing a ./build.sh clean and a new deployment, I am facing a java.lang.IllegalStateException: Authentication Failed error when trying to log in or run console commands.
What happened:
The iiq.dat and iiq.cfg files were deleted during the clean process, and the build generated new ones. Now, the encryption keys in the new keystore do not match the encrypted passwords already stored in the database (e.g., spadmin).
Environment:
IdentityIQ Version: 8.4 / 8.5
Build Tool: SSB
Database: MySQL
Question:
Besides restoring a backup of the original iiq.dat or resetting the database (drop/create/import-stock), is there a standard SSB practice to externalize these files so they aren’t lost during a build clean? How can I re-synchronize the database with a new key if the original is lost?
@cleber_pcarv You can move your dat and cfg files from default path to a different location, they your SSB will not be able to modify these. SSB can only make changes if they are in default location.
Additionaly, if you introduce a new keystore, then you can run the task: “Encrypted Data Synchronization Task” to reencrypt all the encrypted data.
Note: Help the community by marking successful fixes as solutions. Feel free to react(, , etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
@cleber_pcarvYou should never let iiq.dat be regenerated in non-dev environments. Best Practice is to externalize config files.
Create a persistent config directory, for example: /opt/sailpoint/iiq-config/
Move these files there:
iiq.cfg
iiq.dat
keystore.jceks (if used)
Update your SSB / startup configuration to point to it:
In build.propertiesiiq.config.dir=/opt/sailpoint/iiq-config
Or via JVM option (Tomcat / WebLogic): -Diiq.config.dir=/opt/sailpoint/iiq-config
SSB will:
Read from this location
Not delete it during build.sh clean
Can the database be re-synchronized with a new encryption key? - No, If the original iiq.dat is lost, encrypted data in the database cannot be recovered.