Strange post-provisioning behavior in IIQ wipes out Identity attributes

IdentityIQ (IIQ) IIQ Community Knowledge Base
1

NOTE: This bug has been reported to SailPoint and will be fixed in some future version of the system. The tracking ID is IIQETN-11720.

Problem

At a customer install of IIQ, we were seeing odd behavior during where a newly created Identity was having its Identity attributes wiped or blanked out post-provisioning.

We have seen this behavior in 8.2 and now 8.4p1, but this is the first time we’ve been able to trace it to a source. The sequence of events looked as follows:

  1. An account was retrieved from an authoritative source system.
  2. Identity attributes were populated according to the usual mapping rules.
  3. Roles were assigned, indicating that the account attributes were, in fact, set.
  4. Accounts were provisioned according to the assigned roles, including Active Directory and a couple of others. These had their attributes properly populated via Provisioning Policy, reflecting the values from the Identity.
  5. (SOMETHING MYSTERIOUS)?!?! :thinking:
  6. The Identity attributes were blank, leaving only name and displayName??? The accounts and roles remained, with their appropriate field values. However, a subsequent attribute sync tried to set blank values in AD, which failed.

Diagnosis

We were able to narrow down this behavior to the customer’s Active Directory connector. We were able to reproduce it with a single Business Role and IT Role, which provisioned the AD account. If we separated the aggregation and the refresh (un-check the role assignment during aggregation, then run an Identity Refresh task afterward), the behavior was eliminated.

This odd behavior was accompanied by Hibernate log messages like the following:

deleted object would be re-saved by cascade (remove deleted object from associations): [sailpoint.object.EntitlementGroup#0ab648db906018b8819062848df15471]

org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [sailpoint.object.Link#0ab648d99068142e8190690915bc2f20]

I’ve seen behavior like this before when IIQ locks Identities twice, nested, but a newly created Identity should not be locked during initial provisioning. In fact, there ought to be nothing to lock.

Solution

It turns out that the PlanEvaluator class has an updatePasswordHistory method. When it sees an attribute called password on an application, which AD does have, it updates the password history of the Link. Makes sense. But it also locks the Identity in order to do so. Locking the Identity was reloading the previous (without attributes) copy of the Identity, then committing it during unlock.

The solution, it turns out, was to remove the password attribute from all AccountRequests in an After Provisioning rule. Something like this:

AttributeRequest pwAttrRequest = accountRequest.getAttributeRequest("password");
if (pwAttrRequest != null) {
  accountRequest.remove(pwAttrRequest);
}
2 Likes