This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using a custom password generation script

Hi,

I would like to use a custom password generation script written using powershell.

The custom script is essential just a copy of the default, but I swapped the "New-Password" function with my own and then deleted some of the other checks the default script does.

The password generation piece is another script I found online that I tweaked slightly to meet my requirements.

The new script also needs to reference a CSV file.

I have two questions regarding this:

  • Can you reference a CSV file stored locally on the C: drive of the ARS server from within a script module? Or is it possible to store the file inside ARS itself? If the file can be stored inside ARS, how is it referenced?
  • How can I test this new password generation script in ARS? It appears that we have already blocked the builtin "Built-in Policy - Password Generation" and created our own policy that appears to just be a copy of the default. I tried changing the script that the custom policy runs, but it still generates the same passwords.

function Create-Password
{ 
    
    $rand = New-Object System.Random

    # read-in very large file creating smaller list of random words
    $words = Get-Content "C:\Scripts\Generation\clean_words.csv" | Sort-Object {Get-Random} -unique | select -first 100

    # query the smaller list of words for single entry (2 times)
    $word1 = $words | Sort-Object {Get-Random} -unique | select -first 1  
    $word2 = $words | Sort-Object {Get-Random} -unique | select -first 1
    $word3 = $words | Sort-Object {Get-Random} -unique | select -first 1
  
    # create random digits
    $number1 = Get-Random -Minimum 10 -Maximum 99
  
    # get random special character
    $special = Get-Random -InputObject "!","@","#","$","%","&","*"

    # Recreate word 2
    $word2 = $word2.Substring(0,1).toupper() + $special + $word2.Substring(1,$word2.Length-1)

    # concatenante and return new random password
    return (Get-Culture).TextInfo.ToTitleCase($word1) + $word2 + (Get-Culture).TextInfo.ToTitleCase($word3) + $number1

}

Thank you,

Cheers

  • Correct. You can feed your custom MyPassword.ps1 script inside ARS Workflow (policy) and overwrite the existing built-in ARS Policies. Customer do it. 

    ARS Workflow. It will require some understanding of ARS engine how to feed inProcess variables $DirObj and $Request inside the AR workflow and disable the built-in policies without damaging whole ARS Automation Policies and Workflows Configuration.

    Custom script. I would recommend to look at ARS SDK (comes with the install on C:\ drive in ARS folder).

  • Hi Aidar,

    I have placed my customized script into a copy of the builtin password script. I didn't want to overwrite the builtin one in case something gets messed.

    How can I have my new script be the default script used to generate passwords?

    The builtin password generation script is set to"Exclude Explicitly" for our "Active Directory"

    And the copy of the builtin one is currently set to apply from the root of our AD structure. But when I swapped scripts, the old password generation still seemed to kick in. Is there a way I can see exactly what policy is being used to generate passwords?

    I checked in the SDK and didn't find any examples of an ARS script referencing an external file. Are there any examples of this anywhere?

    Thank you,

    Cheers

  • Hi,

    This was resolved. The process goes something like this....

    1. Create your password script
      • I personally copied the builtin Powershell one and then just replaced the "New-Password" function with my own
    2. Create a new policy and give it a meaningful name
    3. To test, attach the policy to an OU in your structure
      • Be sure to block the default password generation policy.
    4. Right click on a user and select "Reset Password", then hit the generate button. If your script is working, then you should get a password generated for the user.

    Initially, I had created a copy of the builtin policy. I am not sure why, but the system seemed to not like this as it continued to use the builtin/default password generation policy, even after blocking it.