17.2 Session Management

Privileged session and session capture can be achieved through the following methods:

17.2.1 pcksh

pcksh is used by administrator to grant privileges to a non-privileged system user, such as the ability to run commands as root and to perform a complete session capture of all the user actions. A user logs in as a non-privileged user, then issues a usrun pcksh command to access the root ksh shell and all the user actions in this shell are audited.

In addition, you can also configure rules to set up command risks and disconnect the session when executing specific commands.

Using pcksh shell you can perform the following:

Privileged Session Using pcksh

Using pcksh method the administrator can grant privileged session to a non-privileged system user and all the user action in the privileged session are captured.

Configuring pcksh for a Privileged Session

To grant privileged session to a non-privileged system user, the administrator must configure pcksh privileged session in Privileged Account Manager. For steps to configure the pcksh privileged session in Privileged Account Manager, see Workflow to Configure Privileged Access for Windows

Accessing pcksh for a Privileged Session

To access pcksh privileged session in Linux or UNIX system perform the following,

  1. Log into the UNIX system as a non-privileged user.

  2. Use usrun command to gain privileged shell access to perform administrative functions.

    For example, specify usrun pcksh or usrun shell command. The command is rewritten to /usr/bin/pcksh and Command Control Audits set to 1 based on the policy created in Privileged Account Manager.

  3. Execute the commands that require privileged access and perform the required operations in the UNIX or Linux system. These actions that are performed within the pcksh shell are audited based on the Command Control policy and can be viewed in Command Control Reports. For steps more information on the Command Control Reports, see Command Control Reports

If the users need different environment variables to run some of their privileged commands, you can use a script to set up the values.

By default, Command Control uses the environment variables of the executing user. If the users receive a “not found” message for a command, you need add environment variables to the rule. For configuration information, see Scripts and Modify Environment Script.

You can also define illegal commands, including built-in shell commands, in a script assigned to the rule. For configuration information, see Scripts and pcksh Illegal Commands Script.

Usage Scenario

Consider a scenario where the administrator has to provide privileged access to a part of the user session and monitor that privileged session.

For this scenario, the administrator must perform the following configuration in the command control:

  1. Register the agent to Privileged Access Manager

  2. Add a pcksh command pcksh_cmd with the following field values:

    Description: Explain the purpose of this command. For example, When a user submits a usrun pcksh command or a usrun shell command, the command is rewritten to /usr/bin/pcksh. The Command Control Audit level is set to 1, which enables an additional level of audit to use with the Command Risk.

    Rewrite: /usr/bin/pcksh -o audit 1

    Commands:

    pcksh

    shell

  3. Create a user group pcksh_usrgrp with the following field values:

    Description: Explain the purpose of the user group. For example, Defines the user accounts that can run the usrun pcksh command to access root privileges.

    Users: Specify the usernames of the users on the Linux and UNIX hosts that have thepermission to use the usrun pcksh command.

  4. Add a rule pcksh_rule with the following field values:

    Description: Explain the purpose of the rule. For example, Matches users who submit a usrun pcksh or usrun shell command. It authorizes their session and enables session capture as root. The command assigned to this rule also included a rewrite that enables the additional level of audit to be used in conjunction with the command risk list.

    Session Capture: Select On.

    Authorize: Select Yes, then select Stop from the drop-down menu.

    Run User: Specify root.

  5. Drag and drop the command pcksh_cmd and user group pcksh_usrgrp to the rule pcksh_rule.

After the administrator has configured the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged session as following:

  1. Log into the Linux or UNIX system as a non-privileged user.

  2. Enter the command usrun pcksh to start a privileged session.

    All the user actions in this privileged session are audited and the administrator can view these reports in the admin console.

Complete Session Control Using pcksh

