Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New-TSSSecretPermission unable to determine which SecretAccessRole to use #326

Open
wlodge-WM opened this issue Apr 18, 2023 · 11 comments
Open
Labels
bug Something isn't working triage needed new issues that are still in state of triage

Comments

@wlodge-WM
Copy link

wlodge-WM commented Apr 18, 2023

Verified issue does not already exist?

Yes

What error did you receive

C:\Program Files\WindowsPowerShell\Modules\thycotic.secretserver\0.60.9\parts\ProcessResponse.ps1 : {
"errorCode": "API_GenericException",
"message": "The server was unable to determine which SecretAccessRole to use. Please provide a valid
SecretAccessRoleName if using REST. Otherwise, make sure your request has a valid SecretAccessRoleID."
}
At C:\Program Files\WindowsPowerShell\Modules\thycotic.secretserver\0.60.9\functions\secret-permissions\New-TssSecretPe
rmission.ps1:101 char:41

  • ... $restResponse = . $ProcessResponse $apiResponse
  •                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    

Please run the command using -Verbose

VERBOSE: Command invocation: New-TssSecretPermission -TssSession:TssSessionObject -SecretId:System.Int32[]
-AccessRole:System.Int32[] -DomainName:pmmr.com -Username:PGarrison -Force:True -Verbose:True
VERBOSE: Command invocation: Search-TssSecret -TssSession:TssSessionObject
VERBOSE: Performing the operation GET
https://oct.secretservercloud.com/api/v1/secrets?sortBy[0].direction=asc&sortBy[0].name=Name&take=2147483647&filter.inc
ludeRestricted=true
VERBOSE: Performing the operation POST https://oct.secretservercloud.com/api/v1/secret-permissions with:
System.Collections.Specialized.OrderedDictionary
VERBOSE: Performing the operation "POST https://oct.secretservercloud.com/api/v1/secret-permissions with {
"SecretAccessRoleName": "Edit",
"SecretId": 123456,
"domainName": "domain.com",
"Username": "username"
}" on target "Secret ID: 123456".
C:\Program Files\WindowsPowerShell\Modules\thycotic.secretserver\0.60.9\parts\ProcessResponse.ps1 : {
"errorCode": "API_GenericException",
"message": "The server was unable to determine which SecretAccessRole to use. Please provide a valid
SecretAccessRoleName if using REST. Otherwise, make sure your request has a valid SecretAccessRoleID."
}
At C:\Program Files\WindowsPowerShell\Modules\thycotic.secretserver\0.60.9\functions\secret-permissions\New-TssSecretPe
rmission.ps1:101 char:41

  • ... $restResponse = . $ProcessResponse $apiResponse
  •                                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    

Provide a test case or steps to reproduce

$tsssession = New-TssSession -SecretServer $ssURL -Credential $cred -OtpCode 123456
$user = Search-TssUser -TssSession $tssSession -Field username -SearchText 'username'
#Note: AccessRole can be any of: List, View, Edit, Owner but the error message is the same
#Note: error message is also the same if adding permission for local user and removing the -DomainName parameter
New-TssSecretPermission -TssSession $tssSession -SecretId $secretID -AccessRole Edit -DomainName $user.DomainName -Username $user.Username -Force -verbose

Expected behavior

Expected behavior is that permissions inheritance is broken, if necessary, and a new permission entry is added to secret for the specified user.

What Edition of Secret Server?

Cloud Subscription

What version of Secret Server

EA release

What PowerShell host was used when producing this error

Windows PowerShell (powershell)

PowerShell Host Version

Name Value


PSVersion 5.1.19041.2673
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.2673
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

@wlodge-WM wlodge-WM added bug Something isn't working triage needed new issues that are still in state of triage labels Apr 18, 2023
@tylerezimmerman
Copy link
Contributor

We can investigate a more graceful way to handle this.

@wlodge-WM
Copy link
Author

FYI this still doesn't appear to work in the 0.61.1 version of the module, though the error seems different.
image

@tylerezimmerman
Copy link
Contributor

