Share all details about your problem, including any error messages you may have received.
Hello everyone,
I would like to know how the Password Intercept workflow works.
We currently have 2 password change modes configured in Sailpoint:
Password change from Active Directory or domain PC
The Password Intercept workflow runs during password changes correctly and propagates the newly updated password via the interceptor to the various targets that the identity has associated with it.
Change password from Sailpoint (Manage Passwords)
A second custom workflow configured for password changes, independent of the password intercept, after validating the password in Sailpoint, propagates it to the various targets that the identity has associated with it, including the Active Directory.
When it is propagated to the AD, the password intercept workflow is executed, updating the password again on all targets.
I wanted to know whether this behaviour is expected or is a workflow anomaly, since if the pwd is changed by Sailpoint we only expect it to update once and not to be propagated again.
Is there a possibility of not triggering the interceptor if the password change was made directly in Sailpoint?
This anomaly is blocking for us because with the Password Intercept wf we set a static value for pwd changes made by the domain, and this value must not be set at all if the change was made by Sailpoint, while it currently is set because the password intercept is performed with the pwd change by Sailpoint.
Usually, in an installation only one is used because its a best pratice to have only one Password Manager but in your case(and in mine too ) you have 2 source where a user can change the password.
Before all, you can block the pwd update on AD where PWI events come in IIQ. Into the PWI workflow you can find the Select Targets step; there you can return a list of application where you want change the pwd:
<Step name="Select Targets" posX="127" posY="15" resultVariable="targetApplications">
<Arg name="targetApplications" value="ref:targetApplications"/>
<Arg name="applicationName" value="ref:applicationName"/>
<Script>
<Source>
// Placeholder for custom application selection.
// The result must be left on the targetApplications list
// as either a csv or List(String) of Application names.
List appList = new ArrayList();
appList.add("app1");
appList.add("app2");
appList.add("app3");
return appList;
</Source>
</Script>
<Transition to="Compile Project"/>
</Step>
so you put all the apps except AD.
About the Manage Password, you can permit the change password only for AD. With this configuration the flows will be the following:
From AD → PWI → IIQ → Target System
From IIQ → AD → PWI → IIQ → Target System
Withi this you dont have any loop and all the application will be updated.
@Marzia00 This is expected behavior and the same behavior will occur if you have multiple ad and they have password interceptor in their side so it will send and then ping pong condition will occured. In your case ping pong will not occur but it will change in ad and then again in sailpoint and target system. To handle this , we can do:-
SailPoint password change workflow you can exclude AD but this will not be helpful as user end up with 2 password.
If you are using Password history and does not have one way hashing then you can write a validation in password interceptor workflow and handle there that if password is same which is in history then terminate the workflow
If you have one way hashing then you can check the latest task result and that is from 10-15 mint before then terminate the user password change.
You can only change the password in AD when user try to change from quicklink and AD will do the rest of downstream application.
Point 4 u can go it will be helpful. Point 2 and 3 you can use for other multiple different ad and those scenarios .
) you have 2 source where a user can change the password.