You can use pcksh to get complete session capture of the non-privileged UNIX or Linux system user. For complete session capture of the user, the user’s login shell should be modified to pcksh client. The pcksh client executes commands as a normal Korn shell.The functions and the aliases that replace normal system commands are read from /etc/profile.pcksh.When the user issues a command that needs privileges to run, it is authorized through the Framework.

Configuring pcksh for Complete Session Capture

To get complete session capture using pcksh, the administrator must make appropriate configurations in Privileged Account Manager.For steps to configure the pcksh in Privileged Account Manager, see Workflow to Configure Privileged Access for Windows

Accessing pcksh for Complete Session Capture

To access pcksh for complete session capture perform the following,

  1. Log into the UNIX or Linux system as a non-privileged user.

  2. Use the tool provided in the UNIX or Linux environment to set the users’ shell to the following:

    /usr/bin/pcksh
  3. To ensure that configured commands are authorized at the Framework, add the following line to either the user’s profile file or to the central profile.pcksh file in the /etc directory on the appropriate UNIX or Linux servers:

    set -o remote

    IMPORTANT:The set -o remote option forces all commands that are not built in to the user’s shell to be authorized at the Framework. Commands for which a defined rule does not exist are not permitted to execute. To prevent all commands in the profile.pcksh file or .profile file from being passed to the Framework for authorization, add the set -o remote command at the end of the file.

  4. (Optional) Set the following additional options in the profile file:

    Option

    Description

    set -o host <hostname>

    Specifies that all authorized commands are executed on the defined host, if permitted.

    set -o user <username>

    Specifies that all authorized commands are executed as the defined user if permitted.

    set -o audit <n>

    Enables auditing, Set <n> to one of the following values:

    • 1: Enables auditing of all commands that are not built into the user's shell.

    • 2: Enables auditing of all commands including commands that are built into the user's shell. This level of auditing can affect login times.

    After the audit value has been set, it cannot be changed. If it is turned on in the profile, the user cannot turn it off later.

    set -o ignoreperm

    Enables commands that have not been successfully authorized at the Framework to execute according to the local permissions in effect on the server where the command was issued.

    set -o test

    Allows typed commands to be checked to see if they would be accepted by the rule structure.

    A yes or no output to screen indicates the result.

    The set -o test option is normally used in conjunction with the set -o remote option.

    set -o test '${}$'

    Returns the complete metadata result that is generated by the Command Control manager.

    Rule definitions override the settings for user and host. If a successfully matched rule specifies a run user or a run host, this user or host is used to execute the command, and not those specified in the set -o commands.

    You can use rule conditions to match the run user or run host to the username or hostname defined by using these commands (see Setting Conditions for a Rule), but if a run user or run host is defined in the rule configuration, these are the ones that are used.

    You can define a list of illegal commands, including built-in shell commands, in a script assigned to a rule. Users using the pcksh shell cannot run these commands, even if they are root.

Using Shell Scripts

You can hide some of the complexities of the privileged command syntax from the users by using scripts and aliases to wrap privileged tasks. Using this technique, the end user can log in with their non-privileged account and use what appear to be standard commands to perform privileged tasks. Alternatively, you could create a script that provides a menu system to access a set of administrative tasks. With this method, the user would simply select options from the menu to perform their privileged tasks.

Either method requires a shell script that executes under the pcksh shell and performs remote authorization. For example: 

#!/usr/bin/pcksh
set –o remote 
passwd $*

This script executes the pcksh client, sets it to use Command Control, and executes the passwd command.

17.2.2 cpcksh

cpcksh is used to audit the complete user’s session. With NetIQ Privileged Account Manager, you can change a user’s login shell to cpcksh (/usr/bin/cpcksh), then configure a Command Control rule to authorize cpcksh and enable session capture. When the users log in, the commands are captured and audited through NetIQ Privileged Account Manager.

This method of integration provides the most auditing functionality. By changing the user’s shell to the cpcksh client instead of the pcksh client, Command Control can be configured to capture the user’s complete session, in addition to all other audit and control features.When the user logs in to the server, the session is started with the cpcksh client, which executes as a normal Korn shell. A request is sent to the Command Control Manager for authorization.

