Access disclosure plugins

The pswcmdrun access disclosure plugin is used with account set access requests. It allows users to run commands or scripts on multiple managed systems using managed account credentials.

When a user checks out an account set, Bravura Privilege displays a command execution window if any of the member systems support the run command operation.

Currently the following target systems support the run command operation:

Additional preparation is required before pswcmdrun can run PowerShell commands on a Windows Server / workstation target. See Windows Server in the Connector Pack documentation for details.

If the plugin is enabled but an account set contains no managed system that supports the run command operation, Bravura Privilege displays the following message upon check-out:

You can modify the following default attributes to control the behavior of pswcmdrun :

Command attribute

The pswxcmd access disclosure plugin provides users with access to managed systems by executing an external program and providing credentials. The default program is PuTTY.exe, which opens an ssh/telnet terminal to a Windows machine. The external program must meet the following requirements:

There are three types of command prompt controls; one is specifically for managed accounts, and the other two are for temporary group membership, where the password can either be passed onto the command line, or specified upon connection to the remote server.

You can modify the following default attributes to control the behavior of pswxcmd :

Arguments attribute

The arguments provide substitution of the password, user name, host, and other custom plugin attributes. The substitutions are as follows:

Using custom attributes provides control over the arguments attribute. You can enable the user to override the custom attribute only, while leaving the arguments locked or hidden.

The following are examples of customizations using the pswxcmd access disclosure plugin.

Allow optional arguments

The default settings for pswxcmd execute PuTTY and connect using the privileged password. This example shows how you can add a custom attribute to allow the user to specify the port:

Insert an escalation sequence

You can allow users to insert an escalation sequence into a program (such as PuTTY.exe) using a hotkey or window name.

When a user presses the escalation hotkey, the escalation sequence is automatically typed into the program. By default, the escalation hotkey is Ctrl + K.

To configure the escalation hotkey:

When the window name is detected, the escalation sequence is automatically typed into the program.

To configure the escalation window name:

Impersonating the checked-out account

You can allow the requester to run a program (such as cmd.exe) with the permissions of the checked-out account. This will essentially simulate the runas command.

Set the impersonate attribute to:

Executing a shell script

This example shows how you can configure pswxcmd to execute a shell script:

Executing SQL*Plus

This example shows how you can configure pswxcmd to execute SQL*Plus:

Changing the message to users on failure

You can change the message displayed to users in the event that the external program fails to launch by modifying the RES CONNECTION TO SERVER FAILED MSG setting in the global or managed system policy Account access request options.

This is a preconfigured pswxcmd access disclosure plugin specifically for managed accounts. By default, this plugin is configured to execute PuTTY and connect using the user’s SSH keys instead of the privileged password.

The following requirements must be met:

The following attributes are available:

See Command prompt: pswxcmd for more information on modifying these attributes.

The pswxcopy access disclosure plugin provides users with access to a password by copying it into the clipboard of the client workstation. By default, it is configured to clear the clipboard if the browser is closed or if the default 30 seconds expiry time for the plugin has passed.

You can modify the following default attributes to control the behavior of pswxcopy :

The pswxtsvc access disclosure plugin provides users with access to Windows server or client managed systems and RemoteApp programs using Remote Desktop Connection (RDC). The plugin provides automatic connection to the managed system without requiring the entry of administrative credentials for the managed account. You can also connect to the remote server when accessing group sets. This access disclosure plugin supports Network Level Authentication (NLA) and session monitoring.

There are two versions of the pswxtsvc access disclosure plugin:

The plugin requires the following:

You can modify the following default attributes to control the behavior of pswxtsvc :

The following disclosure attributes are applicable to the Remote desktop access disclosure plugin only:

The following disclosure attributes are applicable to the Remote APP RDP disclosure plugin only. You can obtain these values by viewing the contents of the RemoteApp’s .rdp file.

Authentication prompting

