Problem With Live Migration Of LDOM Under OpsCenter 12C U1 user fails for password creation

On : 10 8/11 U10 version, Ops Center

Problem with Live Migration of LDOM under OpsCenter 12C U1

During the Live Migration of the LDOMs under OpsCenter, it creates an user on the target server "xvmCxxxx" and set a random password. Error message is generated when this user account is created and password is assigned, why ?.

The policy of password creation for our Server is as follows:

MAXWEEKS=12
MINWEEKS=1
PASSLENGTH=6
WARNWEEKS=2
DICTIONLIST=/usr/share/lib/dict/words
MINUPPER=1
MINLOWER=1
MINDIGIT=1
MINSPECIAL=1
NAMECHECK=YES
HISTORY=10

SOLUTION

There is a CR, which is listed as fixed in the 12c initial release. The fix added a value to the XVM.properties file located
in the /opt/sun/n1gc/lib/ directory. Lines 49-53 describe the random-string-prefix value that is defaulting to "two letters and a digit"
for the random generated password.

From CR engineer:

We compute randomly a password for a temporary account that will last for the time of the migration.
To ensure the random password will satisfy the policy you can define a prefix meeting the policy and the rest of the characters will be randomly computed.
To modify the default prefix, you need to edit on each ldom control domain the file /opt/sun/n1gc/lib/XVM.properties,
and modify the property com.sun.hss.domain.internal.serialconsole.random-string-prefix.
If your policy require at least one upper case letter, one lower case letter, one digit, and one special character, you could for example use this value:

  com.sun.hss.domain.internal.serialconsole.random-string-prefix=Xv2!

This Prefix is making sure the proper upper,lower, and special characters are assigned and the digit is taken care of by the random number generator.

Given the config file you show, the password needs to meet the following criteria:

  DICTIONLIST=/usr/share/lib/dict/words
  MINUPPER=1
  MINLOWER=1
  MINDIGIT=1
  MINSPECIAL=1

So a prefix like "Aa#" would be sufficient to generate a password like "Aa#36000"

Then for the value to be taken into account, you need to restart the cacao scn-agent instance on each control domain where you have modified the value.

$ cacaoadm stop -i scn-agent
$ cacaoadm start -i scn-agent