pspete / psPAS

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

ISPSS New-PASSession returns a session but none of the cmdlets work #465

Closed walidhammad closed 1 year ago

walidhammad commented 1 year ago

Describe the issue While the new module update to include ISPSS seems to connect, I cannot access any of the cmdlets results.

To Reproduce Installing the module Connecting to ISPSS using service account Running cmdlets

Expected behavior I expect to be able to get results for any of the cmdlets of this module.


$ get-module pspas -ListAvailable

$ install-module pspas -RequiredVersion 5.5.110

$ get-module pspas -ListAvailable

    Directory: xxxxxxx

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     5.5.110               psPAS                               Desk      {New-PASSession, Close-PASSession, Add-PASPublicSSHKey, Get-PASPublicSSHKey…}

$ $pcloudlogin = Get-Credential -UserName xxxxx@xxxxxxxxx

PowerShell credential request
Enter your credentials.
Password for user xxxxx@xxxxxxxxx: ****************************************

$ New-PASSession -TenantSubdomain xxxxxxx -Credential $pcloudlogin -Verbose
VERBOSE: Performing the operation "Logon" on target "https://xxxxxxx.id.cyberark.cloud/oauth2/platformtoken".
VERBOSE: HTTP/1.1 POST with 141-byte payload
VERBOSE: received 2120-byte response of content type application/json
VERBOSE: HTTP/1.1 GET with 0-byte payload

$ Get-PASSession

User BaseURI                                                     ExternalVersion WebSession
---- -------                                                     --------------- ----------
     https://xxxxxxx.privilegecloud.cyberark.cloud/PasswordVault 0.0             Microsoft.PowerShell.Commands.WebRequestSession

$ Get-PASServer
Invoke-PASRestMethod:
Line |
  14 |  …   $result = Invoke-PASRestMethod -Uri $URI -Method GET -WebSession $S …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | No such host is known.

$ Get-PASLoggedOnUser
Invoke-PASRestMethod:
Line |
  16 |  …   $result = Invoke-PASRestMethod -Uri $URI -Method GET -WebSession $S …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | No such host is known.

$ Get-PASSafe
Invoke-PASRestMethod:
Line |
 230 |  …   $result = Invoke-PASRestMethod -Uri $URI -Method GET -WebSession $S …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | No such host is known.

$ Get-PASComponentSummary
Invoke-PASRestMethod:
Line |
  18 |  …   $result = Invoke-PASRestMethod -Uri $URI -Method GET -WebSession $S …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | No such host is known.

$ Get-PASAccount
Invoke-PASRestMethod:
Line |
 197 |  …   $result = Invoke-PASRestMethod -Uri $URI -Method GET -WebSession $S …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | No such host is known.

Your Environment Windows: Name Value


PSVersion 7.3.3 PSEdition Core GitCommitId 7.3.3 OS Microsoft Windows 10.0.22621 Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0

Mac: Name Value


PSVersion 7.3.3 PSEdition Core GitCommitId 7.3.3 OS Darwin 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T60… Platform Unix PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0

Additional context Add any other context about the problem here.

walidhammad commented 1 year ago

I can still connect with older module + issue#402 work around and do everything I need

$ Get-PASSession

User                     BaseURI                                                       ExternalVersion WebSession
----                     -------                                                       --------------- ----------
xxxxx@xxxxxxxxx https://xxxxxxxx.privilegecloud.cyberark.cloud/PasswordVault 13.0.0          Microsoft.PowerShell.Commands.WebRequestSession

$ Get-PASServer 

ExternalVersion InternalVersion ServerName
--------------- --------------- ----------
13.0.0          13.0.0.9        Vault

$ Get-PASLoggedOnUser

AgentUser    : False
Disabled     : False
Email        : 
Expired      : False
ExpiryDate   : 
FirstName    : Privilege
LastName     : user
Location     : \
Source       : Internal
Suspended    : False
UserName     : xxxxx@xxxxxxxxx
UserTypeName : EPVUser
pspete commented 1 year ago

It would be expected for both a username & the version information to be included in the get-passession output...

If the "WebSession" object is examined, does it include a bearer token?

PS C:\Users\petem> Get-PASSession | Select -ExpandProperty WebSession | select -ExpandProperty Headers

Key           Value                                                                                                                                                                                                    
---           -----                                                                                                                                                                                                    
Authorization Bearer SomeLongStringSomeLongStringSomeLongStringSomeLongStringSomeLongString...
walidhammad commented 1 year ago

Yes

Get-PASSession | Select -ExpandProperty WebSession | select -ExpandProperty Headers

Key           Value
---           -----
Authorization Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjRBOTJBRkUxRjIxMkZCQTJEN0M2MDg4NjE3N0ZGRTMxNEZCMkE1QTgiLCJ4NXQiOiJTcEt2NGZJUy…
pspete commented 1 year ago

is the https://xxxxxxx.privilegecloud.cyberark.cloud/PasswordVault value from Get-PASSession as expected?

