BeyondTrust Password Safe common mistakes
BeyondTrust Password Safe · Understand the traps and how to avoid them.
Treating the Password Safe appliance as the component that initiates password changes, rather than the Password Safe client or central policy engine that triggers the change through the functional account.
Candidates conflate the management appliance with the execution engine; the appliance hosts the vault and policy, but rotation is performed by a functional account using the platform's remote management protocols.
What to do instead
Map the rotation workflow: policy defines the schedule, the functional account executes the change on the target, and the vault stores the new secret. Review the architecture diagram and identify which component performs each step.
Assuming a single Password Safe installation can manage assets across multiple network segments without additional components, and failing to identify the role of the Password Safe Gateway or similar proxy.
Candidates overlook that the central appliance may not have direct network access to all managed systems, requiring a gateway to broker connections.
What to do instead
Study the deployment topologies: single appliance, high availability, and distributed gateway. For each, note which component initiates connections and where credentials traverse.
Confusing the concepts of a managed system, a managed account, and a functional account, and misassigning which credential is rotated by which process.
The terms are similar and the UI groups them; candidates memorize labels without understanding that functional accounts are used to perform rotations on managed accounts, and managed accounts are the credentials being vaulted.
What to do instead
Create a table: managed system (target host), managed account (credential to vault), functional account (credential used by Password Safe to perform actions). Practice classifying scenarios into these categories.
Believing that password rotation occurs only on a fixed schedule and ignoring event-driven or on-demand rotation triggers such as check-in, password release, or manual initiation.
Candidates focus on the schedule field in policy and miss the broader rotation policy settings that include triggers and propagation.
What to do instead
Review the rotation policy options: scheduled, on check-in, on release, and manual. For each, identify the business scenario where it is appropriate and the audit evidence it generates.
Assuming that assigning a user to a role automatically grants access to all accounts in that role, without considering access policies, approval workflows, and account grouping.
Role-based access is only one layer; effective access is the intersection of role assignment, access policy, and approval. Candidates stop at the role assignment step.
What to do instead
Trace the access decision path: user -> role -> access policy -> account or account group -> approval requirement. Build a decision tree and test it against sample scenarios.
Misconfiguring approval workflows so that the approver is also the requester, or failing to define escalation and timeout behavior, leading to self-approval or stalled requests.
Candidates configure the minimum to make a request work and do not test separation of duties or timeout settings.
What to do instead
Design approval workflows with explicit approver groups, self-approval prevention, and timeout escalation. Test with a request from a user who is also an approver and verify the request is blocked or routed to another approver.
Overlooking session management settings such as session recording, keystroke logging, and session termination, and assuming that access alone provides sufficient audit evidence.
Candidates equate access control with session control; session policies are configured separately and may be disabled by default.
What to do instead
Review session policy options: recording, monitoring, and termination. For each, identify the audit record produced and the compliance requirement it satisfies. Practice enabling and verifying a session recording.
Failing to distinguish between functional account permissions and managed account permissions when troubleshooting rotation failures, and granting excessive privileges to the functional account.
Candidates grant domain admin to the functional account as a shortcut, which works in the lab but violates least privilege and masks permission issues.
What to do instead
Document the minimum permissions required for each functional account per platform (e.g., local admin on Windows, sudo rights on Linux). Test rotation with least privilege and review the functional account's rights.
Ignoring the difference between platform-dependent and custom platforms, and attempting to use a built-in platform for a system it does not support, resulting in failed rotations or incorrect password policies.
Candidates select the first platform in the list without verifying compatibility, and do not know how to create or modify a custom platform.
What to do instead
Review the platform library and the process for creating a custom platform: define the connection protocol, password change command, and verification command. Test with a non-standard system.
Assuming that all events are audited by default and that reports are prebuilt for every compliance requirement, and failing to configure audit retention or custom reports.
Candidates rely on default logging and do not explore the audit configuration or report builder, leading to gaps in evidence.
What to do instead
Review the audit event categories and retention settings. Practice creating a custom report for a specific compliance requirement, such as privileged access to a database, and verify the report includes the necessary fields.