Closed jasonwbarnett closed 4 years ago
Hi @jasonwbarnett - thanks for the report, let me look into it
Very astute @jasonwbarnett; an excellent issue report. An initial fix for the reported behaviour has been developed, example output below...
PS > $Member = Get-PASSafeMember -SafeName ABC -MemberName XYZ
PS > $Member.Permissions
UseAccounts : False
RetrieveAccounts : True
ListAccounts : True
AddAccounts : False
UpdateAccountContent : False
UpdateAccountProperties : False
InitiateCPMAccountManagementOperations : False
SpecifyNextAccountContent : False
RenameAccounts : False
DeleteAccounts : False
UnlockAccounts : False
ManageSafe : False
ManageSafeMembers : False
BackupSafe : False
ViewAuditLog : True
ViewSafeMembers : True
AccessWithoutConfirmation : False
CreateFolders : False
DeleteFolders : False
MoveAccountsAndFolders : False
RequestsAuthorizationLevel : 1
PS > $Member.Permissions.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True False PSCustomObject System.Object
PS > $Member.Permissions.RequestsAuthorizationLevel
1
To maintain consistency, the output of the function when querying all safe member permissions has been updated also:
PS > $Member = Get-PASSafeMember -SafeName ABC
PS > $Members[0].Permissions
Add : True
AddRenameFolder : True
BackupSafe : True
Delete : True
DeleteFolder : True
ListContent : True
ManageSafe : True
ManageSafeMembers : True
MoveFilesAndFolders : True
Rename : True
RestrictedRetrieve : True
Retrieve : True
Unlock : True
Update : True
UpdateMetadata : True
ValidateSafeContent : True
ViewAudit : True
ViewMembers : True
PS > $Members[0].Permissions.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True False PSCustomObject System.Object
PS > $Members[0].Permissions.ViewMembers
True
As this will be a breaking change, it may take a little while to get the fix released (some other updates are in progress too). Would be great to get feedback once the update is published to the dev branch - will tag any related updates with this issue.
This is fantastic. Thanks for quickly turning this around. What you have looks good to me.
What if you added a flag (i.e. -AsHashtable
) to the function in the short-term so you don't break the existing API? Then you could introduce a warning into the code base at some point in the future and then outright deprecate the old array response eventually.
Get-PASSafeMember -SafeName ABC -MemberName XYZ -AsHashtable
Add-PASSafeMember
& Set-PASSafeMember
both require the fix for this too.
Changes now present in the dev
branch and will be part of the next module release.
Describe the issue
The
Get-PASSafeMember
function returns theRequestsAuthorizationLevel
property when-MemberName
is provided, but it only returns the property name and not it's value.See: https://github.com/pspete/psPAS/blob/master/psPAS/Functions/SafeMembers/Get-PASSafeMember.ps1#L159-L163
This code assumes that all property values are a boolean but
RequestsAuthorizationLevel
is an integer.To Reproduce
Expected behavior
I would expect to be able to get the
RequestsAuthorizationLevel
(i.e.0
,1
, or2
)Your Environment
P.S. What a nice hack using an empty POST request to retrieve this otherwise missing value. I'll be filing a bug report to CyberArk to get them to add
RequestsAuthorizationLevel
to theGET /WebServices/PIMServices.svc/Safes/{SafeName}/Members
API endpoint.