Set-PASUser ExpiryDate

[JohnnyLeuthard]

Describe the issue If I run a get-PASUser and pipe it to Set-PASUser like this Get-PASUser -id 123 | Set-PASUser - enabled $false I get n error "Cannot process argument transformation on parameter 'expirydate'. Cannot convert value "-62135575200" to "system.DateTime". Error: "Ticks must be between DateTime.MinValue.Ticks and DateTime.MaxValue.Ticks/ parameter name: ticks"

To Reproduce Steps to reproduce the behavior:

1. Create a user
2. In PrivateArk set an expiration date
3. Remove expiration date
4. run this command... Get-PASUser -id 123 | Set-PASUser - enabled $false

Expected behavior The user defined in the Get-PASUser gets disabled. This can be any action just setting or changing a value

Screenshots & Console Output Can't get those since I have to log this issue from my personal PC and policy at work will not allow me to transfer data to and from my controlled laptop.

Your Environment Include relevant details about your environment

• PowerShell Version: 5.1
• psPAS Version: I forget where to find this but it is within the last 6 months?
• CyberArk Version: 11.5.4

Additional context This worked at one point. My guess is that it happened because I enabled an expiration date and then removed it and not it is passing that across the pipeline. OR if I just provide whatever the value is to tell it to disable that setting?

[pspete]

Thanks for the report @JohnnyLeuthard ... Will look into it

[JohnnyLeuthard]

Just an FYI, I can just do a set-pasuser and it works BUT it removes all other attributes. Thats why I was using get-pasuser so it passes the additional attributes across the pipeline so they don't get removed. I'm thinking the field has a value since the expiration date was added and removed and that set a weird value where before it may have been null so it wasn't accepting it from pipeline by value?

OR I can use the command I am getting an error with and put a date in it also works but again I don't want it to expire. I did think maybe just add a date 20 years in the future but it gave me an error it was to big a value. I think because it it an int vse int32 or something larger?

[pspete]

Consider using the gen2 parameters instead of gen1.

https://pspas.pspete.dev/commands/Set-PASAccount#gen2singleop-default

[JohnnyLeuthard]

I'd still need to get all the values currently assigned to the user ID to put in a hashtable correct? if I don't supply them it will remove any not assigned right? I like being able to get the user with get-pasuser so I know I'm getting everything and passing that off to the next command vs having to get the user, and process that info and pass that across to the set command.

[pspete]

10.4 + uses the PATCH method instead of PUT. Only the legacy PUT based requests require all properties to be specified. https://pspas.pspete.dev/commands/Set-PASAccount#description

10.4+ supports update of individual properties

[pspete]

@JohnnyLeuthard - apologies, ignore previous comments - they relate to Set-PASAccount, not Set-PASUser.

[pspete]

First fix just stops Set-PASUser accepting pipeline input for the expirydate parameter. Currently present on the issue-363 branch and in build 5.1.24

[JohnnyLeuthard]

I pulled down the updated set-pasuser and replaced the one on my test system and ran the same commands I was before and it no longer gives the error and passes all the settings so they don't get removed. It's working as expected now.

Thanks