SPS connection policies

Hi,

When you join SPP and SPS, the SSH connection policy (safeguard_default) is auto generated and used by default for SSH sessions on port 22

SPS checks connection policies from top in order and so if the first connection policy matches then it wins the session and no other connection policies will be used if assigned the same port.

Therefore, it would not be possible to use two SPS connection policies with the same port as only the first one would win always.

Not clear on the use-case you are looking to implement with two connection policies for SSH sessions but i would suggest consulting with PSO team on new configurations for a solution based on what you are looking to accomplish.

Thanks!

Hello Tawfiq,

Let me try to explain better my use case:

- as we joint SPP and SPS, the "safeguard_default" connection was automatically created and, as we decided to use the SPP-initiated workflow, in the ARP on the SPP the SPS connection policy chosen is always the "safeguard_default"

- I configured a new connection policy under SSH control on the SPS because I needed to test same features (channel policy and content policy in detail) 

Now, if I try to make a new request toward a target, even though the first connection under SSH control is the new one, it always selects the safeguard_default so I am not able to test these features. I was wondering if in this case I should change the SPP connection policy (as it stands now it does not seem to be possible because in the drop down menu I only see safeguard_default and SPS initiated workflow) or in which way I can simultaneously use two different SPS ssh connections.

Thank you!

Hello Tawfiq,

Let me try to explain better my use case:

- as we joint SPP and SPS, the "safeguard_default" connection was automatically created and, as we decided to use the SPP-initiated workflow, in the ARP on the SPP the SPS connection policy chosen is always the "safeguard_default"

- I configured a new connection policy under SSH control on the SPS because I needed to test same features (channel policy and content policy in detail) 

Now, if I try to make a new request toward a target, even though the first connection under SSH control is the new one, it always selects the safeguard_default so I am not able to test these features. I was wondering if in this case I should change the SPP connection policy (as it stands now it does not seem to be possible because in the drop down menu I only see safeguard_default and SPS initiated workflow) or in which way I can simultaneously use two different SPS ssh connections.

Thank you!

If the purpose of this is to test a different channel rule with a content policy then it may be easier to keep the same default SSH connection policy then inside of the Channel Policy add a new channel rule > select "Session Shell" and select the Content policy you wish to test and specify a target server either by IP address or Hostname then this rule to be the top of the Channel Policy.

In this case you would have the default channel policy "safeguard_default" but inside of it there are two Session Shell channel rules:

1. first session shell rule which has the content policy selected and the target server that will be applicable for this content policy

2. second session shell rule which is the original one and does *not* have any content policy or target listed.

This way if the session is going to the target server in the top channel rule then the content policy is applied

If the session is pointed to a different target then the second channel rule applies and no content policy is applied.

hope this helps?

Thanks!

Dear Tawfiq,

I am working with an integrated SPP and SPS environment. My goal is to apply a specific content policy based on the username initiating the session, rather than by source or destination IP addresses.

Currently, I have tried adjusting the connection policy selection through SPP > Entitlement > Access Policy > Security.

However, during SPP-initiated sessions, SPS always selects the connection policy based on the order from above, This results in the content policy being enforced by IP criteria, not by the username.

Is there any supported method or best practice to enforce content policies in SPS per username (or user group) for SPP-initiated sessions, rather than by source/destination IP? 

Thank you for your assistance.

Hi Mahmoud,

Yes you can accomplish this using the same safeguard_default Channel policy that is selected by default for SPP initiated workflow, but need to modify it as below:

You would add a new channel rule (inside the same safeguard_default channel policy) that will include the content policy - for example, if this is for RDP, you can add a new Drawing channel rule which includes the content policy AND for this new Drawing channel rule, you would specify a Group which the user belongs to in either:

Gateway group field (if you want to match against the Username logged into SPP which is considered the GW user by SPS)

or

Remote Group field (if you want to match against the username of the account logging into the target server which is considered as the Remote user by SPS)

Then place this new Drawing channel rule to the top of the Channel rules list inside of the safeguard_default channel policy.

- The result is there will be two Drawing channels in the same Channel Policy (safeguard_default)

First Drawing channel with a Content policy selected AND either a GW group or Remote Group defined depending on which username you are looking to match.

Second Drawing channel without any Content policy and No groups defined

-------------

if first rule is restrictive and:

- the user belongs to a defined restricted group then this would be the first match and therefore this rule will take precedence and apply to the connection.

- the user does *not* belong to the restricted group then the next rule with the same channel type will be checked further until a match is applicable.

if first rule is non-restrictive (No group defined) and therefore matches all users then it will win and no check will be made on remaining rules of the same channel type.

 -------------

Thanks!