Gateway Authentication failed

Hi Simone,

SPP initiated sessions should not require a gateway authentication at SPS side so there is likely a conflict issue with the connection policies, I would double check the Entitlement and Access Request Policy is using the correct SPS connection policy for RDP and SSH? Verify the priority order to make sure the correct entitlement was used for the request.

Are there other connection policies in SPS for RDP and SSH besides the SPP initiated ones that could be conflicting?

Here is the admin section on Configuring the Passwords-initiated workflow

https://support.oneidentity.com/technical-documents/one-identity-safeguard-for-privileged-sessions/7.0%20lts/administration-guide/118#TOPIC-1832013

You may engage PSO if you need further assistance with new configuration.

Thanks!

Hi Tawfiq,

I've double checked the Access Request Policyes and both of them are using the correct custom Connection policy. None of them has the "Require Gateway Authentication on the SPS Web Interface" turned on, so there should be none. As for Entitlements i only have 2, one for RDP sessions and one for SSH sessions; priority shouldn't be a problem.

I only have created 2 custom Connection policyes and deactivated the "Safeguard_default" ones. In the end i only have those 2 (one for RDP and one for SSH) connections active. I also tryed connecting by deactivating the 2 ones i created and using the dafault ones, but i still get the same error message.

Those 2 custom Connection policy are quite simple: non-trasparent connection to a single IP with inband destination selection.

And last i followed every step of the guide, but still the error appears

I forgot to mention that i'm using SPP adn SPS versions 7.0LTS.

I also noticed a thing when requesting the RDP session: if i launch it from SPP (i installed scalus on the machine), when the RDP tool opens i need to insert manually the IP address of SPS. Shouldn't in be pre-compiled?

Thank you

Hi Simone,

I would suggest to start over by deleting the RDP and SSH connection policies in SPS (both the custom and default ones), then delete the session appliance from SPP using the hard delete option from API as per the admin guide (Hard delete with Swagger) located here:

https://support.oneidentity.com/technical-documents/one-identity-safeguard-for-privileged-passwords/7.0%20lts/administration-guide/36#TOPIC-1820921

The re-join SPS to SPP and verify the entitlements \ ARPs are using the default connection policies then test to see if that helps before making any further custom changes.

Thanks!

Hi Tawfiq,

i have done the procedure you suggested but we still get the same error. The "https://<SPPAddressIP>:8649/service/SPSInteractive/v3/Plugin/Authentication" always returns the error code 60094. This time i made sure that even DNS is fine, and it is, it can resolve every FQDN. Port 8649 is open between the 2 appliances (i don't know if there should be any others). Now i'm using the "safeguard_default" and "safeguard_RDP" policyes.
I also tryed connecting through SPS only, and the SSH connection works fine once i input the credentials, unfortunately i can't say the same for the RDP connection. It gives back a black screen and never reaches teh server (even though the inputted credentials are correct).

Is there a way to check this "/SPSInteractive/v3/Plugin/Authentication"? Do you have any other ideas on which the problem could be?

Thank you!

Here is the KB on required ports between SPP and SPS:

https://support.oneidentity.com/one-identity-safeguard-for-privileged-passwords/kb/4251550/what-ports-are-required-for-communication-between-safeguard-cluster-members

Client workstation will also need access to RDP and SSH ports against the SPS appliances because after requesting a session the client connects via SPS to the target machine, for example:

RDP Session Request from SPP Web UI > RDP Client > SPS 3389 > Target Server 3389

SSH Session Request from SPP Web UI > SSH Client > SPS 22 > Target Server 22

SPS Local SSH Service should be changed to a different port for example 222 so that it does not conflict with SSH proxy using port 22

We recommend consulting with One Identity Professional Services if you need further assistance with configuration \ implementation. 

Hello,

the problem here was given by the autamtic NAT applied by the Firewall. Once it has been disabled everything started to work fine.