dnewsholme/PasswordState-Management

New-RandomPassword: Using the password generator policy for the specific password list

colombeen opened this issue · 11 comments

colombeen commented

Instead of the function containing a default of 12 chars, ... adding the ability to set a default password rule, defining what a new password should be like without additional params

# Set default new password rule
Set-PasswordStateDefaultPasswordRules -Length 20 -includeuppercase -includelowercase

But if you decide to add this, a Get- should be created as well ofcourse to view the current situation.

EDIT:
If I'm not mistaken, there is a "new password rule" in PasswordState itself, maybe you could read that one??

colombeen commented

I've found some more info on this in the documentation... But it's still not straight forward.

You can use the PasswordGeneratorID to force a specific policy rule

# This seems to be the default policy (1)
PS C:\> $uri = "/api/generatepassword/?PasswordGeneratorID=1"
PS C:\> Get-PasswordStateResource -uri $uri

Password
--------
exhales-SWxgB_r
# This seems to be my test policy (2)
PS C:\> $uri = "/api/generatepassword/?PasswordGeneratorID=2"
PS C:\> Get-PasswordStateResource -uri $uri

Password
--------
gainhovererAfJN1Cv$cEI9Pft3E4T*%L

But I haven't found a way to read the policies with the API.

The only thing that I think is easily achievable is, when using the "New-RandomPassword" function, providing the passwordlist (ID) to retrieve the default PwdPolicy for the list?

# Generate PWD with a policy ID
New-RandomPassword -PasswordGeneratorID ((Get-PasswordStateList 477).PasswordGeneratorID)

# Generate a new credential using the same "method", when there isn't a password provided
New-PasswordStatePassword -passwordlistID 477 -title 'Test_PWD' -username 'Test_User' -description 'Generated using the default password generator for the list with ID 477'
dnewsholme commented

I found the same thing before as there is no way to retrieve the password generator policies via the API it makes doing this more of a pain. I was thinking about maybe setting the defaults as a local thing instead.

colombeen commented

We could also do a feature request to extend the API with the required password policy information :-p

dnewsholme commented

I think that's probably the best approach. I'll raise a feature request and stick this in backlog for now.

colombeen commented

I've asked the support for info on this subject... this is what I got back:

In your API Scripts, if you add the ‘GeneratePassword = True’ value as per my below Powershell example, this will generate a password based on the Password generator Policy that is set on the password list. You don’t select a generator policy in the script per se, rather it just uses what you have already set in the system.

# Update an existing password using the Windows Authenticated API

# Set your Passwordstate URL in the below variable - example "https://passwordstate.contoso.com"
#$PasswordstateUrl = [PasswordstateUrl]
$PasswordstateUrl = "https://sandbox.halox.net"

# Define values for the Password List in below array
$Body = @{
  PasswordID       = "72313"
  GeneratePassword = 'true'       
}

# Convert Array to Json
$jsonData = $Body | ConvertTo-Json

# Execute the command
$FullUrl = "$PasswordstateUrl/winapi/passwords"
$result = Invoke-Restmethod -Method Put -Uri $FullUrl -ContentType "application/json; charset=utf-8" -Body $jsonData -UseDefaultCredentials

Maybe we can use this?

dnewsholme commented

Yes this would work for updating existing resources or creating new ones since you need to provide a list anyway, should be fairly quick and easy to implement.

As for just generating random passwords without creating an entry it would have to use the previous method.

colombeen commented

Any progress? I haven't been able to contribute myself in the last few days.

dnewsholme commented
dnewsholme commented

I've created a pull request #29 which implements the suggestion you made.

If you are happy with that too i'll close,merge and push the new build.

colombeen commented

It's a partial solution, just to bad that we still can't get a list of all pwd policies using the API, that would be the ideal solution.

dnewsholme commented

I'm going to close now and merge since it will be while if ever that the Passwordstate API gets the functionality.

  • 👍1