If the managed system you are connecting to is configured to include a prompt for password upon connection, you may notice that the password field is already filled in. You can proceed by clicking OK ; you do not need to specify any additional information.

The password is passed from the disclosure plugin to the RDP client via Windows UI Automation (MSAA).

If you receive a similar error and the password is not populated at all, it's possible that Windows changed the RDP dialog. If you are using a supported version of Bravura Security Fabric

Bravura Security Fabric , contact support so they can look for a possible patch.

The pswxview access disclosure plugin provides users with access to a password by displaying it within the browser. When the secure method is enabled, Bravura Privilege uses JavaScript to decrypt the privileged password embedded in the page. If the insecure method is enabled, the browser can store passwords in plain text in the page source, and users can view the password in browsers that do not have JavaScript enabled.

You can modify the following default attributes to control the behavior of pswxview :

Changing default font and size of viewable passwords

You modify the default font and size of viewable passwords by opening the following files:

passFontFamily: ‘<font_name>'
passFontSize: <font_size>

If the ie directory exists, the file in it will override the global file outside of it.

Split password view

You can split up a password amongst multiple viewers by specifying the pwd split attribute. This takes the form ”n/m” where m is the number of pieces to split the password into, and n is the number of the piece that this instance of the control should display.

For example, 1/2 will display the first half of the password, while 2/2 will display the second half. You can configure a plugin to determine what part of the password a viewer will see. See Using a plugin to define access disclosure plugin . If you don’t intend to use password splitting, you can safely delete the default pwd split attribute.

Use an alternative disclosure plugin, such as Website access disclosure plugins , as Internet Explorer is no longer a supported browser. For information about pswxdom see documentation for 12.5 or older.

Installing ActiveX controls is no longer a supported method. See documentation for Bravura Security Fabric version 12.5 or older if you need information about this feature..

An MSI installer is available for download when users attempt to access a password without installing the browser extension for Chrome or Firefox first:

These MSI installers are also available on the Bravura Security Fabric server in the addons\idarchive directory.

If a previous version of native extensions for Firefox is already installed on the workstation (11.1.x or older) you must uninstall and install the current version.

Disclosure plugins are not supported for Mac OS.

To manually install the browser extension:

You can launch access disclosure plugins using the one-time disclosure method. These plugins have the same functionality as the native access disclosure plugins and do not require additional software, however they are good for one-time use only. The one-time disclosure is available as an executable that can be run directly or downloaded to be run on a different workstation. A new executable needs to be generated in order to view the access disclosure plugin again.

You can configure messages to display to users how much check-out time is remaining and that the check-out time has expired.

When a one-time disclosure plug-in is downloaded and executed, the plug-in will check with Bravura Privilege to determine how much time is left in the checkout, or if the authorized interval has expired. This also applies to one-time plug-ins that have been saved for future use.

The one-time disclosure option is enabled by default. End-users may be able to see this option if the native access disclosure plugins are not yet installed or are disabled. When the one-time disclosure option is disabled, the option will be grayed out.

To disable one-time disclosures:

Users on a Windows workstation are prevented from installing browser extensions

To allow users to install the browser extensions, enable and modify the following group policy setting:

Administrators on a Windows workstation cannot install browser extensions for all users

If administrators are unable to select an installation scope option, disable the following in the Local Group Policy Editor:

The guacamole-rdp Guacamole access disclosure plugin provides users with remote access to Windows server or client managed systems using Remote Desktop Connection (RDC). This control provides automatic connection to the managed system without the need to enter the administrative credentials for the managed account and is compatible with session recording.

You can modify the following default attributes to control the behavior of guacamole-rdp :

The guacamole-remote-app Guacamole access disclosure plugin provides users with remote access to applications hosted on a Windows server or client managed system using Remote Desktop Connection (RDC). This control provides automatic connection to the managed system without the need to enter the administrative credentials for the managed account and is compatible with session recording.

You can modify the following default attributes to control the behavior of guacamole-remote-app :