@wlodge-WM do you get the same error when using Powershell 7?

@wlodge-WM
Copy link
Author

@wlodge-WM do you get the same error when using Powershell 7?

The new comment I made as of 2 days ago has the updated error using PowerShell v7 and the 0.61.1 version of the module (latest).

@wlodge-WM
Copy link
Author

Tried this again with the 0.61.2 version of the module and the original error returned:
image

@tylerezimmerman
Copy link
Contributor

@wlodge-WM Apologies on the delay and thank you for your patience, we will be taking this for the 0.61.4 release.

@gaurava-delinea
Copy link

gaurava-delinea commented Jul 14, 2023

@wlodge-WM @tylerezimmerman
I am not able to reproduce this issue but not able to reproduce it
Tried the following scenarios:

1 Tried permission for the domain group - Success
2. Tried permission for the domain user - Success
image

  1. Tried permission for domain user with integer value of the access rule. - Success
    image

  2. Set the inherit permission flag on the Secrets Server folder - got the valid error
    image

  3. Run the command with force flag to bypass the inherit permission - Success
    image

Looks like there is some permission issue in your environment. Maybe you can try to set the same permission manually by logging in the secrete server with the same user which you are using to create the session object in PS module.

@wlodge-WM
Copy link
Author

Gaurav:

Thank you for the follow up. I updated to 0.61.3 on my system and still am receiving the same error. I have reached out to the Admins of our tenant to confirm permissions. I do know if I use the Web UI, I can adjust the permissions without error. The scripting is necessary for automation I am trying to build.
Thank you.

@ConagherL
Copy link

I can confimr I get the same error above when I execute the same command against a secret I have not touched. If I manually set the inheritance to no, then run the command. It works correctly. From there I also set the secret back to inherit permissions, and running the same command again works.

If I touch any new secret not previously manually edited I get the same error as the customer.

VERBOSE: Command invocation: New-TssSecretPermission -TssSession:TssSessionObject -SecretId:System.Int32[] -AccessRole:System.Int32[] -DomainName:jhjh.com -Username:aestrada -Force:True -Verbose:True VERBOSE: Command invocation: Search-TssSecret -TssSession:TssSessionObject VERBOSE: Performing the operation GET https://jjghj.secretservercloud.com/api/v1/secrets?sortBy[0].direction=asc&sortBy[0].name=Name&take=2147483647&filter.includeRestricted=true VERBOSE: Performing the operation POST https://jghjghjsecretservercloud.com/api/v1/secret-permissions with: System.Collections.Specialized.OrderedDictionary VERBOSE: Performing the operation "POST https://jghjghj.secretservercloud.com/api/v1/secret-permissions with { "SecretAccessRoleName": "Edit", "SecretId": 53005, "domainName": "ghgh.com", "Username": "aestrada" }" on target "Secret ID: 53005". ProcessResponse.ps1: C:\Users\CLepley.DELINEA\OneDrive - Delinea\Documents\PowerShell\Modules\Thycotic.SecretServer\0.61.3\functions\secret-permissions\New-TssSecretPermission.ps1:101:41 Line | 101 | … $restResponse = . $ProcessResponse $apiResponse | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | { "errorCode": "API_GenericException", "message": "The server was unable to determine which SecretAccessRole to use. Please provide a valid SecretAccessRoleName if using REST. Otherwise, make sure your request has a valid SecretAccessRoleID." }

@ConagherL
Copy link

Working in the same customer environment as wlogde and able to reproduce the error with FULL admin rights and Owner rights on the secret/folder.

@wlodge-WM
Copy link
Author

OK I’m not sure how this makes sense, but it looks like if you toggle the permissions inheritance, it works?
• Toggle permissions inheritance to false – Success
• Attempt to set permissions – Fail
• Toggle permissions inheritance to true – Success
• Toggle permissions inheritance to false – Success
• Set permissions – Success
image
Even more interesting is this seems to work in both versions of the module (0.61.3 and 0.60.9).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage needed new issues that are still in state of triage
Projects
None yet
Development

No branches or pull requests

4 participants