none
FIM Powershell Password Reset Workflow RRS feed

  • Question

  • Hello All,

    I'm trying to use the FIM portal in order to allow helpdesk to reset an users password upon the end user calling helpdesk. But am running into an issue with the powershell workflow.


    Currently I have added a boolean attribute called "PasswdReset" and binded it to the user type.
    Created an criteria based set called "PasswordResetUsers" which will transition users into when passwdrest is set to true.
    Created an workflow called "PasswordResetWF" which is made up of several steps
    1. The powershell activity which executes the following script

    Import-Module Activedirectory
    $newpwd = ConvertTo-SecureString "P@ssw0rd" -AsPlainText –Force
    Set-ADAccountPassword SampleUser -Credential domain\administrator -NewPassword $newpwd -Reset -PassThru | Set-ADuser -ChangePasswordAtLogon $True
    Here lies the problems
    First how do I pass the samaccountname of the user to the powershell script to replace the sampleuser parameter.
    Second How do I  force this script to run as the domain\administrator without prompting for password

    The rest of the workflow is as follows.
    2. Trigger custom email notification to an monitored email account for logging purpose
    3. Trigger custom email notification to Helpdesk monitored email account to generate support ticket. 
    4. OOB function to set "PasswdReset" attribute to false and transition the user out of the "PasswordResetUsers" set.

    As always any suggestions would be greatly appreciated. 



    Friday, March 13, 2015 3:20 AM

All replies

  • Hello,

    iI did something very similar.

    Assuming you use this PowerShell Activity:https://fimpowershellwf.codeplex.com/

    you can simle pass data to the Activity with the "function evaluator" through the WorkflowDictionary like this:

    AccountName > [\\WorkflowData\samAccountName]

    This WorkflowData is passed to to next Activity and you can get the values in your script like this:

    $fimwf.samAccountName

    Impersonation to Administrator is not possible OOB with that activity, by Default it runs as the FIMService Account but you can Change this to the account who is starting the request.

    In my Environment I gave the FIMService the permission to reset account Password.

    -Peter 


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Friday, March 13, 2015 8:15 AM
  • Hi Peter,

    Thanks for the quick response I have created an Function Evaluator called "Get Account Name" and it is as follows. 
    AccountName > [//WorkflowData/samAccountName] (notice the slashes are going in the other direction.

    As a sample test I have a powershell script that writes the output into an text file

    "Sample Data" | Out-File "C:\FIM_WF\test.txt" -Append
    $fimwf.samAccountName | Out-File "C:\FIM_WF\test.txt" -Append

    However the samAccountName doesnt get written to the file only the text Sample Data. I dont think the samaccountname is being passed from step one to step two of the workflow.

    Any advice is greatly appreciated.

    Friday, March 13, 2015 7:19 PM
  • Which PowerShell Activity do you use, is it the one I mentioned above, or another one ?

    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Friday, March 13, 2015 7:56 PM
  • Hi Peter it is the same one as you mentioned. Please see the attachment.

    Friday, March 13, 2015 8:15 PM
  • Hello,

    ohh sorry i remembered something wrong.

    I take a look in my scripts.

    $fimwf contains default properties like GUID and the complete workflow dictionary, so you have to get it in your PowerShell like this:

    $fimwf.WorkflowDictionary.samAccountName | out-file .....

    -Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Saturday, March 14, 2015 8:45 AM
  • Hi Peter,

    Thank you i now see the right samaccountname in the text file. However when I run my powershell script to reset password nothing happens. Can you look over this and let me know if you see anything wrong.

    Import-Module Activedirectory
    $newpwd = ConvertTo-SecureString "P@$$w0rd" -AsPlainText –Force
    Set-ADAccountPassword $fimwf.WorkflowDictionary.samAccountName -NewPassword $newpwd -Reset -PassThru | Set-ADuser -ChangePasswordAtLogon $True

    Saturday, March 14, 2015 12:39 PM
  • Hello,

    looks exactly as my solution and should work, I'm not quite sure but is can be that you must put the Value from the workflow dictionary into a normal string variable first, because of the type.

    Are there any PostprocessingError in the request history ("Search Requests")

    It is also a good idea to activate logging to eventlog, see: https://fimpowershellwf.codeplex.com/wikipage?title=Adding%20the%20System.Diagnostics%20Entry%20in%20the%20FIM%20Config%20File&referringTitle=Documentation

    -Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Saturday, March 14, 2015 12:54 PM
  • Hi,

    I am trying to accomplish the same thing.

    I have followed both your instructions and Peter_Stapf's instructions.

    I have installed the "Active Directory module for Windows PowerShell" feature.

    I have granted the FIMService account reset password permission to the test user.

    The request fails

    status PostProcessingError
    Request Workflow Remarks Exception of type 'Microsoft.ResourceManagement.Workflow.WorkflowExtensionException' was thrown

    For the request, switching to the advanced view and looking at the "Request Status Detail" shows

    <RequestStatusDetail xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" DetailLevel="Information" EntryTime="2015-04-01T16:24:40.5317426Z">Exception of type 'Microsoft.ResourceManagement.Workflow.WorkflowExtensionException' was thrown.</RequestStatusDetail>

    I have configured PowerShell, in case it uses actual scripts;

    set-execution policy unrestricted

    I have enabled logging as described in Peter's last reply, but can't find anything significant...

    Would really appreciate any help with this.

    Anwar

    Wednesday, April 1, 2015 4:41 PM
  • Hello,

    there should be some eventlog entries in the Application Log from Source "PowerShellActivity" if debug logging is correctly enabled.

    -Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    • Proposed as answer by Anwar Mahmood Wednesday, April 1, 2015 5:12 PM
    Wednesday, April 1, 2015 4:46 PM
  • Peter,

    Thanks for your reply.

    Had another look; events are indeed present;

    Log Name:      Application
    Source:        PowerShellActivity
    Date:          01/04/2015 17:45:31
    Event ID:      0
    Task Category: None
    Level:         Information
    Keywords:      Classic
    User:          N/A
    Computer:      SERVER.DOMAIN

    Description:
    01/04/2015 16:45:31 -- Executing: Import-Module Activedirectory
    $newpwd = ConvertTo-SecureString "P@$$w0rd" -AsPlainText –Force
    Set-ADAccountPassword $fimwf.WorkflowDictionary.samAccountName -NewPassword $newpwd -Reset -PassThru
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="PowerShellActivity" />
        <EventID Qualifiers="0">0</EventID>
        <Level>4</Level>
        <Task>0</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2015-04-01T16:45:31.000000000Z" />
        <EventRecordID>50286</EventRecordID>
        <Channel>Application</Channel>
        <Computer>SERVER.DOMAIN</Computer>
        <Security />
      </System>
      <EventData>
        <Data>01/04/2015 16:45:31 -- Executing: Import-Module Activedirectory
    $newpwd = ConvertTo-SecureString "P@$$w0rd" -AsPlainText –Force
    Set-ADAccountPassword $fimwf.WorkflowDictionary.samAccountName -NewPassword $newpwd -Reset -PassThru</Data>
      </EventData>
    </Event>

    In my case, it was password policy.

    Thank You!


    Wednesday, April 1, 2015 4:58 PM
  • Choosing a different password reset string, and it now works!
    Wednesday, April 1, 2015 5:04 PM