The guacamole-ssh Guacamole access disclosure plugin provides users with remote access to a server using Secure Shell (SSH). This control provides automatic connection to the managed system without the need to enter the administrative credentials for the managed account and is compatible with session recording.

You can modify the following default attributes to control the behavior of guacamole-ssh :

The guacamole-telnet Guacamole access disclosure plugin provides users with remote access to a server using Telnet. This control provides automatic connection to the managed system without the need to enter the administrative credentials for the managed account and is compatible with session recording.

To use this control, Telnet must be installed and enabled on the managed system.

You can modify the following default attributes to control the behavior of guacamole-telnet :

The guacamole-vnc Guacamole access disclosure plugin provides users with remote access to a server using Virtual Network Computing (VNC). This control provides automatic connection to the managed system without the need to enter the administrative credentials for the managed account and is compatible with session recording.

In order to use this control, VNC must be installed and enabled on the managed system.

You can modify the following default attributes to control the behavior of guacamole-vnc :

There is greater flexibility when using Guacamole access disclosure plugins. It can be viewed on commonly used browsers such as Google Chrome, Mozilla Firefox and Microsoft Edge. Unlike native access disclosure plugins which are limited to Windows, you can view Guacamole access disclosure plugins on other operating systems such as Linux, provided that it has a HTML5-compatible browser. Guacamole access disclosure plugins can also be viewed on mobile devices such as smart phones and tablets.

Guacamole access disclosure plugins have similar functionality as the native access disclosure plugins. The controls contain default attributes to customize behavior, and are compatible with session recording.

This section outlines the steps for setting up Guacamole. In sequence, you will need to:

There are a couple methods of installing the Guacamole remote desktop gateway:

Install Guacamole using Docker

The following steps are based on a CentOS 7 64-bit distribution. All steps performed on the Guacamole server should be performed as root user.

Obtain the idmunix-rhel-el8.x64.tar.gz or idmunix-rhel-el9.x64.tar.gz file from <instancedir>\addon\idmunix on the Bravura Privilege server and copy it into the Guacamole server under the /root directory.

Stopping the container

To stop the Docker container run:

docker compose down

Starting the container

To start the Docker container; for example, after restarting the Guacamole server, run:

docker compose up -d

Running the Docker container as a service

Docker containers can be controlled using systemd . This is useful when you want to start Guacamole automatically upon reboot of the Guacamole server.

Start the Guacamole service by running:

systemctl start guacamole.service

Stop the Guacamole service by running:

systemctl stop guacamole.service

Logging

Tail the logs for the running containers with the following commands:

docker logs -f guacd

docker logs -f guacamole

Install Guacamole using Podman

The following steps are based on a CentOS 8 and Centos 9 Stream 64-bit distribution. All steps performed on the Guacamole server should be performed as root user.

Stopping the container

To stop the Docker container run:

podman-compose down

Starting the container

Running the Docker container as a service

Docker containers can be controlled using systemd . This is useful when you want to start Guacamole automatically upon reboot of the Guacamole server.

Start the Guacamole service by running:

systemctl start guacamole.service

Stop the Guacamole service by running:

systemctl stop guacamole.service

Logging

Tail the logs for the running containers with the following commands:

podman logs -f guacd

podman logs -f guacamole

At a minimum, to use Guacamole access disclosure plugins, the URL of the Guacamole service must be set. To do this:

In order to secure Guacamole connections using SSL, please ensure the following have been created before proceeding:

It is assumed the reader knows how to generate these items, otherwise contact support@bravurasecurity.com for assistance.

Next steps

Self-signed certificates

If you are using self-signed SSL certificates for the Guacamole server, you will need to deploy these certificates on any system that will be used to launch Guacamole sessions. If not installed, web browsers will return a ERR_CERT_AUTHORITY_INVALID error message because it cannot validate the site’s SSL certificate.

Perform the following steps as a user with administrative permissions, for each system that will be used to launch Guacamole sessions. This is based on a Windows environment.

