none
Hiding generated password in the request queue RRS feed

  • Question

  • Hi all,

    I'm using a workflow parameter in a sync rule to call out to a workflow which generates an initial password for a new user. The workflow uses the MIMWAL 'GenerateRandomPassword' function to generate the password and pass it back to the sync rule to flow to unicodePwd; all good.

    The problem I have is that the password returned by the workflow appears in the ERE creation request in the request queue. Our security folks aren't too keen on this... Is there any way to generate a proper random password without the result appearing in the request queue?

    Thanks,

    Lee.

    Tuesday, July 5, 2016 2:10 PM

Answers

  • Hi,

    the only thing that came to my mind is to remove that attribute from the request object.

    or you can put the PW generation into extension code (provisioning) or build a custom activity (or use PowerShell activity) to write a PW directly to AD after object was created the first time.

    /Peter


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

    • Marked as answer by leemar Thursday, July 7, 2016 9:55 AM
    Wednesday, July 6, 2016 8:09 AM

All replies

  • Hi,

    the only thing that came to my mind is to remove that attribute from the request object.

    or you can put the PW generation into extension code (provisioning) or build a custom activity (or use PowerShell activity) to write a PW directly to AD after object was created the first time.

    /Peter


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

    • Marked as answer by leemar Thursday, July 7, 2016 9:55 AM
    Wednesday, July 6, 2016 8:09 AM
  • Hi Peter,

    Thanks for your reply. The password appears in 'Synchronisation Rule Data' in the request. I'm not sure if I can exclude that attribute from the request object and what the effect would be. I couldn't see a way to do it as it doesn't appear in the schema as an attribute of the request object.

    I'm going to have a go at writing a powershelgl activity to do this.

    Thanks for your help!

    Lee.

    Thursday, July 7, 2016 9:55 AM
  • Leemar,

    Peter means that you have an WF that later deletes the value from the request object. Obviously, you can't prevent it from getting there in the first place.

    It would have been nice if MSFT had created some sort of encrypt and decrypt option. But they didn't.

    The next best thing you can do is to generate the password and store it in a workflow variable. Then change it in a repeatable way and store that in a different workflow variable. Email the user's manager with the second. Send the first to the Workflow that applies the Sync Rule, and then in the sync rule repeat the change. In this way the exact password is never stored in the FIM Service database on a permanent basis.


    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Thursday, July 7, 2016 6:12 PM