Configuring inband destination selection
With inband destination selection, you can create a single connection policy and allow users to access any server by including the name of the target server in their username (for example, ssh username@targetserver@scb_address, or username%@targetserver%scb_address). If you do not specify the username or the address in nontransparent SSH and Telnet connections, One Identity Safeguard for Privileged Sessions (SPS) displays a terminal prompt where the user can enter the username and the server address.
To configure a Connection Policy to extract the address of the server from the username
-
Navigate to the Connection policy you want to modify, for example, to SSH Control > Connections.
-
Select Inband destination selection.
Figure 170: <Protocol name> Control > Connections — Configuring inband destination selection
-
Optional Step: Enter the IP address or the hostname of the domain name server used to resolve the address of the target server into the DNS Server field.
If you do not set the DNS Server field, SPS will use the global DNS server (set on the Basic Settings > Networking page) to resolve the hostnames in this connection.
-
Optional Step: Configure domain names and CNAME records.
If the clients do not include the domain name when addressing the server (for example they use username@server instead of username@server.example.com, or username%server for RDP connections), SPS can automatically add domain information (for example, example.com). Enter the domain name to add into the Append domain field.
SPS can also resolve CNAME records.
To enter more domain names (for example, because connections extend through subnets), click 
. In case of more domain names in the Append domain field, SPS appends the first domain name in the list that the target can be resolved with.
-
Enter the addresses of the servers that the users are permitted to access into the Targets field. Note the following points:
-
Use the IP address/prefix (for example 192.168.2.16/32, or 10.10.0.0/16) format. Alternatively, you can use the FQDN of the server. To permit access to any server, enter *.
-
For FQDN, you can use the * and ? wildcard characters.
|
|
Caution:
If only the hostname of the server is listed and the client targets the server using its IP address, SPS refuses the connection. |
|
|
Caution:
When the client uses hostname in inband destination selections, the hostname must comply with RFC5890: Internationalized Domain Names for Applications (IDNA). For example, from the ASCII characters only letters, digits, and the hyphen character is permitted.
Starting with version 6.1.0, SPS rejects connection requests where the hostname does not comply with RFC5890. |
-
If the clients target the server using its IP address, include the IP address of the server in the Targets > Domain list. This is required because SPS resolves the hostnames to IP addresses, but does not reverse-resolve IP addresses to hostnames.
-
If the clients target the server using its hostname, then the hostname-from-the-client-request + the-value-of-the-Append-domain-option must appear in the Targets > Domain list. Alternatively, you must include the IP address of the hostname-from-the-client-request + the-value-of-the-Append-domain-option host.
Example: Hostnames and inband destination selection
For example, you have set Append domain to example.com, and your clients use the username%servername request, then you must include either the servername.example.com host or its IP address in the Targets > Domain list.
-
If the clients can access only a specified port on the server, enter it into the Port field. If the Port is not set, the clients may access any port on the server.
-
If there are any servers that the users cannot target using inband destination selection, add them to the Exceptions field.
-
To use inband destination selection with RDP connections without using One Identity Safeguard for Privileged Sessions (SPS) as a Remote Desktop Gateway (or RD Gateway), you must use SSL-encrypted RDP connections (see Enabling TLS-encryption for RDP connections).
-
Click 
.
Expected result
The connection policy will extract the address of the destination server from the protocol information.
Modifying the source address
The source address is the address that One Identity Safeguard for Privileged Sessions (SPS) uses to connect the server. The server sees this address as the source of the connection.
To modify the source address of a connection
-
Navigate to the Connections tab storing the connection and click 
to display the details of the connection.
Figure 171: <Protocol name> Control > Connections — Configuring connections
-
The SNAT section allows you to configure Source Network Address Translation (SNAT) on the server side of SPS. SNAT determines the IP address SPS uses in the server-side connection. The target server will see the connection coming from this address. The following options are available:
-
Use the IP address of a SPS logical interface: Server-side connections will originate from SPS's logical network interface. This is the default behavior of the connection.
-
Use the original IP address of the client: Server-side connections will originate from the client's IP address, as seen by SPS.
-
Use fixed address: Enter the IP address that will be used as the source address in server-side connections.
Alternatively, you can enter a hostname instead. SPS automatically resolves the hostname to an IP address.
NOTE: Note the following limitations:
-
To resolve the hostnames, SPS uses the Domain Name Servers set in the Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields.
-
If the Domain Name Server returns multiple IP addresses, SPS randomly selects from the list.
|
|
Caution:
Do not forget to properly configure routers and other network devices when using the Use fixed address option: messages sent by the server to this address must reach SPS. |
-
Click .
Creating and editing channel policies
The Channel Policy lists the channels (for example, terminal session and SCP in SSH, or Drawing and Clipboard in RDP) 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 via SSH terminal, but the channel policy may restrict SCP access only to a single client. The policies set in the Channel Policy are checked when the user attempts to open a particular channel type in the connection.
Figure 172: <Protocol name> Control > Channel Policies — Configuring channel policies
To create a new channel policy or edit an existing one
-
Channel policies are configured individually for every protocol. Navigate to the Channel Policies tab of the respective protocol (for example, SSH Control > Channel Policies) and click to create a new channel policy. Enter a name for the policy (for example, shell_and_backup).
-
Click 
to add a new channel.
-
Select the channel to be enabled in the connection from the Type field. All restrictions set in the following steps will be effective on this channel type. The available channels are different for every protocol. For their descriptions, see the following sections:
-
To restrict the availability of the channel only to certain clients, click in the From field and enter the IP address of the client allowed to use this type of the channel. Repeat this step until all required client IP addresses are listed.
Alternatively, you can also enter a hostname instead. One Identity Safeguard for Privileged Sessions (SPS) saves the hostname and resolves it when opening channels, therefore SPS can trace dynamic IP addresses.
NOTE: Note the following limitations:
-
The Domain Name Servers you set must be able to resolve the hostnames you enter into the From and Target fields, otherwise this function (and, therefore, the sessions using this Channel Policy) will not work.
-
SPS Channel Policies support wildcard characters in the *.example.com format. If the channel opening request contains an IP address, SPS uses a reverse lookup method to resolve this IP address into a hostname for a match.
-
SPS uses the Domain Name Servers set in the Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields to resolve the hostnames.
-
To restrict the availability of the channel only to certain servers, click in the Target field and enter the IP address of the server allowed to use this type of the channel. Repeat this step until all required server IP addresses are listed.
NOTE: Use the real IP address of the server, which may be different from the one addressed by the clients, specified in the Target field of the connection policy.
Alternatively, you can also enter a hostname instead. One Identity Safeguard for Privileged Sessions (SPS) saves the hostname and resolves it when opening channels, therefore SPS can trace dynamic IP addresses.
NOTE: Note the following limitations:
-
The Domain Name Servers you set must be able to resolve the hostnames you enter into the From and Target fields, otherwise this function (and, therefore, the sessions using this Channel Policy) will not work.
-
SPS Channel Policies support wildcard characters in the *.example.com format. If the channel opening request contains an IP address, SPS uses a reverse lookup method to resolve this IP address into a hostname for a match.
-
SPS uses the Domain Name Servers set in the Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields to resolve the hostnames.
Alternatively, you can configure a custom DNS server to be used for target selection. Select Enable Custom DNS server under the Target section of your connection policies (set under <Protocol name> Control > Connections) and enter the IP address of the custom DNS server.
-
To restrict the availability of the channel only to certain users, click in the Remote Group field and enter the name of the user group allowed to use this type of the channel. Repeat this step until all permitted groups are listed.
To restrict the availability of the channel when using gateway authentication, click in the Gateway Group field and enter the name of the user group allowed to use this type of the channel. Repeat this step until all permitted groups are listed.
You may list local user lists as defined in Creating and editing user lists, or LDAP groups (for details on accessing LDAP servers from SPS, see Authenticating users to an LDAP server). Note the following behavior of SPS:
-
If you list multiple groups, members of any of the groups can access the channel.
NOTE: >When listing both a whitelist and blacklist in the Remote Group section and a username appears on both lists, the user will be able to access the channel.
-
If you do not list any groups, anyone can access the channel.
NOTE: When the channel opens, there are certain cases when the remote group is not known yet. For example, in case of an RDP or ICA login screen, the drawing channel has to be opened first to properly display the logon screen. Only those channel rules will apply, where the Remote group field is empty. In case of network level authentication, all required information is present already so this limitation does not apply.
-
If a local user list and an LDAP group has the same name and the LDAP server is configured in the connection that uses this channel policy, both the members of the LDAP group and the members of the local user list can access the channel.
-
Select a time policy to narrow the availability of the channel. If the time policy of the channel policy is set to 7x24, the channel is always available. For details, see Configuring time policies.
-
Some channel types require additional parameters, for example port forwarding in SSH needs the IP addresses and ports of the source and destination machines. Click in the Details field and enter the required parameters. For a list of parameters used by the different channels, see Supported SSH channel types and Supported RDP channel types.
-
Select the Record audit trail option to record the activities of the channel into audit trails. Typically large file-transfers (for example system backups, SFTP channels) are not audited because they result in very large audit trails. Check regularly the free hard disk space available on SPS if you do audit such channels. You can also receive alerts about disk space fill-up if you set these. For details, see Preventing disk space fill-up and System related traps.
-
Select the 4 eyes option to require four-eyes authorization to access the channel. For details, see Configuring four-eyes authorization.
-
Repeat Steps 2-10 to add other channels to the policy.
NOTE: 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.
-
Click to save the list.
Real-time content monitoring with Content Policies
You can monitor the traffic of certain connections in real time, and execute various actions if a certain pattern (for example, a particular command or text) appears in the command line or on the screen, or if a window with a particular title appears in a graphical protocol. Since content-monitoring is performed real-time, One Identity Safeguard for Privileged Sessions (SPS) can prevent harmful commands from being executed on your servers. SPS can also detect numbers that might be credit card numbers. The patterns to find can be defined as regular expressions. In case of ICA, RDP, and VNC connections, SPS can detect window title content.
The following actions can be performed:
-
Log the event in the system logs.
-
Immediately terminate the connection.
-
Send an e-mail or SNMP alerts about the event.
-
Store the event in the connection database of SPS.
SPS currently supports content monitoring in SSH session-shell connections, Telnet connections, RDP and Citrix ICA Drawing channels, and in VNC connections.
NOTE: Command, credit card and window detection algorithms use heuristics. In certain (rare) situations, they might not match the configured content. In such cases, contact our Support Team to help analyze the problem.
Real-time content monitoring in graphical protocols is not supported for Arabic and CJK languages.