Configure Guacamole with SSL using Docker

The following steps are based on a Guacamole installation using Docker . All steps performed on the Guacamole server will be done as root user.

Configure Guacamole with SSL using Podman

The following steps are based on a Guacamole installation using Podman . All steps performed on the Guacamole server will be done as root user.

This could be the result of connecting to a managed system that does not require a proxy. If a proxy is not required to access the managed system, modify the no_proxy list in /etc/profile to include the managed system. You will need to source the file again or log off and log back in to the Guacamole server for the proxy changes to take effect. Alternatively, add --http-proxy=false to the podman run commands. For example:

podman run -d --pod guac --name guacd --http-proxy=false guacd
podman run -d --pod guac --name guacamole --http-proxy=false guacamole

Several factors can affect the reliability of Guacamole. One of the major factors is memory usage on the Guacamole server. However, it can be challenging to determine the amount of memory Guacamole consumes. A single Guacamole session can initiate multiple guacd threads; each thread using varying amounts of memory. Plus, the amount of memory initially consumed by a Guacamole session will gradually increase as the session persists. Additionally, the tasks performed on the remote desktop screen can also impact memory consumption, as well as the display settings for the remote desktop screen. Furthermore, RDP sessions consume more memory than SSH sessions.

The following shows how to determine:

To make things simple and consistent, 40 concurrent In-Browser RDP sessions will be launched. Each session will RDP to the same managed system using the same managed account, with the default display resolution of 1024x768 at 96 DPI (dots per inch), and will open a command line window upon login that covers most of the Remote Desktop screen, which will ping 3 reachable IP addresses every 2 seconds. This will simulate constant movement on the screen, which ideally would result in a more realistic worst-case scenario. It is assumed that in a normal case, users will periodically use Guacamole sessions throughout the checkout duration, rather than regularly.

The terms “memory” and “RAM” will be used interchangeably.

To get an idea of how much memory is consumed per Guacamole session, you need to determine the following metrics at each stage:

The memory allocated when launching the initial Guacamole session is typically larger than subsequent Guacamole sessions. This is because some guacd processes will remain active even if all Guacamole sessions have terminated. Thus, the total RAM used at Stage 4 will differ from Stage 2. However, the memory consumed upon launching subsequent Guacamole sessions will be relatively consistent.

A useful tool to measure this information is htop , which can be installed on the Guacamole server using dnf install htop (or yum install htop). You can find more info at https://htop.dev

A minimum 4 core processor is recommended for the Guacamole server. On htop , you can determine the CPU usage based on the “Load average” metric. There are 3 values: the first value is the per minute average; the second value is the 5 minute average; and the third value is the 15 minute average. A value of 4.0 for a 4-core CPU would mean 100% utilization. If the Load Average consistently exceeds this number, it is an indication that additional cores need to be allocated to the Guacamole server based on the load.

Session monitoring is not included in this test. Based on Guacamole benchmarking tests conducted previously, there does not appear to be any noticeable increase in memory usage when Session Monitor is enabled (screenshots, keystrokes and clipboard capture)

Other Guacamole disclosure plugins such as In-Browser SSH, In-Browser VNC, In-Browser RemoteApp and In-Browser Telnet will not be included in this test. In-Browser VNC and In-Browser Remote App should have similar memory requirements as In-Browser RDP; and In-Browser SSH and In-Browser Telnet should both be comparable but use considerably less memory than In-Browser RDP.

The following test was performed:

The total memory usage was gathered after all 40 sessions were initiated and left running for more than 12 hours. One-by-one, each Guacamole session was terminated, and the updated total memory usage per x number of sessions was obtained. This is a more accurate measure of memory usage per Guacamole session instead of obtaining it immediately after the Guacamole session is launched because the memory usage can still fluctuate as time goes on.

The maximum memory usage for a Guacamole session will be used to calculate the worst case, in this case, 116 MB.

