There is a strange behavior of OIM 11.1.2.3, which appears to still be present in 12c, that causes unexpected password changes on accounts. Specifically, all encrypted fields on a parent UD table are set to NULL on access policy evaluation, which triggers any Password Updated-type provisioning actions. These will typically fail, resulting in an open task, because applications typically will not accept a blank password.

The conditions of this strange behavior are:

• You have an application type defined in OIM that has more than one Password field, or
• You have a single Password-type field but it is (a) called something other than Password and (b) not flagged with the AccountPassword property.

In either of those conditions, when an access policy is evaluated that results in no parent UD table changes for a particular account, OIM will blank all Password-type fields.

You can work around this by satisfying either of the conditions above:

• Rename your single password field to PASSWORD – i.e. the database column must be UD_WHATEVER_PASSWORD, or
• Set the AccountPassword property to true on your single password field.

If you have multiple encrypted fields, OIM will choose the first one that matches the above criteria, subject to the whims of database query ordering, and blank out the rest.