Auto Generate a password in a script

Hello.

I need to generate a password for a user in a policy script.  I'd like the password to be compliant with the password policy I've already setup in ARS, and which is generated if I use the New User wizard from the ARS MMC console.  I don't see how to do this though.

I know I can change a user's password with the following snippit of code.

$newPW = "P@ssW0rd"
$Request.Put("edsaPassword", $newPW)

My problem is how to a generate a text string that is compliant with the password policy in ARS.

I can see a builtin function called New-Password which seems to do what I want, but I can't call it or include it in a policy script.

Any help would be appreciated.

Craig.

  • Hello, would you be able to provide a little more detail on this use case? Would this be for automated user creation (Sync Service/SPML/PowerShell)?

    It sounds like you may have adjusted the parameters in either the "Built-in Policy - Password Generation" policy or called the "Generate User Password - PowerShell" script again in a new policy to set the password strength and character/special character set as needed?

    To be able to utilize the New-Password function, I would approach this by making a copy of the built-in password generation script. It can then be altered to essentially make it a stand alone script to be able to be called to generate a password outside of the interfaces (MMC/web interface). This new script can then have all of the compliant settings statically contained within it so that it would generate a secure password.

    On a more advanced level, there would be a way to bind to the policy where you have already configured the password setting parameters and query them so that this new script would be dynamic if these password settings were to ever changed. I can provide more details if this sounds like the direction you would like to pursue.

  • Hello Richard.

    I have two scenarios where I need to generate a new password.  The first is from Powershell.  I've connected to the ARS service and I'm using new-QADUser to create user objects. 

    The second scenario is a bit weirder.  We have a business process which requires us to create user accounts that may not be used for a few days or weeks (they come from an HR system in a CSV file).  My thought was to create all the user objects and leave them disabled, I'd also assign a random compliant password which I wouldn't log.  This part would be done from a powershell script external to ARS, but using the OneIdentity powershell module and connecting to the ARS Admin service.  I've also created a virtual attribute that basically indicates if the account is fully provisioned or not.  Then when the account is needed a help desk analyst would make whatever manual final tweaks are necessary either from the MMC or Web Interface, and flip the virtual attribute from False to True.  I'd have a workflow that triggers on the modification of that attribute, it would call a postmodify eventhandler script that would generate a new initial password for the user and put it into our password distribution mechanism.  If there is a better pattern for accomplishing this I'm interested in hearing about it.

    I did find this note that describes how to trigger the generation of an new password according to the ARS password policy

    https://www.oneidentity.com/community/active-roles/w/wiki/27/standalone-script-that-requests-built-in-password-generation-policy

    However it's written in VBScript which you can't call from a workflow, I adapted it into Powershell but it doesn't work.  When I actually access the GeneratedValue property of the PolicyInfo object it returns an empty string.

    It'd be ideal if password generation in these scripts followed the password policy in ARS.  So I don't need to change any code if password requirements change.  I've worked around the problem by writing my own password generation function and putting it in a library script, however it's not ideal because if the password policy changes in the future the script would need to be modified as well.