To get the minimum amount of RAM in GB for y number of sessions:

z = (557 + 249 + xy) * 0.01

Where :

x = Amount of memory per Guacamole session (MB)

y = Total amount of sessions

z = Total memory (GB)

For 10 Guacamole sessions:

z = (557 + 249 + 116x) * 0.01 
z = (806 + 116(10)) * 0.01 
z = (806 + 1160)) * 0.01 
z = 1966  * 0.01 
z = 1.97 GB 

For 50 Guacamole sessions:

z = (557 + 249 + 116x) * 0.01
z = (806 + 116(50)) * 0.01
z = (806 + 5800)) * 0.01
z = 6606 * 0.01
z = 6.61 GB

For 100 Guacamole sessions:

z = (557 + 249 + 116x) * 0.01
z = (806 + 116(100)) * 0.01
z = (806 + 11600)) * 0.01
z = 12406 * 0.01
z = 12.41 GB

For 200 Guacamole sessions:

z = (557 + 249 + 116x) * 0.01
z = (806 + 116(200)) * 0.01
z = (806 + 23200)) * 0.01
z = 24006 * 0.01
z = 24.01 GB

To get the maximum number of Guacamole sessions for y GB of RAM allocated to the Guacamole server:

x = floor((y – 557 – 249) / z)

Where :

x = Total amount of sessions

y = Free memory (GB)

z = Amount of memory per Guacamole session (MB)

Examples

For 5GB of memory:

x = floor((y - 557 - 249) / 116))
x = floor((y - 308) / 116)
x = floor((5000 - 308) / 116)
x = floor(4692 / 116)
x = 40.44 sessions or 40 sessions.

For 12 GB of memory:

x = floor((y - 557 - 249) / 116)
x = floor((y - 308) / 116)
x = floor((12000 - 308) / 116)
x = floor(11898 / 116)
x = 102.57 sessions or 102 sessions.

For 20 GB of memory:

x = floor((y - 557 - 249) / 116)
x = floor((y - 308) / 116)
x = floor((20000 - 308) / 116)
x = floor(19692 / 116)
x = 169.76 sessions or 169 sessions.

The securebrowser access disclosure plugin provides users with brokered access to a website without the need to enter the administrative credentials for the managed account and is compatible with session recording.

This requires installation of the Secure Browser app.

The securebrowser plugin is primarily used in conjunction with team management .

You can modify the following default attributes to control the behavior of securebrowser :

Collecting logs when the secure browser disclosure has issues

The secure browser extension uses a different technology to the native plugins and doesn't provide logging data to the logutil tool that is normally used for troubleshooting.

You can instead compare server logs for a successful attempt with those for a failed attempt, and try to identify the difference.

The pswxwebapp access disclosure plugin provides users brokered access to a website without the need to enter the administrative credentials for the managed account.

This is compatible with desktop Chrome browsers and requires installation of the Bravura Security browser extension.

The pswxwebapp plugin is primarily used in conjunction with Team Management.

You can modify the following default attributes to control the behavior of pswxwebapp :

To configure system-wide access disclosure options:

You can now:

You can add custom access disclosure plugins to make them available to managed system policies. For each access disclosure plugin, you can configure one or more attributes that modify the behavior of the plugin.

To define common parameters for an access disclosure plugin:

You can add or modify attributes to customize the plugin behavior.

To define access disclosure plugin attributes:

You can override these default settings on the managed system policy level. See Overriding global settings in managed system policies .

All access disclosure plugin attributes of type String can be defined with variables. You can define discovered system attribute values in this manner.

To use the discovered system attribute as-is, simply enter the following in the attribute’s Default value field:

% <attribute name> %

For example, the default domain value for a remote desktop plugin is:

%netBIOSDomainName%

String attributes can be manipulated by using the following syntax:

%k:(start position):(end position):<attribute name>%

For example:

%netBIOSDomainName% = corporate.domain
%k:3:12:netBIOSDomainName% = porate.dom
%username% = CORP\account00
%k:5:username% = account00

