At first some theory.
A standalone BPM environment (7.5-8.0) uses a database-base internal repository (DBR) for storing of accounts by default. If your database is down you cannot enter into BPM.
A clustered BPM environment does not use DBR by default, it uses WebSphere file-based user repository (FBR). A standalone environment contains FBR too, but it is not active.
I had this problem when I started to use Oracle DB as BPM database. Default user profile in Oracle has two settings: a password will be expired after 120 days and the user account will be locked 7 days after password expiration. So, if you use Oracle you must change these setting to UNLIMITED at once.
But others databases have analogical problems too.
What do do in these case:
1. The simpliest way, but it does not work anytime. Unlock your locking user if it is possible.
2. The best way, I think. BPM like and WAS uses Authentication aliases (AA) for storing and using of accounts. For example, a datasource uses AA for connectiong to database. The information about aliases (name, login, password) is being stored in the file security.xml in your BPM profile.
For connecting to BPMDB, for example:
<authDataEntries xmi:id="JAASAuthData_1347447212255" alias="processdblogon" userId="db2admin" password="{xor}Dz4sLCgwLTtubWw=" description="Process Server authentication alias"/>
<authDataEntries xmi:id="JAASAuthData_1347447212271" alias="processdblogon_XAR" userId="db2admin" password="{xor}Dz4sLCgwLTtubWw=" description="Process Server authentication alias for XA recovery"/>
The way for encrypting/decrypting of passwords in this file is clear. You can read this:
http://bpmadmin.blogspot.ru/2012/12/how-to-restore-was-bpm-administration.html
As a result, do the next steps:
Unlock your user with a new password, encrypt the password and change the passwords in the security.xml. Also, one more file exists - 98Database.xml (it is the artefact from Lombardi version).
You have to encrypt the password in this file by the other way:
Navigate to the [Lombardi_home]/twinit/lib directory and then run the following command:
java -cp utility.jar com.lombardisoftware.utility.EncryptPassword <password>
where <password> is the password you want to encrypt.
After your server starts, you will be able to enter, if you did all correctly.
3. The radical way. You can refused of DBR and use FBR on standalone.
For this:
Disable WAS security
http://bpmadmin.blogspot.ru/2013/03/how-to-disable-was-security-quickly.html
start your server,
and do:
http://bpmadmin.blogspot.ru/2013/03/how-to-disable-bpms-internal-repository.html
After that you will forget about the issues like this one.
But don't forget about backups!
A standalone BPM environment (7.5-8.0) uses a database-base internal repository (DBR) for storing of accounts by default. If your database is down you cannot enter into BPM.
A clustered BPM environment does not use DBR by default, it uses WebSphere file-based user repository (FBR). A standalone environment contains FBR too, but it is not active.
I had this problem when I started to use Oracle DB as BPM database. Default user profile in Oracle has two settings: a password will be expired after 120 days and the user account will be locked 7 days after password expiration. So, if you use Oracle you must change these setting to UNLIMITED at once.
But others databases have analogical problems too.
What do do in these case:
1. The simpliest way, but it does not work anytime. Unlock your locking user if it is possible.
2. The best way, I think. BPM like and WAS uses Authentication aliases (AA) for storing and using of accounts. For example, a datasource uses AA for connectiong to database. The information about aliases (name, login, password) is being stored in the file security.xml in your BPM profile.
For connecting to BPMDB, for example:
<authDataEntries xmi:id="JAASAuthData_1347447212255" alias="processdblogon" userId="db2admin" password="{xor}Dz4sLCgwLTtubWw=" description="Process Server authentication alias"/>
<authDataEntries xmi:id="JAASAuthData_1347447212271" alias="processdblogon_XAR" userId="db2admin" password="{xor}Dz4sLCgwLTtubWw=" description="Process Server authentication alias for XA recovery"/>
The way for encrypting/decrypting of passwords in this file is clear. You can read this:
http://bpmadmin.blogspot.ru/2012/12/how-to-restore-was-bpm-administration.html
As a result, do the next steps:
Unlock your user with a new password, encrypt the password and change the passwords in the security.xml. Also, one more file exists - 98Database.xml (it is the artefact from Lombardi version).
You have to encrypt the password in this file by the other way:
Navigate to the [Lombardi_home]/twinit/lib directory and then run the following command:
java -cp utility.jar com.lombardisoftware.utility.EncryptPassword <password>
where <password> is the password you want to encrypt.
After your server starts, you will be able to enter, if you did all correctly.
3. The radical way. You can refused of DBR and use FBR on standalone.
For this:
Disable WAS security
http://bpmadmin.blogspot.ru/2013/03/how-to-disable-was-security-quickly.html
start your server,
and do:
http://bpmadmin.blogspot.ru/2013/03/how-to-disable-bpms-internal-repository.html
After that you will forget about the issues like this one.
But don't forget about backups!
No comments:
Post a Comment