Public key-based gateway + password-based server-side authentication from credential store
This scenario differs from the previous one only in the client-side authentication method. In this case, the end-user is authenticated with the public key method, and if all permissions are granted by SPS (for example usermapping is allowed), they get logged in automatically to the requested server with the requested server account without having to enter a password.
To configure this, upload a public key for the user in the applied local user database, and make sure that the private key is accessible for the client application (openSSH, PuTTY, and so on).
To configure public key-based gateway + password-based server-side authentication from credential store
-
Create a local user database:
Navigate to Policies > Local User Databases and create a local user database.
For details, see Creating a Local User Database.
-
Connect the local user database with a client-side gateway authentication policy:
Navigate to SSH Control > Authentication Policies. Create an authentication policy. Select Authenticate the client to SPS using > Local. Select Public key. Configure the required settings.
For details, see Local client-side authentication.
-
Create a user list:
Navigate to Policies > User lists and create a user list.
For details, see Creating and editing user lists.
-
Create a usermapping policy:
Navigate to Policies > Usermapping policies and create a usermapping policy.
For details, see Configuring usermapping policies.
-
Create a local or remote credential store with the server user and its password. SPS provides a plugin framework to integrate with other remote credential stores/password management systems.
For details, see Using a custom Credential Store plugin to authenticate on the target hosts.
-
Expected outcome:
If all prerequisites are met, SPS is ready to perform inband gateway authentication in an SSH session, which together with inband destination selection could be performed with the following connection string by an end-user:
Example: Inband gateway authentication and destination selection
$ ssh gu=balabit@root@192.168.56.10@192.168.56.200
-
gu=balabit = gateway user (balabit)
-
root = server user
-
192.168.56.10 = target server
-
192.168.56.200 = IP address of SPS
-
Configuring an advanced channel policy for SSH
The channel policy lists the channels (for example, terminal session and SCP in SSH) that can be used in the connection, and also determines if the channel is audited or not. The Channel policy can also restrict access to each channel based on the IP address of the client or the server, a user list, user group, or a time policy. For example, all clients may access the servers defined in a connection through SSH terminal, but the channel policy may restrict SCP access only to a single client. The rules defined in the channel policy are checked when the user attempts to open a particular channel type in the connection.
The order of the rules matters. The first matching rule will be applied to the connection. Also, note that you can add the same channel type more than once, to fine-tune the policy. This can be helpful in the following cases:
-
Four eyes authorization is required only for certain target user groups (Administrator/root)
-
Group-based auditing: only certain user groups are audited
-
Remote access to a certain server is only allowed during non-business hours for example to ensure that work is not interrupted because of system maintenance.
Based on the environment of the customer, such requirements could probably also be solved by creating multiple channel policies, hence having multiple-connection policies in place. But because connection policies are selected by only matching IP addresses and destination ports, especially group-based decisions cannot be solved at this stage. The third example can definitely be solved by a separate connection policy having a special channel policy assigned. But if this is the only difference to another connection policy, solving the issue by an additional rule in the channel policy is much faster and keeps a clean ruleset.
For details, see Creating and editing channel policies.
To configure an advanced channel policy for SSH
-
Navigate to SSH Control > Channel Policies and click
to create a new channel policy. Enter a name for the policy.
-
Click
-
Select the channel to be enabled in the connection from the Type field.
-
To restrict the availability of the channel only to certain clients, click
-
To restrict the availability of the channel only to certain servers, click
-
To restrict the availability of the channel when using gateway authentication, click
-
To restrict the availability of the channel only to certain users, click
-
Select a Time policy to narrow the availability of the channel.
-
Decide which actions to trigger if the parameters configured above match:
Select the 4 eyes option to require four-eyes authorization to access the channel.
Select the Record audit trail option to record the activities of the channel into audit trails.
-
Click
.
Group-based auditing
It is sometimes a requirement to record connections of certain users only. If those uses cannot be identified by layer 3/4 connection parameters, this issue is not solved by creating separate connection policies with each having assigned a specific channel policy with auditing enabled/disabled.
To solve this issue, configure the group(s) that are affected by the channel settings:
Figure 9: Group-based auditing
In this scenario, only users of gateway groups gr_supplier-A and gr_supplier-C are audited when requesting a new SSH session shell channel. If these two groups are not matched, the second rule matches and no recording is triggered. Without the second rule, users that do not match the specified groups would be denied by this channel policy.
Integration with ticketing systems
SPS provides a plugin framework to integrate SPS to external ticketing (or issue tracking) systems, allowing you to request a ticket ID from the user before authenticating on the target server. That way, SPS can verify that the user has a valid reason to access the server — and optionally terminate the connection if they do not.
Currently the following protocols are supported:
-
Remote Desktop (RDP)
-
Secure Shell (SSH)
-
Telnet
-
TN3270
The following is an example of a gateway authentication process with ticketing integration in PuTTY
Figure 10: Authentication with ticketing integration in PuTTY
For details, see Integrating ticketing systems.