INFORMATION: Method to find out if account is checked in, working correctly?

[HerbM]

Thanks for the great library CyberArk API's are some of the worst junk I've seen so you are to be doubly admired and thanked for making so much sense of them.

Find out which accounts are locked, or failing management.

Looking at Get-PASAccount gives

• automaticManagementEnabled=True;
• status=success;

Is anything else available?

[pspete]

Hi @HerbM - thanks :-)

To find accounts which have password management issues you can use Get-PASAccount to search for MaxRetries:

> Get-PASAccount -search MaxRetries

Locked accounts currently cannot be searched for/enumerated . It likely does not help answering your question, but, a meaningful error message will be returned if an action is attempted against a account which is locked:

> Invoke-PASCPMOperation -id 29_3 -VerifyTask

Invoke-PASRestMethod : [400] Password is locked by another user.
At line:287 char:4
+             Invoke-PASRestMethod @ThisRequest
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: ({"ErrorCode":"P...another user."}:ErrorRecord) [Invoke-PASRestMethod], Exception
    + FullyQualifiedErrorId : PASWS143E,Invoke-PASRestMethod

[HerbM]

Thx PSPete,

To find accounts which have password management issues you can use Get-PASAccount to search for MaxRetries:

> Get-PASAccount -search MaxRetries

That should help.

And it taught me something else (I think): You can uses -search for more than just strings -- I have only been using it like "keywords".

It looks like I can still combine the above with -SafeName SomeSafe ## but I haven't proven this works yet.

Locked accounts currently cannot be searched for/enumerated .

Bummer, but thanks for confirming.

It likely does not help answering your question, but, a meaningful error message will be returned if an action is attempted against a account which is locked:

No, that helps a lot. Since by trying an action I can at least find out they are locked.

> Invoke-PASCPMOperation -id 29_3 -VerifyTask

Good. Does help -- a lot.

Invoke-PASRestMethod : [400] Password is locked by another user. At line:287 char:4

• Invoke-PASRestMethod @ThisRequest

• 
  + CategoryInfo          : NotSpecified: ({"ErrorCode":"P...another user."}:ErrorRecord) [Invoke-PASRestMethod], Exception
  + FullyQualifiedErrorId : PASWS143E,Invoke-PASRestMethod
  ```

So if you have it locked, it wouldnn't give an error since you can still do things to accounts you yourself have locked. Makes sense. Typed it out mostly to think it through.

I am finding "LastReconciledTime" in secretManagement which seems to help. The Web interface must be cheating by going direct to the database or through a programmatic API since it "knows" things we can't find.

Also, I am pretty sure the stupid web interface gives SOME time values in UTC and some in Local time -- without indication.

Again, I cannot really imagine how much time you must have spent working this out and over so many API versions.

THANK YOU

[HerbM]

Technically this was not a "feature requrest" but a request for info, though some of this might make it into a doc item or help page.

Thank you again for taking the time to answer so helpfully AND for all the time you must have spent working out the details.

[pspete]

I have only been using it like "keywords".

keywords is a parameter for the "Classic API" which only returns a single account (even if more matching results were found) - before version 10.4 there was no alternative other than this method. using the search parameter you can specify more than 1 search term. -SafeName SomeSafe will only return matching results from SomeSafe

More here: https://pspas.pspete.dev/commands/Get-PASAccount

Always happy to receive feedback - especially around anything currently lacking (like documentation) which would make the psPAS experience better 👍

[NathanielMaier]

using the search parameter you can specify more than 1 search term. -SafeName SomeSafe will only return matching results from SomeSafe

Does -SafeName need to be a full Safe Name, or could it be a partial name? I tested and it seems that it does need to be the full Safe Name when calling this with Get-PASAccount, but I know the advanced search function in the PVWA (classic UI) works with partial names.

[pspete]

Does -SafeName need to be a full Safe Name

SafeName was just added to the module in the psPAS 4.2.26 release, it is more of a convinience parameter: Behind the scenes, the string provided is having some formatting applied, and it is then provided to the api as the value for the filter parameter (the value being SafeName eq SomeSafe). This can be visible to you in the verbose output. The idea being the onus on a module user to provide the correctly formatted filter value of SafeName eq SomeSafe is removed. eq is the only documented relational operator available for the safename filter - assume eq means exactly equal....

Partial safe names can be provided against the search parameter.

E.G.:

>Get-PASAccount -search "SomeSafe SomeUser"

AccountID                 : 12_3
Safe                      : SomePrefix_SomeSafe
address                   : SOMEDOMAIN.COM
userName                  : SomeUser
name                      : Operating System-WinDomain-SOMEDOMAIN.COM-SomeUser
platformId                : WinDomain
secretType                : password
platformAccountProperties : @{LogonDomain=SOMEDOMAIN}
secretManagement          : @{automaticManagementEnabled=True; lastModifiedTime=1591375234}
createdTime               : 05/06/2020 15:40:34
categoryModificationTime  : 05/06/2020 15:40:35

>Get-PASAccount -safeName SomePrefix_SomeSafe -search SomeUser

AccountID                 : 12_3
Safe                      : SomePrefix_SomeSafe
address                   : SOMEDOMAIN.COM
userName                  : SomeUser
name                      : Operating System-WinDomain-SOMEDOMAIN.COM-SomeUser
platformId                : WinDomain
secretType                : password
platformAccountProperties : @{LogonDomain=SOMEDOMAIN}
secretManagement          : @{automaticManagementEnabled=True; lastModifiedTime=1591375234}
createdTime               : 05/06/2020 15:40:34
categoryModificationTime  : 05/06/2020 15:40:35

[NathanielMaier]

Thanks! Even with the PVWA UI, I run into situations where more accounts appear in search results than I'd want, because search terms may be present in other properties/File Categories - an easy example is linked accounts. Sure, I could disable those search fields in Options/PVConfiguration.xml, but that's global for everyone.

I'm sure this is more of an enhancement request for CyberArk at this point, but being able to have more granular search filters in the PVWA UI and REST API would be great. Until then, I'll continue Where-Object filtering afterwards.