Functions and aliases that can replace normal system commands are read from /etc/profile.pcksh. When the user issues a command that needs privileges to run, it is executed through the Command Control system.

Configuring cpcksh for Complete Session Capture

To get complete session capture using cpcksh, the administrator must make appropriate configurations in Privileged Account Manager.For steps to configure the cpcksh in Privileged Account Manager, see Workflow to Configure Privileged Access for Windows

Accessing cpcksh for Complete Session Capture

To access cpcksh for complete session capture perform the following,

  1. Log into the UNIX or Linux system as a non-privileged user.

  2. Use the tool provided in the UNIX or Linux environment to set the user login shell to

    /usr/bin/cpcksh
  3. Perform the required operation and all these user actions are audited and can be viewed in Command Control Reports. For more information on the Command Control Reports, see Command Control Reports

Usage Scenario

Consider a scenario where the administrator has to provide a privileged session and complete session when a non-privileged user logs in.

For this scenario, the administrator must perform the following configuration in the command control:

  1. Register the agent to Privileged Access Manager

  2. Add a pcksh command cpcksh_cmd with the following field values:

    Description: Explain the purpose of this command. For example, When a user's shell is set to /usr/bin/cpcksh and the user logs in, a Command Control request is sent with a submitting command of -cpcksh to indicate login. The user's login shell is rewritten to /usr/bin/pcksh. The Command Control Audit level is set to 1, which enables an additional level of audit to use with the Command Risk.

    Rewrite: /usr/bin/pcksh -o audit 1

    Commands:

    -cpcksh

  3. Create a user group cpcksh_usrgrp with the following field values:

    Description: Explain the purpose of the user group. For example, Defines the user accounts that can use the cpcksh command.

    Users: Specify the usernames of the users on the Linux and UNIX hosts that have thepermission to use the usrun pcksh command.

  4. Add a rule cpcksh_rule with the following field values:

    Description: Explain the purpose of the rule. For example, Authorizes the matching of submit users who have /usr/bin/cpcksh as their defined login shell. It authorizes their session and enables session capture, when they are still running as their original login ID.

    Session Capture: Select On.

    Authorize: Select Yes, then select Stop if authorized from the drop-down menu. These settings allow subsequent commands to be executed without authorization checks whenever the user has had one command authorized.

  5. Drag and drop the command cpcksh_cmd and user group cpcksh_usrgrp to the rule cpcksh_rule.

After the administrator has configured the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged session as following:

  1. Log into the Linux or UNIX system as a non-privileged user.

  2. Use the tool provided in the UNIX or Linux environment to set the users’ shell to the following:

    /usr/bin/cpcksh
  3. Perform the required action in the Linux or UNIX system.

    All the user actions in this privileged session are audited and the administrator can view these reports in the admin console.

17.2.3 Secure Shell Relay

Secure Shell Relay (SSH Relay) provides the ability to access privileged accounts using a standard SSH client. This feature provides the ability to access Privileged Account Manager functionality without an agent for Privileged Account Manager on the target host. SSH Relay allows users to connect to a remote host by using secure shell without knowing the privileged account credentials such as password or identity certificate of the user.

SSH Relay session videos can be captured only if the PAM manager is in Linux environment.

Configuring an SSH Relay Session

The packages are:

  • SSH Relay Agent

  • SSH Agent

SSH Relay listens on port 2222. You need to verify port 2222 is assigned for hosts running the SSH Relay Agent package.

For steps to configure an SSH Relay in Privileged Account Manager, refer Workflow to Configure UNIX and Linux Privileged Sessions

Accessing an SSH Relay Session

After making appropriate SSH relay configuration, you can access the SSH relay session in the following ways:

Accessing an SSH Relay Session from My access console

