Delay in execution of Password Reset and Account Unlock operations

Hello everyone. We have one custom script in the production which is performing password reset and account unlock operations on the domain. This script is called by an external application (IVR Solution) with AD SAMAccountName as input parameter and script reset password and call SMPP API to deliver password to end user and confirmation of account unlock as well.

We are facing an issue where end users AD account unlock and password replication on all DCs is taking too much time as compared to the password manager solution we have, since password manager has a feature to replicate changes on selected DCs, hence, changes are very instant. 

My question is that is there a way to speed up the script execution in one identity or can we provide multiple DCs in the sync editor connection parameters to speed up things? priority setting in the designer is only for processes. However, in our case we are just executing a script via One Identity APIs.

we are using 1IDM 8.0.2.

Best regards,

Daniel

Parents
  • Even when you calling the password reset via a script, the execution of the password update operation is done by the process engine of OneIM, therefore setting a higher priority for the "Update Account" process step is a good idea and is part of the OOTB process ADS_ADSAccount_Update/(De-)activate. Check the priority definition script of this process step.

    Keep in mind that the lookup interval on the Job Service itself (how often does he look for tasks in the job queue if he has nothing to do) is essential as well. The default is 90 sec.

    And, if you want to select a different DC to perform these password updates, you can override the script ADS_SetOverrideVariables_for_Projection. The OOTB one contains an example that explains how to override the DC selection made in the synchronization project with a custom one.

    HTH

Reply
  • Even when you calling the password reset via a script, the execution of the password update operation is done by the process engine of OneIM, therefore setting a higher priority for the "Update Account" process step is a good idea and is part of the OOTB process ADS_ADSAccount_Update/(De-)activate. Check the priority definition script of this process step.

    Keep in mind that the lookup interval on the Job Service itself (how often does he look for tasks in the job queue if he has nothing to do) is essential as well. The default is 90 sec.

    And, if you want to select a different DC to perform these password updates, you can override the script ADS_SetOverrideVariables_for_Projection. The OOTB one contains an example that explains how to override the DC selection made in the synchronization project with a custom one.

    HTH

Children
  • Hi Markus,

    Thank you very much for your reply. I found below condition on priority for the process step "Update Account" in the OOTB process ADS_ADSAccount_Update/(De-)activate.

    If $UserPassword[o]$ <> $UserPassword$ Then
    Value = 7
    Else
    Value = 3

    How can I enhance this for account unlock operation. Since account is locked at domain level and I suspect column AccountLockedOut will not be 1 in this case, unlike password operation where AD password value is changed actually in the adsaccount table column.

    Best regards,

    Daniel

  • These are two separate problems. I assume that If you want to reset the AccountLockedOut flag, you are setting the UserPassword as well so the condition hasn't to be changed.

    But to enforce an unset AccountLockedOut flag to sync to AD you need to deal with the ForceSyncOf parameter that is used in the ADSAccount_Update/(De-)Activate process. With this parameter, you can specify that columns that should be synced to the target system explicitly, and this value is set in the Pre-Skript of the process chain itself. But it can be set via the parameter collection as well. Combine that with setting the AccountLockedOut property 0 False if the UserPassword is set and you have your solution.

    Long story short, starting with 8.1 you have the option OOTB available. There is a configuration parameter (TargetSystem | ADS | Accounts | UnlockByCentralPassword) that would allow the system to automatically unlock the account in AD if the UserPassword is changed via the CentralPassword of the linked person.

  • Hi Markus,

    I just checked, ForceSyncOf is fired for both accountlockedout and userpassword. My problem is that during peak business hours we have HR synchronizations, IT shop requests, other operations etc and users are unlocking/resetting passwords via IVR which as explained earlier are executed via process ADSAccount_Update/(De-)Activate. 

    We noticed today that queue size was very long and single request took almost 15 minutes to execute from 1IDM. Our end goal is to speed up the entire process and we already reduced AD replication time but if process execution itself is delayed from 1IDM then I can see all guns pointed at 1IDM.

    Remediation approach:

    If I increase the value from 7 to 14 (since forcesycof is getting fired for account unlock n pwd reset) and combine this with job lookup interval to 30 sec, will this approach help?

  • I think increasing the value from 7 to 14 may not bring enough speedup.

    Things to consider are:

    • Reduce the job lookup interval. Start with 30sec and see how it goes, but do not reduce it below 10 sec.
    • Think about giving all AD processes a separate queue (QBMServer) for processing. You do not need to use a separate job service to do that. A job service can handle more than one queue. In that case, no other jobs could block the queue for your password resets.
    • Think about my proposal to determine the best DC for your password reset from my first answer.

    HTH

  • Thanks Markus for your suggestions. 

    I increased the priority and reduced the refresh interval to 25 sec. Meanwhile Active Directory admin reduced the replication time as well. Next step is to create a separate AD processes queue.

    I'll perform detailed testing and share my findings here.

    Best regards,

    Daniel