Disaster Recovery Process

TIP:

Find your location and Contact Us in case of emergency.

In a PAS deployment, failover is the process of switching operations from a primary (active) system to a secondary (Disaster Recovery, DR) system when the primary becomes unavailable. On the other hand, failback is the process of returning operations from the Disaster Recovery (DR) environment back to the primary system after the original issue has been resolved.

Having a failover process is critical because:

  • It ensures continuous privileged access

  • It minimizes downtime during outages or disasters

  • It preserves audit logging and session continuity

  • It supports business continuity and compliance requirements

This guide provides the high-level, step-by-step procedure for failing over CPAM services to a Disaster Recovery environment.

IMPORTANT:

Contact Imprivata Support by phone using the number of your location.

BEST PRACTICE:

Imprivata recommends that you contact Raise a Support Ticket to test your environment for failover. It is not recommended that you test your environments by yourself.

Failover Process Requirements

Before performing failover, ensure your environment is properly designed and prepared:

To support failover, your CPAM deployment must include:

  • A primary CPAM appliance to handle access, sessions, and audit logging in day-to-day operations.

  • A Disaster Recovery (DR) CPAM appliance that functions as a standby or secondary system. The DR appliance maintains synchronized configuration and data.

  • Gatekeeper installed in customer or internal networks. These access points must be able to reconnect to both appliances (the primary and the DR appliance).

  • Recent backups of your configuration, credentials (if applicable), and audit data.

  • DNS hostname mappings for all your CPAM components.

NOTE:

Load balancers are not supported in CPAM.
Virtual IPs (VIPs) are only required for High Availability configurations.

To support failover, ensure the disaster recovery appliance supports the same connectivity as the primary appliance in production. Read the System Requirements for more information.

Failover Process Guide

The following steps outline a typical failover procedure. Exact steps may vary depending on your architecture.

  1. Validate the Failure Condition: Confirm the primary appliance is unavailable. Signs include inaccessible UI, Gatekeeper do not check in, or sessions continuously fail.
    Ensure the issue is not related to connectivity or DNS before proceeding.

  2. Notify Stakeholders: Inform your internal IT, Security, Vendors, Internal Users, and Customers that service may be affected. If possible, configure a System Message banner in the UI.

  3. Contact Imprivata Support: Imprivata recommends that you follow the failover process with Imprivata Support.

    1. Contact Imprivata Support by phone for failover for disaster recovery.

    2. Raise a Support Ticket when performing failover testing .

  4. Validate Core Functionality: Test the following features:

    • User login, including local authentication, SSO, and AD.

    • Gatekeeper connectivity.

    • Connection Manager session launch.

    • Browser-Based sessions (if configured).

    • Credential injection (if configured).

  5. Validate Connections and Integrations (if configured): Ensure your integrations persisted the failover, including:

    1. Nexus connections for CPAM and VPAM integration.

    2. Syslog connection for log transfers.

    3. AD, LDAP, or SAML integrations for authentication.

  6. Resume Operations: Inform stakeholders and users, and continue to monitor session activities, system performance, and audit logs.

To reduce down time and prevent risks, ensure you comply with the following best practices:

  • Regularly Perform Failover Testing: Testing ensures your team knows the process and verifies that systems, integrations, and dependencies actually work during a real disaster.

  • Keep Gatekeepers and Gateways Updated and Registered: Updated components ensure compatibility and security, while proper registration guarantees they can reconnect to the DR system without manual intervention.

  • Document DNS Records, IPs, and Access Credentials: Clear documentation reduces delays and confusion during an outage, enabling faster and more accurate execution of failover steps.

    IMPORTANT:

    Customers that manage their own DNS-A record should ensure TTL is at 10 minutes or less to ensure enough time for DNS to settle in the event of a DNS change.

NOTE:

Failback to primary systems follows the exact same process as failover, with the target environment being the primary appliance, instead of the secondary.