Modes: push and local service
Bravura Privilege manages systems using two modes: push mode and local service mode (previously known as pull mode).
Ensure you only use one mode to manage a system. If a system is managed by both push and local service modes you will end up with duplicate managed accounts. Bravura Privilege will be unable to determine which managed account contains the current password and consequently, password history and auditing issues. For more details, see Do not double target .
This section explains the differences between the modes, and how to determine which mode to use.
Push mode
In push mode, Bravura Privilege performs remote password resets using the Privileged Access Manager Service.
Changes at the Bravura Privilege server typically trigger immediate actions on managed systems; whereas, in local service mode, actions are triggered when the workstation connects to the server at the end of the next polling interval.
A system can be managed in push mode when it is manually added as a target system, or when it is discovered on a domain. Accounts can also be managed manually or during auto-discovery.
Choose push mode if you:
Do not want a software footprint on your servers or workstations
Require real time” integration
Want to manage passwords on systems other than Windows
Want to manage SSH public keys on Unix systems
Have systems in a DMZ that cannot connect to your Bravura Privilege server
Local service mode
In local service mode, you install the Local Workstation Service on the managed system. Local service mode works as follows:
After installing on the system to be managed, the Local Workstation Service waits a random amount of time.
This prevents large numbers of Local Workstation Services, installed during a mass deployment, from contacting the Bravura Privilege server simultaneously.
The Local Workstation Service then connects to the pamlws on the Bravura Security Fabric server over HTTP or HTTPS (recommended) and registers itself with Bravura Security Fabric . This initiates the discovery process, during which the system is listed as a discovered object, and evaluated against import rules. This process is repeated until the system passes an import rule and is managed, or is disabled.
Once a system is discovered and managed, the Bravura Security Fabric server periodically checks on what needs to be done, based on workflow requests and password expirations, and sets the necessary flags for it.
The Local Workstation Service periodically connects to, or polls, the pamlws over HTTP or HTTPS to check on any tasks, such as listing users and attributes, changing a password, or adding and removing users from groups.
The Local Workstation Service performs the assigned task, if any, and sends the required data back to the pamlws at the next poll. This may either be the list of users, groups and attributes, or success and failures on other tasks. It will wait a configured amount of time before connecting to the Bravura Security Fabric server again.
Local service mode is only available for Windows systems; however, a plugin architecture supports applications running on Windows.
Choose local service mode if you have:
Many Windows machines that are not permanently connected to the domain (laptops, workstations etc.)
Systems that aren't always on or are periodically unavailable.
Servers that do not allow inbound access due to firewall rules or other networking restrictions. Installing Local Workstation Service on these servers will allow outbound connections to the Bravura Security Fabric server.
Caution
Many desktops are left on and locked so that users can resume their work the next day; if these are contactable via normal auto discovery (
psupdate
), do not add the Local Workstation Service to these machines.
When users request privileged access on local service mode systems, group and account operations may take longer than on push mode systems, since Bravura Security Fabric is required to wait for communication from the local workstation.
Legacy terminology of pull mode may be referenced in binary files and add-on installer names, glossaries, customer solution documents, language tags used in the product, and some are hard-coded in the log entries.