Bulk password reset using a CSV using a workflow

Hi,

We have a situation where we need to have techs submit a csv file listing users and passwords that need to be reset. We currently have a single script in a workflow that does this but since the script uses the service account and not the techs account. They can reset  passwords of users out side the OUs they have rights to.   I was told we need to use a workflows to correct this.  Can you provide any guidance around this?

Thanks much

Tony

Parents
  • Hello, how is the password reset workflow initiated? Does it run on a scheduled basis or do these techs have the ability to run the automation workflow whenever they have a csv file ready?

    If the workflow is running on a scheduled basis, the workflow will always run as the service account. There isn't a way around this, and the process of kicking off the workflows may need to be altered as indicated below.

    If the techs are manually kicking off the workflows, there is a "Run As" setting within the workflow's Options and Start Conditions, to have it run as "The account of the user who started the workflow". This may solve the issue of the techs being able to reset passwords in OUs they are not delegated access. Additional rights will probably need to be granted to the techs to be able to see and run automation workflows.

  • Hi Richard, The techs have the ability to run the workflow when they have a need to do so.  I did try the "Run As" setting but that did not make a difference. 

  • I am running my tests in version 8.1.3. There is a Control called InheritInitiatorInfo, described in the SDK, that can be added to the operation. Looking at the event log when using this control in a Set-QADUser cmdlet, I am seeing the Initiator value change from the service account to the user's name that started the workflow. However, the change is still occurring, even though the user/Initiator does not have rights to perform the update. If I test this using an Update workflow step, and hard code the user to update and action, it fails with an 'Access Denied' error, which is what I would expect the script to do as well when setting the InheritInitiatorInfo control. I'm still researching/testing this.

Reply
  • I am running my tests in version 8.1.3. There is a Control called InheritInitiatorInfo, described in the SDK, that can be added to the operation. Looking at the event log when using this control in a Set-QADUser cmdlet, I am seeing the Initiator value change from the service account to the user's name that started the workflow. However, the change is still occurring, even though the user/Initiator does not have rights to perform the update. If I test this using an Update workflow step, and hard code the user to update and action, it fails with an 'Access Denied' error, which is what I would expect the script to do as well when setting the InheritInitiatorInfo control. I'm still researching/testing this.

Children
No Data