Question about *_PASSWORD = CREATE_RANDOM_PASSWORD in the define.tem file for IFS Cloud

This is an interesting set of questions.  I used to work with the IFS group which handled middleware installations for my region of the world.  So I thought I’d do some research to see if I could find the answers needed here.  I checked with my contacts who still work with mws installations to help with that research.

I’ll post responses to each of the questions in italics:

Is the password generated by CREATE_RANDOM_PASSWORD stored anywhere?
If yes, where can I find it?  These user passwords, performed for the users named further below, are only stored in the usual manner in the Oracle database (encrypted of course).  I dug through the code of an IFS Cloud build and found that the installation scripts will default to use an Oracle utility package to generate a random password for the internal users (CAMUNDA_APPOWNER, IAM_APPOWNER, etc,) if no other password values are provided by the engineer at the time of the installation.  Note that every installation I’ve been associated with in the past allowed the installing engineer to manually specify passwords for these internal users. This is by far the most commonly used method for password generation.

Is it possible to view the generated password in plain text after deployment?  The randomly generated password is NOT displayed in the logs at the time of the user’s creation. Instead, if the installer scripts were to reach the point of random password generation, the logs will show the text string “<hidden>” (without quotes) instead of the text of the user password(s).

If not, what is the supported way to reset it?  Most of these internal users’ passwords may be reset in the usual manner, i.e. via an Oracle editor session (SQL Developer, SQL Plus, or other tools).  But the appowner (usually IFSAPP) should be updated in the way described in the IFS technical documentation. 

Is there any official documentation that explains this behavior?  I couldn’t find any documentation on this specific topic.  So I had to resort to stepping through the code of an IFS Cloud build.

…the public documentation for define.tem looks a bit different from the actual define.tem file in our environment.
For example, our file includes variables like CAMUNDA_APPOWNER, IAM_APPOWNER, DBADMPROXY_OWNER, and RAISE_NEW_CUSTOM_OBJ_INVALIDS.  I haven’t found any documentation regarding these internal users.  CAMUNDA_APPOWNER is a recently added internal user which deals with administering workflows. 

Some of the other internal users are defined briefly here - https://docs.ifs.com/techdocs/26r1/030_administration/011_users/?h=user

I don’t have an answer to why the others aren’t defined – though their respective names are descriptive of their individual purposes.

​@Eugene Wager Great answer!

Just to add to this:

• With 26R2 the “Special Oracle Users in IFS Cloud” section in the Tech Doc is already updated to contain the full list of Oracle users. As part of this update we have also gotten rid of some old, now obsolete, oracle users that were still unnecessarily being created.
• We have added a task to our backlog to update the define.tem documentation to both, cover all the missing properties that have been added as well as to provide some more details on the parameters and features like CREATE_RANDOM_PASSWORD. No timeline yet when this will be updated though.