pspete / psPAS

PowerShell module for CyberArk Privileged Access Security REST API
https://pspas.pspete.dev
MIT License
293 stars 91 forks source link

Unable to Set PASAccount for automaticManagementEnabled = $True #217

Closed fl0riandre closed 4 years ago

fl0riandre commented 4 years ago

Describe the issue A concise summary of the issue

To Reproduce Steps to reproduce the behavior:

set-pasaccount -accountid xxx_x -op replace -path /secretmanagement/automaticManagementEnabled -value $true

Expected behavior need to edit properties of account accordingly (set value to $false is working)

Screenshots & Console Output If applicable, add screenshots to help explain your problem.

Console Output Code Block:


Invoke-PASRestMethod : [500] Object reference not set to an instance of an object.
At line:359 char:14
+ ...   $Result = Invoke-PASRestMethod -Uri $URI -Method $Method -Body $Bod ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: ({"ErrorCode":"C...of an object."}:ErrorRecord) [Invoke-PASRestMethod], Exception
    + FullyQualifiedErrorId : CAWS00001E,Invoke-PASRestMethod

Your Environment Include relevant details about your environment

Additional context Add any other context about the problem here.

Zombiedraxx commented 4 years ago

I'm getting this same issue.

Get-PASAccount -search xxxxxxx | Set-PASAccount -op replace -path /secretmanagement/automaticManagementEnabled -value $true

Invoke-PASRestMethod : [500] Object reference not set to an instance of an object. At line:363 char:14

Zombiedraxx commented 4 years ago

Same result with Set-PASAccount -AccountID 5062_3 -op replace -path /secretmanagement/automaticManagementEnabled -value true

This gives the same result: Set-PASAccount -AccountID 5062_3 -op replace -path /secretmanagement/automaticManagementEnabled -value $true

Invoke-PASRestMethod : [500] Object reference not set to an instance of an object. At line:363 char:14

pspete commented 4 years ago

It appears you have to clear the manual management reason at the same time:

$ops = @(
    @{
        "path" = "/secretManagement/automaticManagementEnabled"
        "op" = "replace"
        "value" = $true
    },
    @{
        "path" = "/secretManagement/manualManagementReason"
        "op" = "replace"
        "value" = ""
    }
)
PS>Set-PASAccount -AccountID 330_4 -operations $ops
Zombiedraxx commented 4 years ago

I can confirm the following worked for me:

$ops = @( @{ "path" = "/secretManagement/automaticManagementEnabled" "op" = "replace" "value" = $true }, @{ "path" = "/secretManagement/manualManagementReason" "op" = "replace" "value" = "" } ) Get-PASAccount -search XXXXX | Set-PASAccount -operations $ops

pspete commented 4 years ago

New Functions Enable-PASCPMAutoManagement & Disable-PASCPMAutoManagement now present in version 3.3.88 on the master branch & published to the PowerShell Gallery.

@fl0riandre - closing this now, please comment if you feel it should be reopened.

FIMTooler commented 4 years ago

If you are trying to enable an account that has been disabled by the CPM such as for reaching maximum retries, this will not work as intended.

The account will be enabled and then immediately disabled because the retries count isn't reset. I did find out that if you add RetriesCount as an optional property on the platform, you can then include it in the update along with the the other 2 properties with a value of 0.

This essentially makes it function much more like the Resume button in the PVWA.

pspete commented 4 years ago

@FIMTooler - for accounts disabled by CPM which have reached MaxValue for RetriesCount, initiating a CPM Operation on the account will clear those file categories automatically. The following psPAS commands can be used to achieve this:

Invoke-PASCPMOperation -ChangeTask -AccountId 123_4
#or
Invoke-PASCPMOperation -ReconcileTask -AccountId 123_4

The Enable-PASCPMAutoManagement & Disable-PASCPMAutoManagement commands allow user control of the "automatic password management" status as intended.

FIMTooler commented 4 years ago

That makes sense and is easier than adding properties to one or more platforms for most cases. It's not as intuitive as thinking enabling the account in this situation should use the enable command.

In my particular situation, the account needing enabled is part of an account group that is very sensitive. Triggering an action to change all of the passwords without notice and communication causes major problems. With a hundred plus accounts in the group, triggering a verify to enable one account would work, but is kind of overkill.

I'm not worried either way if you update the command or not, but maybe someone else will find this if searching the web for a solution to enabling an account that immediately gets disabled again.

Finding this thread about also being required to reset the manualManagementReason helped me a lot with my own script this week as I kept getting failures sending only one of the two required properties.