Bulk password reset using a CSV using a workflow

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. 

One more question on this topic. We have multiple forests in ARS.  We are only successful in one domain even if we specify another domain in our script.  We can create in ForestA but even if we use the  -server ForestB switch it fails.  Where as if we do this task manually we are successful. Only when running the script do we receive error going out side ForestA.   All that be said the application is running with a ForestA gmsa account. I am guessing that it is using that account when running the script. I do have different account for other Forests under Managed Domains. 

By default, scripts execute as the admin service account.  The SDK specifies a method for referencing the configured domain specific creds (a.k.a. override accounts):

Here's an example:

 # Find out what domain the in process user is in by grabbing their distinguishedname

   $UserDN = $Request.DN

# Determine the override creds applicable to the in process user's domain by passing the DN - returns a credential object

s $Creds = $DomainOverrideCredentials.Get($userDN)

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.

Hi, 
I got this working for one forest which has a trust with the domain ARS is hosted in.  But I can not get it working another forest which has no trust. 

As the accounts are rolling in from CSV I am looking a what forest/domain each account is in.    I am using get-aduser <name> -server <forest name> but I am getting "unable to contact the server" on one of the domains.     I see that get-Qaduser does not have the -Server option.  Is there a switch I can use to get user info for another forest within the script?  That way I can get the DN and process the password change like I can for 2 of the 3 forests?

The Get-ADUser '-Server' switch and Get-QADUser '-Service' switch do the same thing.

If you have the DN of the user, what I have done in the past is extracted the DC=... bit of the DN and converted that to a domain FQDN for use in one of the switches above.

Further to my answer above, you always have the option of adding credentials i.e. '-Credentials' to any command but you will need figure out how you want to implement the creation of the credential object (the passing of the password is usually the sticking point).

I'm not clear on whether you are running your script interactively or "inside" of Active Roles as a policy script and/or script activity in a workflow of some kind.

If the latter, you can setup an untrusted domain with specific credentials for that domain  (a.k.a. "override account") specified in your Managed Domains in Active Roles.

You can force the use of those credentials in a policy script something like this:

$UntrustedDomainCreds = $DomainOverrideCredentials.Get($userDN) # $UserDN is the object that you will eventually modify

Set-ADUser -identity $UserDN -Server $UserDomain -Credential $UnTrustedDomainCreds

This is what I have in my script to get the credentials to use to update the user in a foreign forest

the samaccountname and domain are coming from my import-csv command. 

$testuser=get-Qaduser $user.samaccountname -Service $user.domain
$userDN = $testuser.DistinguishedName
$credentials = $DomainOverrideCredentials.Get($userDN)

I am now getting Logon failure: unknown user name or bad password. when running the get-Qaduser $user.samaccountname -Service $user.domain

You need to add the -Credentials switch to your Get and move the Get AFTER you obtain the credentials.