userPassword not reflected in Active Directory

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Hello,
We are on IIQ 8.3 and trying to add reset userPassword as part of leaver plan. The Access Request shows that it is successful, however the AD Account does not actually seem to have had the password reset. The passwordLastSet property doesn’t change and when trying to use the account with the new password it rejects as bad password.

I’ve tried with both a static password for testing and using a generatePassword function. Both show up looking good in the Provisioning plan.

    acctReq = new AccountRequest(AccountRequest.Operation.Modify, account.getApplicationName(), account.getInstance(), account.getNativeIdentity());
    acctReq.add(new AttributeRequest("AC_NewParent", ProvisioningPlan.Operation.Set, newParent));
	  acctReq.add(new AttributeRequest("msExchHideFromAddressLists", ProvisioningPlan.Operation.Add, true ) );    
    //acctReq.add(new AttributeRequest("userPassword", ProvisioningPlan.Operation.Set, generatePassword()));
  acctReq.add(new AttributeRequest("userPassword", ProvisioningPlan.Operation.Set, "l8X.5v6H-Tx4E007"));

Any ideas on why this would not work?

Thanks!

2

For AD/LDAP and most other connectors that support the PASSWORD feature OOB, the AttributeRequest should generally just be password.

1 Like
3

Hi Brian,

Thanks, I can’t get either to work! Will work with ES to try to figure it out.

Thanks again.

4

@chrisk - Good luck! And have you tried inspecting the Provisioning Plan that’s being sent to the connector to make sure it looks correct? I generally log out a plan.toXml(); in the BeforeProvisioning rule and look for anything that might be off. If you like, you can scrub the plan XML (remove/obfuscate person and company-specific info) and share it here for additional sets of eyes!

Also, Password Change/Update is OOB supported by IIQ, so I would suggest starting with a standard Support case and work it from there.

1 Like
5

Hi Brian,

It looks like a lot of information to look over - if anyone here actually wanted to set eyes on it. I captured the entire log from the Termination Workflow. This is from a Sandbox Environment and scrubbed.

Before the Termination I looked in AD and the userPassword Attribute was blank. Afterwards it was filled in with something, but when account enabled still could not logon and pwdLastSet had not changed.

Thanks to anyone who actually looks at it!!

Chris
catalina.out.txt (256.1 KB)

6

Yeah, it’s a lot of output, but I’ve seen worse, lol. Something I did notice is that the initial plan (on line 630), you can see the userPassword AttributeRequest and is has a value. Skip forward a bit to where you enter the Starting workflow SP Provision Processor Sub (line 736), something has modified the plan (as you can see on the plan in the variable starting on line 814, the password is gone: <AttributeRequest name="userPassword" op="Set"/> (line 824). That “mysteriously updated” plan carries through to the Starting step Compile Project stage (line 992, with the output Project XML on line 994). Notice in both the project MasterPlan and the compiled Plan both contain the same <AttributeRequest name="userPassword" op="Set"/>.

It looks like that somehow got pulled into the ApprovalSet (line 1436-1447). The IdentityRequestItem also has no reference to a value component (lines 1506-1512). The ApprovalSet gets auto-approved (as seen on 2351-2384), and the password value reappears in the plan output variable (line 2476), but not in the project output variable (line 2389). It then moves to the provisioning phase where it recompiles the project (line 2978), but the userPassword value is still absent in both the MasterPlan and Plan sections of the project return from that step. Moving forward to the Starting workflow Provision with retries subprocess (line 3211), you can see that the input project is still there with no password value (3243). So it looks like that one is the one that is being executed by the provisioner (that subprocess ends at line 3482 with no indication of errors, as the return project variable indicates success via <ProvisioningResult status="committed"/> on line 3572). The Starting step Post Provision seems to indicate a project with a value for password was executed (line 3866-3960), but the project return from the SP Identity Request Provision on line has no password value.

Now I’m not big into the SSF myself, so I could be wrong, but it looks like an incomplete/incorrect project is being executed. It’s certainly possible that the password value is being deliberately stripped from the SSF workflow trace output, but I find that pretty unlikely - especially since it shows up in other parts of the logs as one would expect.

Just for a sanity-check, I’d suggest attempting to test a password change outside the Leaver process (and the SSF). Take one of the plan XMLs that you have in that log and tweak it to a suitable test case and attempt to execute it via the OOB LCM Provisioning workflow, or even via the console provision command (see IIQ Console for testing Provisioning Rule - IIQ 8.2 - #2 by brian_weigel).

1 Like
7

Wow! What an incredibly helpful and generous response! I’m still trying to learn all this stuff as I go, this will be helpful. I’ll dive into all of this and see what comes of it.

Thank you so much for taking time to help, truly appreciated!

I’ll respond if/when I find something.

Chris

1 Like