Hi Silvio

I think the key thing to remember here is that SPP and SPS are products that can stand up on their own without any need to interact with each other.

You cannot use SPS to proxy SPP functions.

If you are talking about using SPP to carry out password management functions then it needs to be able to see/communicate with the target system/assets. You can find details of the ports SPP needs to carry out management functions in the Admin guide. if it is just Linux/Unix passwords that need to be reset then you only need port 22 open from the SP cluster.

The SPP - SPS Join function allows you to create SPP originate sessions or SPS originate sessions.

SPP originated sessions allows you to authenticate to SPP and follow a workflow within SPP that allows you to request and start a session from SPP with SPP passing the details of the session to SPS without the need to interact directly with SPS.

SPS originate sessions allows you to create an SPS originated session and have SPP pass the credentials for the session to SPS from SPP.

Password reset after release is still handled by SPP.

I hope this helps

Best regards

Tim

Hi Tim, thank you so much for your information. I understand the different role for SPP and SPS, but we wanted to use SPP only as password Vault and ACL management console, demanding to SPS all the connections. 

Here the flow:

I access SPP, request ssh access to server, then SPP request SPS to connect, and recording session, using ad account linked in SPP that will not shared with users. At the moment changing password is not required. 

It would be possibile, if SPP do not reach SSH server, but only SPS does? Or it is better to design an architecture in which both SPP and SPS are connected to the target servers?

THX

Silvio

Hi Silvio

So it sounds like you are talking about using an SPP originated session.

As you do not want to reset password then SPP would not need to access the target system/asset.

In this case then you NEED to use the SPP - SPS Join function.

Once you have the "Join" configured and working you will need to enter the details for the target system (asset) and account into SPP. You will also need to define the various policies and entitlements needed for the user who authenticates to SPP to allow a session to be requested.

You should then be able to make a request in SPP and have the session started from SPS.

Now for you things get a little more difficult as you want to have SPS effectively proxy the session but also route it to another segment.

Have to admit I have never done this , I don't know how to do this and I do not know for sure if this is possible. Still learning SPS myself.. I would have to "play" or ask somebody who does know...

ANY SPS GURU's out there care to comment?

If I was going to investigate this I would start by getting the "Join" function working correctly.

I would be looking at the SPS configuration to make sure that the networking configuration and routing is working to allow the SPS to be able to access the DMZ. You can use the troubleshooting tools in SPS to ensure that SPS can connect to the relevant target in the DMZ.

Now the "Join" will create the SPS policy in SPP to allow a session to be started via SPP. I would then expect SPS to handle the routing of the session to the DMZ.

Your local SSH clinet would then connect to the front of the SPS proxy but the SPS will then male the connection to the back end.

Finally you have not mentioned if you are clustering the SPS appliances. If so and IF this is possible then you would potentially have to configure all cluster members to be able to route traffic to the DMZ target or create a second Join with a single SPS to allow this connectivity. The SPS cluster used its own "load Balancing" algorithm to decide which cluster member handled the session so if each cluster member cannot route the traffic you could have another problem here.

Sorry I cannot be more help.

Good luck

Tim

Hi Silvio

So it sounds like you are talking about using an SPP originated session.

As you do not want to reset password then SPP would not need to access the target system/asset.

In this case then you NEED to use the SPP - SPS Join function.

Once you have the "Join" configured and working you will need to enter the details for the target system (asset) and account into SPP. You will also need to define the various policies and entitlements needed for the user who authenticates to SPP to allow a session to be requested.

You should then be able to make a request in SPP and have the session started from SPS.

Now for you things get a little more difficult as you want to have SPS effectively proxy the session but also route it to another segment.

Have to admit I have never done this , I don't know how to do this and I do not know for sure if this is possible. Still learning SPS myself.. I would have to "play" or ask somebody who does know...

ANY SPS GURU's out there care to comment?

If I was going to investigate this I would start by getting the "Join" function working correctly.

I would be looking at the SPS configuration to make sure that the networking configuration and routing is working to allow the SPS to be able to access the DMZ. You can use the troubleshooting tools in SPS to ensure that SPS can connect to the relevant target in the DMZ.

Now the "Join" will create the SPS policy in SPP to allow a session to be started via SPP. I would then expect SPS to handle the routing of the session to the DMZ.

Your local SSH clinet would then connect to the front of the SPS proxy but the SPS will then male the connection to the back end.