Start an SSH client by selecting the policy for the SSH relay session on My Access page. A JAVA Webstart program will then launch the downloaded JNLP file, which will then launch the JAVA UI.

  1. Launch the My Access page and specify the IP address of the Framework Manager in the address bar in the following format:

    https:// <IP address of the Framework Manager>/pam

  2. Press Enter. A login screen appears.

  3. Enter the username and password and click Login to log in to the Privileged Account Manager.

    A list of rules defined for that particular user is displayed in the following format: <rulename>(<username>@<machinename>)

  4. Click on the rule required for accessing the Non Windows machine.

NOTE:

  • In Chrome browser, you have to open the downloaded JNLP file to launch the JAVA UI.

  • In Mozilla Firefox and Internet Explorer, the JNLP file opens automatically and launches the JAVA UI.

  • In Edge browser, you must modify the default program for launching the JNLP file to javaws.exe.

After the UI launches, the user must provide the credentials of the SSH Relay user to start the session.

Accessing an SSH Relay Session from SSH Client

  1. You can initialize an SSH relay session by using the following command:

    ssh -t -p2222 <PUMframeworkuser@sshrelayhost> <root@hostname>

    To initialize an SSH relay session with X11 forwarding, use the following command:

    ssh -X -t -p2222 <PUMframeworkuser@sshrelayhost> <root@hostname>

  2. A list of all the available SSH sessions are displayed. Enter the appropriate option to start the respective SSH relay session and provide the credentials of the SSH Relay user.

    NOTE:When you exit from the current SSH Relay session, all the available SSH Relay sessions are displayed again enabling you to connect to a different target system.

Usage Scenario

Scenario 1:

Consider a scenario where the administrator has to provide a privileged access to a Privileged Account Manager user.

For this scenario, the administrator must perform the following configuration in the command control:

  1. Create an account domain for the Linux or UNIX system.

  2. Add a rule ssh_relay_rule with the following field values:

    Run User: root

    Run Host: Submit Host

    Session Capture: Select On.

    Credentials: From the drop-down list, select the required account domain. The Run User is automatically populated with the domain user provided in the account domain.

  3. Drag and drop the preloaded command SSH Session to the rule ssh_relay_rule.

After the administrator has configured the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged session as following:

  1. Launch the My Access page using the following URL:

    https:// <IP address of the Framework Manager>/pam

  2. Login using the Privileged Account Manager credentials.

  3. Click the required rule from the list of rules displayed in the following format: <rulename>(<username>@<machinename>)

  4. Enter the Privileged Account Manager credentials and access the SSH relay session.

    All the user actions in this privileged session are audited and the administrator can view these reports in the admin console.

Scenario 2:

Consider a scenario where the administrator has to provide a privileged access with X11 application access to a Privileged Account Manager user.

For this scenario, the administrator must perform the following configuration in the command control:

  1. Create an account domain for the Linux or UNIX system.

  2. Add a rule ssh_relay_rule with the following field values:

    Run User: root

    Run Host: Submit Host

    Session Capture: Select On.

    X11 Enable: Select Yes.

    The videos for X11 application are captured based on the global videos settings. For information about modifying the video settings, see Configuring the Video Conversion Settings

    Credentials: From the drop-down list, select the required account domain. The Run User is automatically populated with the domain user provided in the account domain.

  3. Drag and drop the preloaded command SSH Session to the rule ssh_relay_rule.

After the administrator has configured the authorization rule in Privileged Account Manager, the non-privileged Linux or UNIX user can gain privileged session as following:

  1. Launch the My Access page using the following URL:

    https:// <IP address of the Framework Manager>/pam

  2. Login using the Privileged Account Manager credentials.

  3. Click the required rule from the list of rules displayed in the following format: <rulename>(<username>@<machinename>)

  4. Enter the Privileged Account Manager credentials and access the SSH relay session.

    All the user actions in this privileged session are audited and the administrator can view these reports in the admin console.