IDMProv doesn't start - Page not found 404
When i try to make configupdate.sh -
I can't make User Application driver configuration properly
IDM version 4.9 on SLES
Cybersecurity
DevOps Cloud
IT Operations Cloud
IDMProv doesn't start - Page not found 404
When i try to make configupdate.sh -
I can't make User Application driver configuration properly
IDM version 4.9 on SLES
Obviously from the error message it is not happy with the Java keystores. Well PKC12 format keystores not JKS specifically.
My first thought was, are these carried over from before an upgrade?
I wonder if the Java 8 vs Java 11 keytool has compatabiity issues?
I would try something like this:
/opt/netiq/common/jre/bin/keytool -keystore /opt/netiq/common/jre/lib/security/cacerts -storepass default -list -v | less
See how that should show 100+ public keys.
Then check each other cert store which should be someting like:
/opt/netiq/idm/apps/osp/osp.jks (does not usually have a default keystore password)
/opt/netiq/idm/apps/tomcat/conf/tomcat.ks (password should be in the server.xml file)
/opt/netiq/idm/apps/tomcat/conf/idmapps.jks (Though they may have renamed this one in 4.9).
See which one is broken and recreate it.
Actually thinking about it more, it is likely the idmapps.jks because the key it is probably trying to write is the NMAS SAML key,
Forlammy the password is incorect. But I used the one which has been used in installation/configuration process and doesnt work
I checked many and is wrong
If the password in configupdate is incorrect, you will fail to update as well. But you should either track down the proper passwords or may have to recreate them. Good news is that it is not very hard.
tomcat.ks needs private key for front end Tomcat web page.
osp.jks needs public key tomcat key, ldap tree key, and private key for osp.
idmapp.jks needs LDAP tree's public key, OSP public key, Tomcat public Key
The error is mentioning: "Error loading master encryption keys", encription keys are in /opt/netiq/idm/apps/tomcat/conf/tomcat.ks password for it is the common password (if common password was used, it is also the same as the one of the default uaadmin user).
You might want to also check idm.jks keystore as that password changed from "changeit" in the older version of IDM to common password in 487 onwards
So if you have upgraded to newer version you might need to change keystore password.