RDP session times out on the server i'm trying to connect to

Hi Simone,

The default certificates should work fine but the issue may be that the client or target server do not support TLS 1.2 which is the default setting in SPS in latest versions.

Please see the KB below:

https://support.oneidentity.com/kb/4315954/-ssl-handshake-failed-errors-in-rdp

Thanks!

Hi Tawfiq, i'm 100% sure that this is not the case since the target server can ONLY accept certificates with TLS 1.2 encription.

Hi Simone,

Does the target server have NLA enabled?

If you use Network Level Authentication (NLA, also called CredSSP), there is no verification performed in the TLS layer due to the TLS session-binding.

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

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

Thanks!

Hi Tawfiq, yes i just checked and the server has NLA enabled, should i disable it then? Or maybe should i join SPS to the Target domain?

Hi Simone,

If NLA is enabled on the target server then you should make sure that RDP settings have the matching setting below enabled:

Enable Network Level Authentication: Use this option to connect to NLA-enabled RDP servers with RDP 6 or later versions. NLA is the preferred option and considered more secure than the authentication provided by the Server logon screen option.

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

Thanks!

Hi Tawfiq, checked that option too and it is enabled on the RDP settings i'm using for the connection. There may be something else preventing the connection to succeed?

Hi Simone,

Is SPS joined to the domain? if not you can test after the joining SPS to the domain as well to see if any difference.

There is also another issue with SHA1 certificates are no longer accepted by SPS latest versions, please see the KB below for more details:

https://support.oneidentity.com/one-identity-safeguard-for-privileged-sessions/kb/4292503/certificates-with-sha1-signature-are-not-accepted-in-sps-6-10

Thanks!

Hi Tawfiq,

since i was using SPP initated workflow i decided to try connecting to the machine using only SPS, to see if it could really be a target problem.
I created a custom connection policy, not shared with SPP and without password injection. The connection is non-transparent and redirects me to the targetted server. During the test it worked all fine, and once i inputted the server credentials i could connect correctly to the server.
At this point the problem could only be in the way the SPP appliance handles credentials.
I can say that everytime i try connecting via SPP the login screen appears in asks for credential even if there's password injection.
I'm sure that the credentials i inserted manually in the vault are correct.
I even upgraded the appliance to the latest version (7.1).
Do you have any ideas on why the injection isn't successfull?

Thank you

Hi Simone,

Here few other items to check:

Do a Check Password on the account in SPP to make sure this is successful to validate the password saved in SPP is correct.

SPP and SPS are running matching version 7.1?

Client machine should also trust the certificate CA issued by SPS which you can download from SPS > Policies > Signing CA > expand safeguard_default and download the Safeguard CA certificate in DER format then install it on the Client machine under Trusted Root CAs

Thanks!

Hi Simone,

Here few other items to check:

Do a Check Password on the account in SPP to make sure this is successful to validate the password saved in SPP is correct.

SPP and SPS are running matching version 7.1?

Client machine should also trust the certificate CA issued by SPS which you can download from SPS > Policies > Signing CA > expand safeguard_default and download the Safeguard CA certificate in DER format then install it on the Client machine under Trusted Root CAs

Thanks!

Hello,

i've solved the problem by changing SNAT on the SPS Connection Policy. It seems that it was on "Use the original client IP" instead of "Use SPS Ip".