Verify Privilege Vault and Verify Privilege Manager Example Architectures
Verify Privilege Vault and Verify Privilege Manager Integration
The benefits of Verify Privilege Manager (PM) integration with Verify Privilege Vault (SS) include:
-
SS can be the authentication source for PM. This:
- Adds SS MFA login options to PM log ons.
- Gives one place for role assignments for both products.
-
PM can use SS as a storage container.
When you use SS as the authentication source for PM, role permissions assigned in SS apply and determine user-access levels in PM.
When using SS as a storage container for PM credentials:
- PM creates secrets for each local credential managed by PM.
- PM creates secrets for each configuration credential stored in PM. This includes the credentials PM uses for foreign system integration, such as AD sync and ServiceNow.
- PM pulls any changes from secrets. PM only stores the credentials in SS to use SS workflow options and for users to view them.
This integration is supported when the two applications are installed on the same server or separate servers, as long as PM can communication with SS via the SS REST API.
Single Site with Minimum HA
Overview
-
Minimum-cost configuration with no shared storage requirement.
-
Verify Privilege RabbitMQ Helper (for SS) is installed on the SS Web servers (typically in a cluster).
-
Single-site design with no native DR capacity. DR can be provided by VM replication if subnets are spanning locations. Otherwise Re-IP + DNS changes may be necessary.
-
PM is installed on separate Web servers.
-
PM can integrate with SS for authentication and credential storage.
-
PM can reside on the same database servers as SS or on separate ones, but SS and PM should not share the same database.
Due to SQL basic availability groups with the Standard Edition, you need to have multiple SQL instances and a separate AlwaysOn availability group configuration.
Requirements
- SQL Standard Edition with a basic availability group configuration.
- You can use local load balancers for all Web server nodes.
- For SQL to stay online during single-node unplanned failures, you must configure a file-share witness for SQL quorum voting.
Diagram
Figure: Single Site with Minimum HA
Single Site with Minimum HA and Separate Verify Privilege RabbitMQ Helper
Overview
-
Minimum-cost HA configuration with no shared storage requirement.
-
Verify Privilege RabbitMQ Helper (for SS) is installed on the SS Web servers (typically in a cluster).
-
Single-site design with no native DR capacity. DR can be provided by VM replication if subnets are spanning locations. Otherwise Re-IP + DNS changes may be necessary.
-
PM is installed on separate Web servers.
-
PM can integrate with SS for authentication and credential storage.
-
PM can reside on the same database servers as SS or on separate ones, but SS and PM should not share the same database.
Due to SQL basic availability groups with the Standard Edition, you need to have multiple SQL instances and a separate AlwaysOn availability group configuration. -
You can use a separate Web reverse proxy or Azure service bus configuration for Verify Privilege Manager agent TCP 443 communication.
Requirements
- SQL Standard Edition with a basic availability group configuration.
- You can use local load balancers for all Web server nodes.
- For SQL to stay online during single-node unplanned failures, you must configure a file-share witness for SQL quorum voting.
Diagram
Figure: Single Site with Minimum HA and Separate Verify Privilege RabbitMQ Helper
Multiple Site with Manual Failover
Overview
-
Minimum-cost HA configuration with no shared storage requirement.
-
Verify Privilege RabbitMQ Helper (for SS) is installed on the SS Web servers (typically in a cluster).
-
SQL AlwaysOn configurations are either synchronous or asynchronous for the SS database and asynchronous only for the PM database.
-
DR site acts as a temporary site only with no long-term use. Services in DR site being down can incur downtime.
-
PM is installed on separate Web servers.
-
PM can integrate with SS for authentication and credential storage.
-
PM can reside on the same database servers as SS or on separate ones, but SS and PM should not share the same database.
Due to SQL basic availability groups with the Standard Edition, you need to have multiple SQL instances and a separate AlwaysOn availability group configuration. -
You can use a separate Web reverse proxy or Azure service bus configuration for Verify Privilege Manager agent TCP 443 communication.
Requirements
- SQL Standard Edition with a basic availability group configuration.
- If global load balancers are not available due to cost or limited infrastructure, you can use local load balancers for all Web server nodes, but DNS change may be required if primary location goes offline.
- For SQL to stay online during single-node unplanned failures, you must configure a file-share witness for SQL quorum voting.
Diagram
Figure: Multiple Site with Manual Failover
Multiple Site with Manual Failover and Separate Verify Privilege RabbitMQ Helper
Overview
-
Minimum-cost HA configuration with no shared storage requirement.
-
Verify Privilege RabbitMQ Helper (for SS) is installed on the SS Web servers (typically in a cluster).
-
SQL AlwaysOn configurations are either synchronous or asynchronous for the SS database and asynchronous only for the PM database.
-
DR site acts as a temporary site only with no long-term use. Services in DR site being down can incur downtime.
-
PM is installed on separate Web servers.
-
PM can integrate with SS for authentication and credential storage.
-
PM can reside on the same database servers as SS or on separate ones, but SS and PM should not share the same database.
Due to SQL basic availability groups with the Standard Edition, you need to have multiple SQL instances and a separate AlwaysOn availability group configuration. -
You can use a separate Web reverse proxy or Azure service bus configuration for Verify Privilege Manager agent TCP 443 communication.
Requirements
- SQL Standard Edition with a basic availability group configuration.
- If global load balancers are not available due to cost or limited infrastructure, you can use local load balancers for all Web server nodes, but DNS change may be required if primary location goes offline.
- For SQL to stay online during single-node unplanned failures, you must configure a file-share witness for SQL quorum voting. We recommend a cloud witness.
Diagram
Figure: Multiple Site with Manual Failover and Separate Verify Privilege RabbitMQ Helper
Multiple Site with Automatic Failover
Overview
-
Improved HA configuration with no shared storage requirement.
-
Verify Privilege RabbitMQ Helper (for SS) is installed on the SS Web servers (typically in a cluster).
-
SQL AlwaysOn configurations are either synchronous or asynchronous for the SS database and asynchronous only for the PM database.
-
DR site acts as a temporary site only with no long-term use. Services in DR site being down can incur downtime.
-
PM is installed on separate Web servers.
-
PM can integrate with SS for authentication and credential storage.
-
PM can reside on the same database servers as SS or on separate ones, but SS and PM should not share the same database.
Due to SQL basic availability groups with the Standard Edition, you need to have multiple SQL instances and a separate AlwaysOn availability group configuration. -
You can use a separate Web reverse proxy or Azure service bus configuration for Verify Privilege Manager agent TCP 443 communication.
Requirements
- SQL Standard Edition with a basic availability group configuration.
- If global load balancers are not available due to cost or limited infrastructure, you can use local load balancers for all Web server nodes, but DNS change may be required if primary location goes offline.
- For SQL to stay online during single-node unplanned failures, you must configure a file-share witness for SQL quorum voting. We recommend a cloud witness.
Diagram
Figure: Multiple Site with Automatic Failover
Multiple Site with Automatic Failover and Separate Verify Privilege RabbitMQ Helper
Overview
-
Improved HA configuration with no shared storage requirement.
-
Verify Privilege RabbitMQ Helper (for SS) is installed on dedicated servers (typically in a cluster).
-
SQL AlwaysOn configurations are either synchronous or asynchronous for the SS database and asynchronous only for the PM database.
-
DR site acts as a temporary site only with no long-term use. Services in DR site being down can incur downtime.
-
PM is installed on separate Web servers.
-
PM can integrate with SS for authentication and credential storage.
-
PM can reside on the same database servers as SS or on separate ones, but SS and PM should not share the same database.
Due to SQL basic availability groups with the Standard Edition, you need to have multiple SQL instances and a separate AlwaysOn availability group configuration. -
You can use a separate Web reverse proxy or Azure service bus configuration for Verify Privilege Manager agent TCP 443 communication.
Requirements
- SQL Enterprise Edition.
- Global and local load balancers.
- If global load balancers are not available due to cost or limited infrastructure, you can use local load balancers for all Web server nodes, but DNS change may be required if primary location goes offline.
- For SQL to stay online during single-node unplanned failures, you must configure a file-share witness for SQL quorum voting. We recommend a cloud witness.
- Distributed Engine Ports.
- SQL Quorum Ports.
Diagram
Figure: Multiple Site with Automatic Failover and Separate Verify Privilege RabbitMQ Helper
Best Multiple Site with Automatic Failover and Separate Verify Privilege RabbitMQ Helper
Overview
-
Best HA configuration with no shared storage requirement.
-
Verify Privilege RabbitMQ Helper (for SS) is installed on dedicated servers (typically in a cluster).
-
SQL AlwaysOn configurations are either synchronous or asynchronous for the SS database and asynchronous only for the PM database.
-
DR site acts as a temporary site only with no long-term use. Services in DR site being down can incur downtime.
-
PM is installed on separate Web servers.
-
PM can integrate with SS for authentication and credential storage.
-
PM can reside on the same database servers as SS or on separate ones, but SS and PM should not share the same database.
Due to SQL basic availability groups with the Standard Edition, you need to have multiple SQL instances and a separate AlwaysOn availability group configuration. -
You can use a separate Web reverse proxy or Azure service bus configuration for Verify Privilege Manager agent TCP 443 communication.
Requirements
- SQL Enterprise Edition.
- Global and local load balancers.
- If global load balancers are not available due to cost or limited infrastructure, you can use local load balancers for all Web server nodes, but DNS change may be required if primary location goes offline.
- For SQL to stay online during single-node unplanned failures, you must configure a file-share witness for SQL quorum voting. We recommend a cloud witness.
- Distributed Engine Ports.
- SQL Quorum Ports.
Diagram
Figure: Best Multiple Site with Automatic Failover and Separate Verify Privilege RabbitMQ Helper