Finally you have not mentioned if you are clustering the SPS appliances. If so and IF this is possible then you would potentially have to configure all cluster members to be able to route traffic to the DMZ target or create a second Join with a single SPS to allow this connectivity. The SPS cluster used its own "load Balancing" algorithm to decide which cluster member handled the session so if each cluster member cannot route the traffic you could have another problem here.

Sorry I cannot be more help.

Good luck

Tim

Tim, you are my saviour, by sure!

So far, we have configured SPS and verified by troubleshooting that can reach SSH server properly. 

We have created Asset, Entitilment and Access Request Policy, but we are freezed on SPP side, because we cannot discovery SSH host key (SPP cannot reach SSH Server) and if we try to request a SSH session, sps initiated or safeguard_default, the request cannot be performed becouse asset don't have SSH host key in SPP (and i want to use SPS to connect to it).

Furthermore, if i try to change adding a connection in SSH Control on SPS, under Connection, the new connection isn't be selectable and visible in Session Settings in SPP Access Request Policies, is there a delay to communicate the changes, or i have to perform some sync activity?

BR

Silvio

Hi Silvio

So have you joined SPS to SPP?

IF not then I think this is your next step.

Without Join you cannot start an SPP originated session/.

The join process will add the required policy to allow you to communications between SPP and SPS you do not need to create on yourself.

You need to enable SPS cluster even if you have only 1 SPS to be able to get the join to work.

IF you do already have the Join setup correctly see if you can start an SPP originate session to a local rather than DMZ resource.

Good luck

All the best

Tim.

Hi Tim, 

I have only 2 server: 1 SPS and 1 SPP, each of them is configurated as cluster, and inside SPS I can see under cluster management my SPS server with roles  Central management, Search local, and N/A for Last seen, Last updated and Configuration status but Status reports OK. I hope it's true ;).

Under Joined to SPP I see the IP of my SPP Server.

Inside SPP, inside Cluster Management i see only the SPP server, and the SPS is listed only under session appliances tabs.

I already have an RDP session (not SSH) originated from SPP that uses SPS IP address as target address, bur the real target is another server on SPS network.

Thank you for all

BR
Silvio

Hi Silvio

From an SPP point of view there is no difference in requesting an RDP to an SSH except the Access policy will be for SSH rather than RDP.

When you request the session via SPP the details of the target and the protocol to start the session will be passed to the SPS. This will then initiate the session.

You need to use the SPP thick client to be able to have a play/start button as for RDP. If you login via a browser session then you need to cut and paste the connection string into PuTTY  or similar.

If you an start an RDP session via SPP the Join is working.

If you have a local Linux/Unix machine you could try connecting to this. just to make sure that you have all the settings and configurations correct for both SPP/SPS and the target system.

You will at least know that issue is down to the DMZ and not the connection policy on SPS or an SPP configuration.

I have seen old encryption protocols cause issue connecting to some unix system so it would be good to check all is working first.

As I mentioned in an earlier post I am still learning SPS myself and I am afraid I am  running out of ideas of things to suggest so I think it is reaching the time where we both need one of the SPS guys to comment.

Good luck and if you do find a resolution please update this thread.

Best regards

TIm

Hi All, 

just another information, i've created an SSH target directly in DMZ (SPS) Network, but also that asset isn't reachable, for the same issue: No host key (90603). 

It seems to me that the only method to configure an SSH session is to connect directly SPP and Target. 

With RDP it is possible to use SPS as "bridge" to target, but the same thing seems not possibile for SSH connections, 

BR

SIlvio

Hi Silvio

Can you open port 22 between the SPP and your SSH target long enough to allow SPP to discover the key?

There is a KB 250836 that describes the error you are seeing.

I do not know for sure but I wonder if you allow SPP to discover the key for your asset if you could then create a session. via SPS.

I am thinking that if you can get the key into SPP you may then be able to start your session. Maybe SPS needs the key transferred to it as a part of the connection stream and because it cannot retrieve the key via SPS the process fails

 If this does work you could then turn off the port 22 between the SPP and your target in the DMZ.

Hopefully one of the SPS guys who know will jump in to clarify what is going on.

All the best

Tim

Hi Tim, finally i cound create a target server in SPP Network, and everithing works fine. Only I continue not to understand why it is necessary fro SPP to reach target: i verified the SSH connection, and it starts from SPS.

Probably, it is necessary the connection between SPP and Target for the password update activity, but in our case scenario, we would want only to use SPP as vault in order to not share password, but without changing it, and placing SPP in another network, using SPS as bridge. I think that it counldn't be possibile, but it is a good news that placing SPP in the same network, everithing works fine: Now we have to redesign our schema with these information.

Thx a lot for your efforts

BR

SIlvio