none
Re-trigger initial flow

    שאלה

  • Some details about my environment:

    • HR is the source for new employees
    • I'm using the FIM Service/Portal for codeless provisioning.
    • ActiveDirectory is one of the target systems. Everyone from HR needs to have an AD account.
    • When a new employee is created in HR, the FIM Service generates an initial password, which is exported to the new AD account.

    A new employee from HR can already be present in AD if he or she worked for the organization before. In that case, the AD account is disabled. After HR projection of the 'new' employee, the existing AD account is then joined.

    That all works well, but the question is: how can I export a new password to the existing AD account. There's no problem in creating a new initial password in the metaverse, but the export rule is set to 'initial flow only'. Therefore, the newly created initial password will never be exported to the already existing AD account.

    Best regards,
    Pieter.


    Pieter de Loos - Consultant at Traxion (http://www.traxion.com) http://fimfacts.wordpress.com/

    יום חמישי 07 יוני 2012 21:15

תשובות

  • One way to do this (the way I did for a project) is to create a Request MPR for the change from a disabled set to an enabled set and run a custom workflow that makes a WMI call to the password reset feature of the AD MA.

    You could also do a transition in MPR to an 'enabled user' or 'new user' set depending on thje specifics of your design.

    You might also consider a notification activity to communicate the new password. if your password change activity stores the new password as workflowData, the notifiction activity can pick it up and it goes away at the end of the workflow so you don't need to worry about keeping passwords around.


    Frank C. Drewes III - Architect - Oxford Computer Group

    • סומן כתשובה על-ידי Pieter de Loos יום שני 11 יוני 2012 08:05
    יום חמישי 07 יוני 2012 22:48

כל התגובות

  • One way to do this (the way I did for a project) is to create a Request MPR for the change from a disabled set to an enabled set and run a custom workflow that makes a WMI call to the password reset feature of the AD MA.

    You could also do a transition in MPR to an 'enabled user' or 'new user' set depending on thje specifics of your design.

    You might also consider a notification activity to communicate the new password. if your password change activity stores the new password as workflowData, the notifiction activity can pick it up and it goes away at the end of the workflow so you don't need to worry about keeping passwords around.


    Frank C. Drewes III - Architect - Oxford Computer Group

    • סומן כתשובה על-ידי Pieter de Loos יום שני 11 יוני 2012 08:05
    יום חמישי 07 יוני 2012 22:48
  • Thanks! I haven't thought of that!

    Pieter de Loos - Consultant at Traxion (http://www.traxion.com) http://fimfacts.wordpress.com/

    יום שני 11 יוני 2012 08:05
  • Yes returning users are tricky. In our environment the same person can return as a different "type" of worker i.e. was Internal, now External and so gets a different employeeID. Quite fun matching them up.

    We run a Powershell script from a custom activity when a user transitions out of the deleted users set. (All FIM managed AD accounts will be in the Portal users. ) The Powershell script can modify the AD account directly e.g. by code like

    $user = [ADSI]$userDN
    $user.psbase.invoke("SetPassword",$newpwd)
    $user.Put("pwdLastSet",0)
    $user.SetInfo()

    which resets the password and forces a change at next login. I prefer PS approach as the CustomActivity code driving the PS can log everything that happens, good and bad. I am a bit wary of WMI calls. Naturally the $newpwd generated in the C# code is pushed back into the WF as a WorkflowData parameter (workflow dictionary thingy?!) so it can be sent in a manager notification

    יום רביעי 13 יוני 2012 09:05
  • Harold,

    Yep - same idea - slightly different approach. I like the idea of a 'generic'powershell activity that can be tasked to run any PowerShell script you like.

    I've already been through the 'pain' of learning WWF, so writing up a process in that is familiar - but being able to do what you want in PS is definitely more attractive, since that skillset is a lot more readily available.


    Frank C. Drewes III - Architect - Oxford Computer Group

    יום רביעי 13 יוני 2012 11:46
  • Al tough this might work, I don't really like the idea of contacting a target system other than FIM Sync from a portal workflow.

    Thanks for the input!

    Best regards,
    Pieter.


    Pieter de Loos - Consultant at Traxion (http://www.traxion.com) http://fimfacts.wordpress.com/

    יום רביעי 13 יוני 2012 11:49