In some scenarios, it may be desirable to have multiple instances of the same access disclosure plugin but with different settings; for example:

Product administrators can create new instances of the same access disclosure plugin by cloning.

To clone an access disclosure plugin:

In scenarios where end users can override disclosure plugin attributes, they may want to save their modified values as a saved session ; for example if they want to:

This allows end users to save their preferences, improves usability and reduces the likelihood of error. It also requires less administrative work than cloning.

To enable users to save sessions for a disclosure plugin, at least one attribute must be set to allow overrides , on either the global or managed-system-policy level.

This capability is not available for Copy, Display, or Run command plugins.

The Functional.pam_saved_session_policy component allows administrators to configure global saved sessions that are available for all end users.

To learn how to save sessions as an end user, see Saving sessions in the User Guide.

Configuring pam_saved_session_policy

To configure saved session policies:

If there are multiple entries with the same SavedSessionName value, those entries will be treated as the same saved session.

If there are multiple entries with the same SavedSessionName value but different SavedSessionCategory and SavedSessionNotes values, the value from the latest entry will be used (unless the value is empty).

If any entries are modified or added to an existing saved session, end-users will need to remove the existing saved session from the Privileged Access App in order to use the saved session with the updated settings.

The policy and action tables are in a linked design and rely on each other to deliver disclosure options to requesters. The disclosure filter policy table is used to provide access to disclosure options, whereas the associated disclosure filter action table is used to set specific attributes of the disclosure options (timeouts and so on)

Bravura Privilege executes all actions that reference (via a foreign key) a policy that passes. This design allows a user to configure a single policy that activates one or more disclosure plugins.

Not all columns in a policy or action table rule have to be populated, only the ones the rule purpose requires. If multiple columns are populated for the rule, the condition is an AND, whereby all conditions of the rule must be true for the rule to trigger its action. If OR logic is needed, add separate rules for each condition requirement.

Like all policy tables, the last policy that passes wins. If you have conflicting actions, the last one overwrites any previous conflicting actions.

Policy Engine terminology:

Disclosure Filter Policy Table

The following table outlines the supported options and usage of the fields in the pam_disclosure_filter_policy extdb table.

The ComponentOwnerFQN field, included in all external data store tables, shows the name of the component providing specific rows to a table.

Disclosure Filter Action Table

The following table outlines the supported options and usage of the fields in the pam_disclosure_filter_action extdb table.

The ComponentOwnerFQN field, included in all external data store tables, shows the name of the component providing specific rows to a table.

Disclosure Filter Policy Examples

Restricting display of passwords to Windows platforms only and limiting disclosure

Click below to view a demonstration where disclosure filter rules are altered so display of passwords is restricted to Windows platforms only, with a time limit of 5 minutes. A Windows and Linux account are then checked out to demonstrate that only the Windows account can display passwords, and it remains visible for only the configured time.

Adding a new disclosure to a checkout

This is an example of adding the Remote Desktop disclosure plugin to a checkout for a user accessing a Windows server. This example assumes that the default Remote Desktop disclosure plugin has not been changed.

Policy Table:

Action Table:

Setting up AD disclosure based on group membership

This is an example of adding multiple disclosure plugins based on the user’s group membership. This example assumes that you have managed the Active Directory security group “security_appliance_admins” and run Auto discovery. This example also assumes you have configured new disclosure plugins in Bravura Privilege for Cisco Iron Port and Blue Coat.

This example is going to look at the platform the account exists on, and the security group. Once it confirms that the account being accessed exists on an Active Directory domain and a security group, it will add both Cisco Iron Port and Blue Coat to the list of disclosure controls available to the user.

Generally, this type of policy would be paired with a generic Active Directory policy that would add a disclosure control(s) that all users have access to, such as Remote Desktop.

Policy Table:

Action Ironport Policy:

Action Bluecoat Policy: