Architectural and Design Considerations

You can view the Secret Server Architecture section. These reference architectures are, at minimum, refreshed every year and are created by our Professional Services Solutions Architect team. For this section, we provide some high-level architecture and design considerations that may help you design a more successful Secret Server or Secret Server Cloud installation.

The following recommendations are primarily for Secret Server on-premises. For Secret Server Cloud customers, many of the recommendations are still relevant, even though you only have control over increasing distributed engines—the only Secret Server infrastructure you physically control when using Secret Server Cloud.

Consider some key questions about your SLA requirements for the application:

  • What are the RPOs and RTOs for the application?
  • Is high availability or disaster recovery required?
  • Are you going to purchase Secret Server or Secret Server Cloud?

Answering these helps determine what initial infrastructure is needed for your environment. You can then look at the reference architectures to help select a variation of the reference architecture that works best for your requirements.

Many customers take a posted variation and alter it to meet their own needs.

When the Professional Services team works with our customers, we gather both architectural and stakeholder requirements to come up with a design that is sized correctly to meet all business needs. If you are planning to design Secret Server's architecture yourself, we suggest planning additional infrastructure based on feature utilization needs in the following order:

Session Recording

This is the most process- and memory-intensive feature of the product if it is used heavily. We recommend reviewing Caveats and Recommendations when planning to implement this feature, as it may require additional hardware or Web servers. Below are a few questions to ask yourself:

  • Is the organization planning to use session recording and to what capacity?
  • How many secrets may have session recording enabled?
  • How many session recordings may occur concurrently?

We recommend only enabling session recording on secrets that absolutely need it—such as those with compliance or legal requirements. Otherwise, we recommend enabling session recording only on high value, high impact assets. This includes "global" admin accounts, domain administrator accounts, and other high-level privileged assets within your environment. This should minimize additional infrastructure just for session recording .

Discovery

This is another feature that can have a large impact on a Secret Server environment. A large enterprise discovering thousands of systems may require additional Web servers or distributed engines. Below are a few questions to ask yourself:

  • How many systems do you intend to discover?
  • How often should discovery run?
  • How quickly does discovery need to complete?

We recommend using out-of-the-box discovery sources where possible. Since discovery cannot be scheduled to run at a specific time, consider enabling discovery for the first time during off-peak hours so it will run around the same time each day or week. If discovering a large number of systems, ensure you have ample Web servers and engines to handle the load. For example, increasing CPU count for each distributed engine can help distributed engines do more work in parallel.

Please see Discovery Best Practices for details.

API Use Case

Employing multiple integrations with our product may impact a Secret Server environment. Below are a few questions to ask yourself:

  • What integrations do you intend to use with Secret Server?
  • What is the total number of API calls you anticipate per second, hour, or day?

We recommend that if you require several integrations with Secret Server where a high volume of API calls is anticipated, carefully consider how to configure your Web servers. You may want to have some Web servers dedicated to API use that have all Web roles explicitly disabled. You could place several such Secret Server Web servers in a load balancer configuration.

Remote Password Changes and Heartbeats

RPC and heartbeats may impact a Secret Server environment if used heavily. Below are a few questions to ask yourself:

  • How many secrets RPC?
  • How often should passwords be changed?
  • How many RPC retries should be attempted?
  • How often should we perform heartbeats?

We recommend carefully planning what types of secrets require different password changing schedules based on your company's information security policy. Generally, setting a large number of retry attempts for an RPC is not a good idea. The same goes for heartbeats. Match these settings to the business use case, such as 10 password retry attempts and having heartbeats occur once per day. These small refinements can greatly reduce the load on Secret Server. If you determine you need aggressive RPC and heartbeat schedules, consider having additional Web servers and distributed engines to handle the load.

Proxying

Heavy proxying can impact Secret Server infrastructure. Below are a few questions to ask yourself:

  • How many systems are proxied?
  • Are they SSH or RDP connections?
  • What is the concurrent need?

We recommend proxy connections go through a distributed engine whenever possible. This offers a security advantage because ports, such as 3390 or 22, are not open inbound directly to your Web servers. You can review the SSH Proxy Configuration section to size proxy requests.

General On-Premise Considerations

The areas mentioned below are often where we spend the most time with customers who have spent professional services time performing architectural health checks. These are the main areas we typically improve:

For the highest scalability and reliability, Delinea recommends using RabbitMQ. MemoryMQ is an easier but less capable alternative and can be used for trials and proof of concepts but should not be used for production environments.
  • Ensure that you have a database maintenance plan in place for Secret Server. It should be implemented or reviewed by your organization's DBAs. Adjusting the data retention settings is not enough and does not substitute for having a maintenance plan.

    • Ensure that you have a maintenance plan in place to detect and re-build Indexes that are fragmented. This should be implemented or reviewed by your organization’s DBA.

    Note that your database maintenance plan may affect overall performance. See SQL Server Performance Improvement for more details.

  • Ensure that RabbitMQ clustering configurations have work distribution policies in place. In most engagements, we use the AutomaticSyncMode policy.
  • When designing multi-site, single-instance Secret Server implementations, be cautious when configuring Web servers and enabling roles on all Web server nodes when inter-location latency is high (50 ms or greater).
  • When using the "local" site for Web processing when also using sites with distributed engine processing, consider using engine processing for the local site too. In most cases, when using both Web and engine processing, you are using both a built-in message broker (MemoryMQ) with (RabbitMQ).
  • Consider having dedicated systems for Secret Server components, as proposed in our mid-range reference architectures. If using RabbitMQ, put it on a dedicated system that is not shared with the distributed engine service. Secret Server
  • For large environments where discovery, RPC, and heartbeats will be used simultaneously, careful consider when to run discovery. Discovery can compete with RPC requests when both features are using the same site. For large environments, you may want to have a dedicated site and distributed engines for discovery and a separate dedicated site for secrets.