does it match the value you see when using the issue #402 workaround?

pspete commented 1 year ago

Yes

Get-PASSession | Select -ExpandProperty WebSession | select -ExpandProperty Headers

Key           Value
---           -----
Authorization Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjRBOTJBRkUxRjIxMkZCQTJEN0M2MDg4NjE3N0ZGRTMxNEZCMkE1QTgiLCJ4NXQiOiJTcEt2NGZJUy…

Can you see if the Bearer token is able to be used outside of the module? Like described here: https://github.com/pspete/psPAS/issues/464#issuecomment-1494864685

walidhammad commented 1 year ago

is the https://xxxxxxx.privilegecloud.cyberark.cloud/PasswordVault value from Get-PASSession as expected?

does it match the value you see when using the issue #402 workaround?

No, the xxxxxxx returned is the identity tenant, which is in https://xxxxxxx.id.cyberark.cloud/oauth2/platformtoken instead of the privilege cloud pvwa name https://xyz.privilegecloud.cyberark.cloud/PasswordVault

walidhammad commented 1 year ago

Yes

Get-PASSession | Select -ExpandProperty WebSession | select -ExpandProperty Headers

Key           Value
---           -----
Authorization Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjRBOTJBRkUxRjIxMkZCQTJEN0M2MDg4NjE3N0ZGRTMxNEZCMkE1QTgiLCJ4NXQiOiJTcEt2NGZJUy…

Can you see if the Bearer token is able to be used outside of the module? Like described here: #464 (comment)

I can by replacing baseurl with https://xyz.privilegecloud.cyberark.cloud/PasswordVault instead of https://xxxxxxx.privilegecloud.cyberark.cloud/PasswordVault and it returns users.

pspete commented 1 year ago

OK, so your scenario is that the Identity & Privilege Cloud subtenant names are different? Will investigate how to cater for this.

bab29 commented 1 year ago

@pspete The URL that is used for "Identity" (Authentication, user updates, etc) operations will always go to a URL that uses "????.my.idaptive.app" (???? Assigned by CyberArk) while any operation that goes to a "PCloud" (Accounts, Safes, Ownership, etc) will go to the "{subdomain}.id.cyberark.cloud" (Subdomain chosen by the tenant)

This line is using a incorrect URL New-PASSession.ps1 $LogonRequest['Uri'] = "https://${TenantSubdomain}.id.cyberark.cloud/oauth2/platformtoken"

This line needs to be updated to use the "Identity" tenant then the code should work.

Suggestion:

New-PASSession.ps1 [Parameter(Mandatory = $true, ValueFromPipeline = $false, ValueFromPipelinebyPropertyName = $true, ParameterSetName = 'SharedServices')] [string]$IdentityID,

$LogonRequest['Uri'] = "https://${IdentityID}.id.cyberark.cloud/oauth2/platformtoken"

Note that $Uri being set is correct and should use the TenantSubdomain, it is just the oauth token request that needs to go to the "Identity" Uri

New-PASSession.ps1 $Uri = "https://${TenantSubdomain}.privilegecloud.cyberark.cloud/$PVWAAppName"

pspete commented 1 year ago

1st generation URLs (like ????.my.idaptive.app) are not yet catered for in the module, we currently assume the URL for current day systems. {subdomain} can be configured as a tenant URL for the Identity portal, which should allow authentication to proceed.

Nevertheless, will work to add some additional logic into the module to cater for different configurations.

pspete commented 1 year ago

It si expected that most Shared Services implementations will be configured so that Identity and Privileged Cloud portal addresses share a common subdomain.

Where this is not the case, and Identity and Privilege Cloud portals do not share an identical subdomain, in the latest psPAS release 5.6.135, subdomain values or portal URL values can be specified independently: https://pspas.pspete.dev/docs/authentication/#shared-services-authentication

walidhammad commented 1 year ago

1st generation URLs (like ????.my.idaptive.app) are not yet catered for in the module, we currently assume the URL for current day systems. {subdomain} can be configured as a tenant URL for the Identity portal, which should allow authentication to proceed.

Nevertheless, will work to add some additional logic into the module to cater for different configurations.

Thank you! The last release works by giving me the options to specify identitysubdomain and tenantsubdomain.

The reason we cannot have them be the same is due to it being Identity Security Platform tenant which makes identitysubdomain a pre generated string

CleanShot 2023-08-13 at 15 34 41@2x
pspete commented 1 year ago

Great it works for you. I Don't think a custom domain/ vanity URL is the same thing as a Tenant subdomain.

The process for adding a custom domain is a lot more involved than adding a subdomain.

walidhammad commented 1 year ago

I Don't think a custom domain/ vanity URL is the same thing as a Tenant subdomain.

It is

https://docs.cyberark.com/Idaptive/Latest/en/Content/GetStarted/CustomDomain.htm

CleanShot 2023-08-14 at 06 11 42@2x