A privileged user is allowed to start a remote desktop session to a Windows server or desktop by using RDP relay, Direct RDP or Credential Provider, and to a Linux server by using pcksh and SSH relay. But if the user performs an action that is unauthorized, you as an administrator can disconnect that session and if required you can block the user from starting the session again. The administrator can configure the level of risk, enable auto disconnect, and enable auto block. You can either disconnect the session manually or you can configure this feature to disconnect the session automatically.
You can also disconnect a database or an application session.
When defining policies ensure that Run Host should be same as the agent name that you have specified in the Host console.
If you want to grant access to any framework user to use the Reports console that includes the disconnect field, then in the Framework User Manager console, you need to add the user to a group that has a role with the following specification:
Module: *
Role: *
For information about Framework User Manager, refer Section 4.0, Managing Users and Groups.
When you, as an administrator, are monitoring every activity that is performed on a remote machine for a particular session, and if you find an unexpected command that is run on the remote server, you can disconnect the session manually and send the reason for disconnecting the session to the user. You can also block the user from using the session again.
The administrator can disconnect the session when a high risk level or any suspicious activity is displayed in the Report data of the Reports console. To disconnect a user from the session on which an unauthorized command is used, perform the following steps in the Reports console:
Click Command Control Reports then select the report.
Open the session that is active.
In the Disconnect Reason field, specify the reason for disconnecting the session.
This is required for auditing.
(Conditional) If you want to block the user from connecting to the same session, select Block User.
By default this checkbox is deselected. Because you may not want to block the user but warn the user about the unauthorized activity that was performed during the session.
NOTE:When you block a user from a session, the user gets added to the Blocked Users list and the user will be blocked from accessing any of the sessions.
Click Disconnect.
You can automatically disconnect the session based on the risk of using a command. In case of emergency access, the session is disconnected automatically based on the expiry time that is specified for emergency access.
NOTE:An SSH relay session cannot be disconnected automatically.
An Administrator can configure Command Risk to automatically disconnect a remote session when a particular risk level is detected or when a user executes a particular command.
The administrator can add commands to a rule and enable the auto disconnect feature for the required commands that can be performed on the remote Windows server or desktop.
NOTE:For a pcksh session: the disconnect based on the risk can happen either when the command /usr/bin/pcksh -o audit 1 or /usr/bin/pcksh -o audit 2 is defined in the Rewrite field for the Commands object, or when the Enhanced Access Control Policy script is added.
To configure disconnecting the session automatically, perform the following:
In the navigation pane of the command control console, click the command icon then select Command.
In the details pane, click Command risk.
Set Command Risk.
For information on setting the command risk refer Setting the Command Risk.
Specifying 1 in Auto disconnect field will automatically disconnect the user when the specified command is executed on the host server. Specifying 1 in Auto Block will block the user from further starting the session.
When you have approved a request for emergency access for a specific time frame, the session gets expired after the expiry time that includes the grace period with the specified time. To disconnect a session based on the expiry time you need to configure the administrative settings for emergency access. For information about configuring the settings, refer Section 6.3.1, Configuring Emergency Access Settings.
In the Reports console, an administrator can view which session was disconnected, the type of disconnect (automatic or manual disconnect), and the reason of disconnecting the session. This can be monitored by using Command Control Reports. To include the fields that display the disconnect information you must perform the following:
On the home page of the console, click Reports.
Click Command Control Reports then, click the required report.
Click the Filter tab then, select Disconnect Details.
The Disconnect Type and the Disconnect Reason fields are displayed under Report Data.
To view the reports for only the disconnected sessions, select Disconnect Report in the Command Control Reports.
The SSH Relay feature is enhanced to support allow commands. With this enhancement, on a privileged SSH session, the end user is allowed to run only the allowed commands and for all the other commands, the user would be denied command execution with a ‘Permission Denied’ message. This implementation is applicable from Privileged Account Manager 3.7 onwards.
The SSH Relay policy configuration remains as it is today. For the alllow commands support, the same or similar policy can be enhanced by attaching a command control script to the Policy or Rule and by defining the allowed commands as Script Arguments to the Policy or Rule. Only one instance of the script must be created manually and the same can be attached to the Rule where the allow commands are to be applied. The particular Rule’s Script Arguments determines the commands that are allowed for the session authorized by that Rule.
When the user connects to Privileged Account Manager and establishes a privileged SSH session, if the authorizing Rule/Policy is associated with an allowed script and arguments, the user is presented with a list of allowed commands.
If the SSH Relay Rule is not associated with the particular script and it’s arguments then the policy behavior would be like a normal ssh-relay policy where the user would be given the privileged ssh session with no command restriction/control by SSH Relay server. The target server can be an SSH server or Telnet server.
NOTE:With this feature, the user is restricted or allowed to run only the commands that are allowed and the runUser (user on target) would be as per the Policy or Rule configuration. The target OS may also restrict the allowed command based on the runUser set on the Rule or Policy. For example, if /sbin/fdisk is a allowed command as per SSH Relay Policy or Rule and the runUser set on the Rule or Policy is a normal non-root user, then the user would still be denied access by the target Operating System permission as the command can be executed by a root-user only.
You can set up these permissions using the following procedure:
Click Administration Console > Command Control, create an SSH-Relay policy. You could also use the SSH Relay template to create this policy.
Create a new Command Control Script, name it as allow command. The contents of the script should be as below:
my $cmds = $args->arg("Commands");
if ($cmds) {
$cmds =~ s/\r/\n/g;
$meta->child("Command")->arg("CmdList",$cmds);
}
return 1;Associate the script with the SSH policy by dragging the script and dropping it on to the SSH-Relay Rule.
The Commands are taken from ScriptArgs set on the SSH-Relay Rule. The name of the ScriptArgs should be Commands and the list of commands are delimited by new-line as shown in the below example. The command can also be a regex.
ssh -t -p 2222 john@rhel8din
Warning: Permanently added '[rhel8din]:2222' (RSA) to the list of known hosts.
john@rhel8din's password:
0) Exit
1) ssh relay - root@ssh
Enter option (1-1): 1
Allowed commands in this session are :
1) id 2) /sbin/ifconfig*
Password:
Last failed login: Thu Dec 10 10:21:51 MST 2020 from 10.71.130.191 on ssh:notty
There were 3 failed login attempts since the last successful login.
Last login: Mon Nov 30 12:16:24 2020 from 164.99.210.133
vlab031509:~ # id
uid=0(root) gid=0(root) groups=0(root)
vlab031509:~ # /etc/passw
Permission denied!d
vlab031509:~ # /sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:56:86:F2:A2
inet addr:10.204.101.237 Bcast:10.204.103.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:511746838 errors:0 dropped:245080 overruns:0 frame:0
TX packets:18860334 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:55836832085 (53250.1 Mb) TX bytes:12912375114 (12314.2 Mb)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:17818674 errors:0 dropped:0 overruns:0 frame:0
TX packets:17818674 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8788789816 (8381.6 Mb) TX bytes:8788789816 (8381.6 Mb)