Beyond Trust Capacity Planning Guide

Tech Brief
Capacity Planning Guide

BeyondTrust’s PowerBroker and Retina Solutions
Version 2.0 December 2016
Capacity Planning Guide 0

© November 2016. BeyondTrust Software, Inc.
Table of Contents
Introduction 3
Appliances 3
BeyondTrust UVM20 3
BeyondTrust UVMV20 4
BeyondTrust UVM50 5
Retina 651 5
Beyondinsight (BI) 6
Base Installation 6
Analytics and Reporting (A&R) 7
PowerBroker 7
PowerBroker Unix Linux (PBUL) and PowerBroker Sudo (PBSudo) 7
PowerBroker Password Safe (PBPS) 21
PowerBroker Identity Services (PBIS) 22
PowerBroker for Windows (PBW) 38
PowerBroker for Mac (PBMac) 46
PowerBroker Endpoint Protection Platform (PBEPP) 47
PowerBroker Auditing and Security Suite (PBASS) 47
Retina 48
Retina Network Security Scanner (RNSS) 48
Retina Host Security Scanner (RHSS) 50
Retina CS (RCS, BeyondInsight) 50
Retina Protection Agent (RPA) 50
Infrastructure 51
Enterprise Update Server (EUS) 51
Event Collector Role (EC) 51
Worker Node Role (WN) 52
Conclusion 52
Appendix A Performance Testing Results 53
About BeyondTrust 55
Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

1
© 2016 Beyond Trust. All Rights Warranty
Reserved. This document is supplied on an "as is" basis with no
warranty and no support.
This document contains information, Limitations of Liability

which is protected by copyright. No In no event shall BeyondTrust be liable for errors
part of this document may be contained herein or for any direct, indirect, special,
photocopied, reproduced, or incidental or consequential damages (including lost
translated to another language profit or lost data) whether based on warranty,
without the prior written consent of contract, tort, or any other legal theory in
BeyondTrust. connection with the furnishing, performance, or use
of this material.
The information contained in this document is

subject to change without notice.
No trademark, copyright, or patent licenses are

expressly or implicitly granted (herein) with this
white paper.
For the latest updates to this Disclaimer

document, please visit: All brand names and product names used in this
http://www.beyondtrust.com document are trademarks, registered trademarks, or
trade names of their respective holders.
BeyondTrust is not associated with any other
vendors or products mentioned in this document.

2
INTRODUCTION
This document describes capacity planning requirements per module for the PowerBroker and
Retina family of solutions by BeyondTrust. This document considers each module operating
independently and considers scalability, throughput, and storage requirements in an average
deployment. Assumptions for the environment are documented below and do not consider
product interaction between modules nor the cumulative effect for operating multiple modules
on the same asset and by multiple users simultaneously. It is reasonable to assume the results
are additive in these situations for capacity planning purposes due to the number of
permutations possible. Therefore, when more one module is used for capacity planning, sum
the requirements, except when specifications are for maximums use the lowest value, and
consider that resources should be for peak loads as well as potential sustained utilization.
APPLIANCES
BeyondTrust offers a full line of integrated IT risk management appliances (UVM) dedicated to
vulnerability management, privileged account management, endpoint protection, configuration
compliance, patch management, and regulatory compliance management. These appliances
provide multi-platform network discovery, automated vulnerability and risk assessment,
centralized policy enforcement, least privilege reporting, and powerful compliance and
regulatory audit capabilities.
BeyondTrust assumes the following hardware and software for all environments based on the
UVM series of appliances in performing capacity planning:
BeyondTrust UVM20
The BeyondTrust UVM20 Security Management Appliance delivers pre-installed and pre-
configured vulnerability and privileged account management capabilities, combining
BeyondTrust’s Retina Network Security Scanner, PowerBroker® Endpoint Protection Platform,
PowerBroker for Windows, and PowerBroker for Mac under the BeyondInsight™ centralized
management, reporting and analytics console.
BeyondTrust Security Management Appliance UVM20 [Link]
Operating System Microsoft Windows 2012 R2 Server Standard

Database Microsoft SQL Server 2014 Standard Edition
Processor Intel Xeon E5-2620 v2 2.0GHz (6 Core) (R720) or
Intel Xeon E5-2620 v3 2.4GHz (6 Core) (R730)
Memory 32GB (2 x 16GB)
Hard Drive 4 x 1TB (RAID 1+0 – 2TB operational storage)
Remote Access iDRAC 8 Enterprise

3
Network Broadcom 5720 QP 1GB Network Daughter Card
Form Factor 2U Rack Mount
Power Dual Redundant Power Supply Units (PSUs), 495W
Appliance Requirements 110-220 VAC 50-60Hz, TCP/IP v4 Static Address
Appliance Capacity
 Maximum Active Assets: 20,000
 Maximum Administrative Console Concurrent Users: 10
 Default Normalized Data Retention: 90 Days
 Default Raw Data Retention: 7 Days
 Maximum Events per Day: 250,000
 Maximum PowerBroker or Retina Agents: 5,000
BeyondTrust UVMV20
The BeyondTrust UVMv20 Security Management Appliance is a pre-installed and pre-
configured virtual appliance for vulnerability and privileged account management based on all
the capabilities of the UVM20 physical appliance. This virtual appliance is fully licensed and is
available for Microsoft Hypervisor-V and VMware ESXi and NSX.
BeyondTrust Security Management Virtual Appliance UVMv20 [Link]
Operating System Microsoft Windows 2012 R2 Server Open Volume License (OVL) or
Retail License Package (Depending on Localization)
Database Microsoft SQL Server 2014 Standard Edition Open Volume License
(OVL) or Retail License Package (Depending on Localization)
Processor Maximum Dual CPU / 4 Cores for Microsoft License Limitation
Memory 32GB Minimum (Required), 4TB Maximum
Form Factor Virtual Image: VMware VMDK for ESXi 5.0 or higher, or and Microsoft
VHD for Hypervisor-V (2008-R2 and 2012)
Appliance Capacity

4
BeyondTrust UVM50
The BeyondTrust UVM50 is an appliance with the same vulnerability and privileged account
management software as the UVM20; however, it ships with significantly increased scalability
based on additional high performance hardware.
BeyondTrust Security Management Appliance UVM50 [Link]
Operating System Microsoft Windows 2012 R2 Server Standard

Database Microsoft SQL Server 2014 Standard Edition
Processor 2 x Intel Xeon E5-2640 v2 2.0GHz (8 Core) (R720) or
2 x Intel Xeon E5-2640 v3 2.6GHz (8 Core) (R730)
Memory 128GB
Hard Drive 8 x 1TB (RAID 1 – 4TB Operation Storage)
Network Broadcom 5720 QP 1GB Network Daughter Card
Remote Access iDRAC 8 Enterprise
Power Dual Redundant Power Supply Units (PSUs), 750W
Appliance Requirements 110-220 VAC 50-60Hz, TCP/IP v4 Static Address
Appliance Capacity
Retina 651
The Retina Security Management Appliance 651 is designed to provide complete coverage for
vulnerability assessment and asset discovery for any size network environment.
Retina Security Management Appliance 651 (VA651) [Link]
Operating System Windows 8.1 Embedded

Processor Intel Pentium G3420 3.2GHz Dual Core
Memory 8GB RAM
Hard Drive 500GB 7200k RPM SATA III
Network Dual 10/100/1000 Mb Ethernet
5
Appliance Requirements 110-220 VAC 50-60Hz
TCP/IP v4 Static Address
Appliance Capacity
 Absolute Maximum Assets per Discovery Scan: Class A
 Recommended Maximum Assets per Vulnerability Scan Job: 10,000
 Maximum Concurrent Administrative Users: 1
 Default Number of Simultaneous Scan Targets: 24
 Maximum Number of Simultaneous Scan Targets: 128
Multiple UVM appliances can be connected together using Roles to scale beyond the
specifications per appliance. This scalability can be extended event further using software
versions of the solution and remote installations of Microsoft SQL
BEYONDINSIGHT (BI)
BeyondInsight enables enterprise-services for privileged account management, distributed
vulnerability assessment, and remediation (patch management). The solution can be deployed
to meet virtually any operational requirement including distinct silo structures, air gapped
environments, and provide summaries up to a global security view using distributed
components and Roles. Capacity planning requirements need to be considered at each tier of
an architecture from the bottom up.
Base Installation
BeyondInsight can be implemented fully self-contained or distributed. For a basic installation,
fully self-contained in a single appliance (or matching software installation), these metrics
should be used for capacity planning:
Metric / UVM Model UVM20 UVMv20 UVM50 VA651
Maximum Active Assets 20,000 20,000 50,000 65,000

Maximum Number of Concurrent 10 10 20 NA
Logged In Users
Maximum number of smart rules 150 150 500 NA

6
Analytics and Reporting (A&R)
BeyondInsight contains a structured data warehouse for analytics and reporting based on
Microsoft SQL OLAP cubes. For a basic installation, fully self-contained in a single appliance (or
matching software installation), these metrics should be used for capacity planning:
Maximum Assets 20.000 20,000 50,000 NA

Logged In Users
Maximum Number of Subscriptions 200 200 500 NA
Average Time to Complete the Daily 90 Minutes 90 Minutes 60 Minutes NA
Job
POWERBROKER
PowerBroker is a family of solutions from BeyondTrust that delivers complete compliance for
privileged access management (PAM). Each solution can operate standalone or centrally
managed with BeyondInsight. For capacity planning, the modules will address both aspects of
functionality when feasible.
PowerBroker Unix Linux (PBUL) and PowerBroker Sudo (PBSudo)

PowerBroker for Unix & Linux and PowerBroker Sudo are user space network-based solutions
for fine-grained privileged delegation and auditing in Unix/Linux environments whether on
premise or in the cloud. PowerBroker enables granular policy control over privileged account
user behavior and provides optional details for all activities in BeyondInsight. For capacity
planning, details regarding each component are referenced below as well is standalone
integration into BeyondTrust appliances.
Submit Host
Submit hosts are the client systems that communicate with the Policy and Log servers. An
agent is installed on these systems to communicate with the Policy server for Authorization
(Auth/Z) of privileged command requests, and if authorized, a connection to the Log servers for
session logs is created. The agent footprint is very small, and the agent remains idle until it is
called, so it does not increase load on the server on which it is installed. These hosts can be
virtual or physical.
UNIX/Linux host in the customer environment
Operating System Most currently supported *NIX Operating systems

Database None Required

7
Processor Varied in Customer Environment
Memory Varied in Customer Environment
Form Factor Varied in Customer Environment
Firewall Ports Required 24345 24346 24347,24348 need to be open to the PBUL
infrastructure
Policy Server
The Policy server is the host where command requests are received and compared with policy
to determine whether to accept or reject a privileged command request. Policy servers take
these requests on firewall port 24345 by default. Policy complexity, and the number of
concurrent requests have a bearing on the sizing of these servers. Servers are typically
deployed in pairs to provide High Availability where both Policy servers host identical policies
for processing.
UNIX/Linux Policy Server host in the customer environment – Minimum Requirements

Processor 2 Core
Memory 4gb RAM
Form Factor Varied in Customer Environment – Host can be physical or virtual
infrastructure
IO Log Server
The Log server is responsible for recording session logs, forwarding events to the Solr server for
indexing, and processes session replay requests when contacted by BeyondInsight. When the
Policy server authorizes a command, a separate process is started between the log server, and
the Run Host to capture and record all session activity.
UNIX/Linux Log host in the customer environment – Minimum Requirements

Processor 2 Core
Memory Minimum 500gb disk space. Varies significantly depending on the
number of session log files recorded, and the retention plan for those
session logs.
4gb RAM
infrastructure

8
8443 needs to be open to the Solr server for event and log indexing
443 needs to be open to BeyondInsight for log replay
Solr Server
The Solr server is responsible for indexing session logs, and forwarding events to the
BeyondInsight Console. When a session recording concludes, the Log server contacts the Solr
Server and requests session log indexing. The session log is indexed, and that information is
passed to the BeyondInsight console for search and retrieval.
UNIX/Linux Solr host in the customer environment – Minimum Requirements

Processor Varied in Customer Environment
Memory Varied in Customer Environment
Firewall Ports Required 24345 24346 24347,24348 need to be open to the PBUL infrastructure
8443 needs to be open to the Solr server for event and log indexing
443 needs to be open to BeyondInsight for log replay
Capacity Planning
The efficiency and capacity of PBUL infrastructure varies widely based on a number of factors.
Network capacity, network port usage, number of concurrent sessions, which sessions are
logged, load balancing (whether using built-in randomization, or a load balancer in front of the
infrastructure), and server I/O are factors in capacity and will vary largely by environment.
A default installation of PBUL configures traffic to transit the customer network on TCP/IP ports
24345, 24346, and 24347, and hosts are called serially as they are listed in the settings file on
the client. This implementation satisfies the requirements of installations with less than 10,000
clients, and where concurrent requests number less than 5,000 at peak.
Capacity can be controlled in two parts in PBUL.
1. Server and Network optimization
2. Policy Optimization
Depending on customer requirements, both should be considered when a customer is
optimizing their environment. There is no perfect solution for optimization, as things vary
greatly from customer to customer, however, using some combination of the suggestions
below will permit a customer to adjust their environment and optimize performance
significantly.

9
Capacity Optimization for hardware/server performance
The PBUL infrastructure can be expanded to handle higher volumes of traffic with a
combination of the following configuration changes to adjust the default installation to the
customer environment. These configuration changes are outlined below, and can be combined
with one another to improve performance or capacity.
Customers should monitor their environment closely for performance issues, and adjust
settings to tune their environment if performance degrades. Adding additional servers is often
the simplest solution, but much can be done to make the best use of the available resources.
The steps below will outline some of the tuning parameters that can be adjusted to increase
the performance of a PBUL deployment.
Load Balancing
Balancing network traffic, and requests across the PBUL infrastructure is critical to improving
performance of the PBUL software. Techniques similar to those used when balancing requests
across a busy web complex can be used to optimize requests to the PBUL infrastructure. This
will prevent any single server from becoming overwhelmed by requests. Load balancing can be
achieved in two ways, using the built-in randomization features, or using a customer installed
load balancer that is available within their network.
Built-in randomization
PBUL has keywords in the pb.settings file that provides randomization among the Policy
and Log servers listed.
Setting the randomizesubmitmasters keyword to “Yes” will cause the PBUL client
to randomly select one of the Policy Server servers listed in the submitmasters line
when a request is made.
Setting the randomizelogservers keyword to “Yes” will cause the PBUL client to
randomly select one of the Policy Server servers listed in the logservers line when a
request is made.
It is recommended that these keywords be returned to “No” when using the alternative
load balancing solution outlined below.
Customer installed Load Balancer
The PBUL infrastructure can be placed behind a Virtual IP (VIP) on a load balancing
system in the customer environment, and that system can select hosts methodically.
Most load balancing software can monitor host load, and will balance network traffic,
sending it to the host that has the most available capacity to handle the request
efficiently. Configuration of the customer installed load balancer should ensure that
requests are balanced as evenly as possible across the available PBUL infrastructure. An
10
additional benefit to load balancing in this manner is that severs can be taken out of
rotation for maintenance without undergoing the ‘fail-over’ delay when a request is
received.
Optimizing to reduce Network Latency

PBUL has keywords to optimize the delay between when a request is made, and received by the
designated Policy or Log server. When a request is made, an attempt is made to contact the
Policy Server, or the Log server, and the allowed delay between the request and the response is
fully configurable. Customer network latency, load, and other factors will influence these
settings. The PowerBroker Administration Guide that corresponds to the installed version has
more detail on these settings, but a general description of their functions is here:
Built-in network time-out and delay settings

masterdelay - This keyword designates the length of time to wait when attempting
to contact a PBUL Policy server. Set this to some value, perhaps 1000 to 2000 (adjust to
tune to the customer environment). Should be used if the customer is experiencing
some kind of network latency; the default value is 500 and the unit is in milliseconds.
masterprotocoltimeout - This keyword sets the length of time to wait for
establishment of a connection once the policy server has been reached. Set this to
some value like 500 or 1000 (tune to the customer environment) and this can help in a
failover situation if the Policy Server/Log server gets busy. The default value is 0 and
this results in making the client “wait” until the PBUL protocol is completely negotiated
by the client. This will be manifest as queuing on a busy server.
logserverdelay - This is similar to masterdelay but applies to a client that
connects to a Log server.
logserverprotocoltimeout - This is similar to masterprotocoltimeout
but applies to a client that connects to a Log server.
Built-in alternative network port settings

By default, all traffic from clients to Policy Server and Log servers transits through the network
on TCP/IP ports 24345, 24346, and 24347. PBUL has keywords to permit the use of non-
standard ports which will distribute the load across multiple TCP/IP ports on clients, and
infrastructure hosts. Using these settings depends on the customer opening corresponding
ports in their firewalls to permit this traffic to pass from client to host. Customers can define
additional port ranges, and authorize the use of the non-standard ports using keywords in the
pb.settings file.

11
The relevant keywords are:
Allownonreservedconnections - This keyword permits PBUL to use ports
outside of the default 24345-24347 range. Changing this keyword to “Yes” will cause
the PBUL infrastructure to negotiate connections on alternate ports between the client,
the Policy Server, and the log server. This helps to distribute TCP/IP traffic and makes
use of unused network ports for connections.
When permitted by Allownonreservedconnections keyword, customers can
define the port range that will be permitted within their network ranging from 1025 to
65535. Customers have varied security requirements that may restrict usage of the
complete port range, and those requirements will govern what range can be made
available. Keywords associated with this configuration are:
minlisteningport 1025
maxlisteningport 65535
minoutgoingport 1025
maxoutgoingport 65535
It is important to note that corresponding firewall rules must be updated to permit traffic on
these ports if they are enabled.
Optimizing Name Resolution

In order to prevent the possibility of a host masquerading within an environment, PBUL
validates that the host name in DNS matches the host name it received with a request. The
client, the Policy Server, and the Log server must be able to resolve fluidly within the customer
network. A keyword within the pb.settings file will allow customers to configure the delay time
that it will wait for host resolution, very similar to the masterdelay keyword above.
Nameresolutiontimeout - This keyword designates the length of time to wait

when attempting to contact a DNS server. Set this to some value, perhaps 1000 to 2000
(adjust to tune to the customer environment). This should be used if the customer is
experiencing some kind of network latency; the default value is 0 and this results in
making the client “wait” until DNS information is returned.
Optimizing Infrastructure Input/Output and resource limits

All PBUL infrastructure servers can be tuned to accommodate the volume of requests that each
server can handle. Customers will have to balance their tolerance for processing delays against
the footprint of the infrastructure they want to support in their environment. Using standard
UNIX tuning tools, it is possible to support large numbers of requests on servers, and this will

12
vary depending on the number of CPUs, the amount of RAM, process limits, and access to swap
space on the servers.
CPU sizing – Customers should monitor server load to operate at ~80% under normal
load, and to allow for spikes in server demand. Servers must be able to efficiently
handle the incoming requests, and process them with adequate resources.
RAM Available – Each request received by a server requires a certain amount of memory
to process. Some connections, such as session log recording use a persistent connection
to record the sessions, writing to disk periodically, or at the end of a session. Customers
must ensure that enough random access memory is available to handle peaks and under
normal use.
Process Limits – UNIX servers can be tuned to allow a certain number of concurrent
processes. This is configurable by user, or process type. The ‘ulimit’ command
controls the amount of resources that can be consumed by any given user or process,
including file size, memory consumption, and the number of concurrent processes. On
PBUL infrastructure servers, adjustments can be made to permit ‘pbmasterd’,
‘pblogd’, and ‘pblocald’ to use an extraordinary amount of resources since the
server should have no other resource demands. Customers should monitor and adjust
these limits based on resource consumption on their servers.
Swap Area – Typical UNIX system behavior can be expected related to the use of swap
space on PBUL infrastructure servers. Processes that are dormant, or have a lower
priority than other requests may be cached to a swap partition for rapid recovery on
busy systems. A swap area sufficient to handle this caching should be provisioned, and
customers should monitor the use of this space adjusting it accordingly to tune servers.
Release of Network Ports – On UNIX servers, TCP/IP will hold ports open for a
configurable length of time to permit residual network traffic to arrive before closing
out a process. The length of time a port will remain open before being released back
into the available pool of resources can be configured using standard UNIX network
configuration procedures. When tuning these settings, it is important to take care that
data is not being lost by closing these ports too early. With modern network
equipment, latency is very low, so adjustments can be made by the customer to suitable
numbers. This procedure should be done when customers see a large number of
‘pbmasterd’, ‘pblogd’, and ‘pblocald’ processes idle on their servers.

13
Capacity Optimization for policy handling and performance
Policy Optimization
PowerBroker policy language is an extremely powerful tool that processes policy to determine
whether to accept, or reject for privileged command requests. PBUL policy consists of
configuration files with functions, and procedures designed to make decisions based on
environmental data (user, group membership, host, command, etc.). Policy files reside on the
Policy Server server, and when requests are received, policy is read and assessed to end with an
accept, or reject. As with all code, policies can be optimized to make the decision process more
efficient.
All policy decisions boil down to “Who”, “Where”, and “What” in most environments, and
writing policy with that in mind will help build policy structure that is efficient. There are some
best practice considerations that can be made to optimize policies for the most efficient
processing possible.
Policy is read from top to bottom – Placing the most important policies at the top of the
policy will ensure that these requests are processed first. For instance, system
administrators often require immediate access to privileged commands to resolve
system issues. Placing the policy that governs their activities uppermost in the policy
will ensure that SA requests for privileged access will be processed first.
Make decisions efficiently – Placing an ‘If’ statement at the beginning of a configuration
file that defines the conditions under which that policy segment will be processed will
allow the policy determination to be made quickly. If a condition is placed at the top of
the policy file that defines a specific condition, and that condition is not met, policy will
continue on to the next configuration file rapidly. Winding down through policy with
broad, or poorly defined conditions will consume processing power and cycles,
degrading the efficiency of policy processing.
Smaller is better – Large files that are processed by policy will slow policy processing
significantly. A rule of thumb is that reading a file larger than ~3,000 lines will slow
processing. This has to do with the way that Unix processes information, and has little
to do with PBUL itself. Recognizing this, and writing code in such a way that you avoid
that condition will help speed processing significantly. Wherever possible, use group
membership, rather than individual users, or regular expressions to define host groups if
possible.
Avoid Hard-Coding variable information - If possible, branch out of policy to read a list in
a small file after a condition has been met, rather than hard-coding variable information
in policy. Information such as users who may come or go from an environment should
never be coded into policy. Rather, it is preferable to assess authorization based on
14
membership in groups, or lists of hosts defined in small files. Group provisioning is
usually handled by a centralized provisioning system, and this will eliminate the
possibility of artifact memberships or legacy policy authorization.
Leverage other Identity and Access Management systems – Most enterprises use many
tools to provision or control the identities within their environment. Most modern
provisioning tools have some type of API that can be queried, or place data into a
database that can be queried easily. When building policy, consider how volatile
information is within an environment. Typically, group memberships do not change
frequently once they are established, so rather than make an LDAP or AD call with every
policy request, give some thought to collecting the data periodically, caching, and
reading it locally. For example, making one LDAP or AD call every 30 minutes, and
storing group membership information locally will spare the LDAP/AD server from
potentially thousands of requests. Retrieve and store the information once, use it
multiple times, and refresh it periodically to reduce the burden on the PBUL
infrastructure, and other systems in the customer environment. Informing users that
following group membership provisioning it will take as much as 30 minutes for
privileges to be available is often acceptable in larger environments.
Use the Operating System – PowerBroker policy language provides unrestricted access
to the Policy Server host operating system. Branching out of policy to execute a small
shell script to create smaller files for processing can optimize policy significantly. For
instance, using a shell script to select a small group of servers from a large list, and
placing it in a specific location for reading, and processing will reduce the number of
extraneous items that have to be reviewed, thus speeding policy processing. The
temporary file can be deleted using policy language immediately following processing to
keep systems clean.
Session logging consumes processes – PBUL policy will always record metadata for
events such as commands that were requested, when, who, etc. whether they were
accepted, or rejected, and these are stored in the PBUL events file. Some events, such
as defined processes that are executed by service or application ids that require
privilege are documented and defined for audit purposes. Recording those sessions
may not be worthwhile, particularly if those processes occur multiple times per day.
Auditors may be satisfied with the process definition document, and assurance that the
process operates unchanged as defined within that document. Reducing the number of
sessions that are logged will reduce the burden on log servers, and will reduce the
amount of space required to store logs. Customers should explore their logging
requirements with their audit team to see where they can save cycles by not logging
sessions.

15
Only log privileged activities – Some commands, such as ‘ls’ require privilege to execute
in certain directories. The ‘ls’ command is entirely passive in nature, and does not
represent a risk of modification to the filesystem. This is true on many systems,
however there may be cases where directory contents may be privileged. The decision
to log these sessions will depend on the security requirements within the customer
environment, but auditors often recognize that passive commands need not be
recorded. Events will still be recorded, and there will be an audit record of the
command being executed, but recording that session may not be necessary. Consult
with your audit team to determine a list of commands that do not have to be recorded,
and build policies accordingly.
Define a log retention strategy – Log rotation, and archival will reduce the size of the
filesystem on the log servers. On large disks, and at load, disk I/O can become a factor
in performance. It is up to the customer to determine the length of time that logs
should be available for replay, and logs beyond that time should be rotated away from
the log server to reduce disk space requirements. Log retention should fall within the
definition of the customer, based on legal, regulatory, or audit requirements for their
business or industry.
Take a step back, and review – PBUL policy evolves over time, and regular reviews of
policy should be undertaken. A master policy definition document that is regularly
updated will assist auditors, as well as give the team that supports PAM the opportunity
to review policy for gaps, or to remove deprecated policies. It is not uncommon for a
host or application to be decommissioned, and policy remains that defines activity on
that host. If possible, customers should integrate PAM with other systems in their
environment to dynamically update host lists, or user lists. Housekeeping in this way
will prevent artifacts from building up.
Capacity Optimization summary

The above should be treated as levers when tuning a PBUL environment. Customer network
security requirements may dictate whether additional ports can be used, and servers must be
tuned to maximize the resources available. Policy handling and efficiency can be used to tune
processing time as well. This tuning is an art, not a science, and each customer network will be
unique in which of the tuning methods works best for them. Adding servers to the
infrastructure can be done at any time, and when this is done, they should be tuned properly to
match the other servers in the infrastructure.
Capacity Planning Calculator (Generic)

For a generic sizing guide, based on a typical data center style server, BeyondTrust recommends
customers running 9.4.1 or higher to scale the number of servers so that no more than a
maximum of 10,000 clients per PowerBroker for Unix & Linux Policy Server or 5,000
16
simultaneous connections per PowerBroker for Unix & Linux Policy Server should be used when
deploying PowerBroker for Unix & Linux.
There are many variables that can and will affect the performance and capacity of a
PowerBroker for Unix & Linux server, but off-loading the logging services, especially when
performing a high amount of Session Recording (IOLogging) is always recommended. Each
Policy Server should be support by 2 separate Log Servers.
When building a PowerBroker for Unix & Linux environment that must handle large volumes of
requests, it is important to understand that requests will get queued up and processed by the
system as resources become available. Please remember submitting large numbers of requests
in a short period of time will like result in an amount of latency before all the requests have
been processed and should be factored in when planning for the required resources.
The example capacity calculator shown below is included in the ‘PBUL Sizing & Stress Test
Results.xlsx’ spreadsheet file that is available from BeyondTrust Professional Services and
illustrates the appropriate requirements for a sustainable architecture:
NOTE: This sizing assumes that the customer environment is stable enough to handle network traffic to and
from the PBUL infrastructure, DNS queries, and LDAP/directory queries. This sizing is based on the CPUs
available to the PBUL software for processing requests.
Performance Testing
CORES RAM Concurrent RequestsDaemon Server Type Comment
20 140 5000 pbmasterdPolicy Master Session logs are more
20 140 5000 pblogd Session Logs intensive than event logs, so
20 140 5000 pblogd Event Logs event number can be
Total Environment Size N/A adjusted if necessary.
Policy Servers (Masters) 1
Log Servers 1
RAM is disregarded for server capacity

Customer Environment
20 128 5000 pbmasterdPolicy Master One Master, spawning two log
20 128 5000 pblogd Session Logs requests for each pbmasterd
20 128 5000 pblogd Event Logs
Total Environment Size 25000

Log Servers 10

Log Servers 60

Log Servers 120

17
BeyondTrust Stress Testing Results
The Lab machines used for the stress testing of high volume concurrent requests were as
follows:
Policy Server(s) Log Server(s) Clients(s)
Again, it is important to remember that there are many factors that can positively or negatively
affect performance and results, such as network, hardware, encryption, policy and logging.
During BeyondTrust’s stress testing, a simplified/basic policy was used. In addition, using
automated tool to simulate load typically results in minimal session log data being generated
and the generation of large session log files (iolog files) in a short period of time should also be
considered when planning log servers, disk size, disk speed and network throughput.

18
Additional System Optimizations
Before performing stress testing against PowerBroker for Unix & Linux 9.4.1, the follow
optimizations were made to the lab machines in addition to the normal configuration
optimizations outlined throughout this document.
/etc/sysctl.conf
# System default settings live in /usr/lib/sysctl.d/00-system.conf.
# To override those settings, enter new settings here, or in an
/etc/sysctl.d/<name>.conf file
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
############################ custom additions ########################

# ref: www.cyberciti.biz/faq/linux-tcp-tuning/
######################################################################
net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 18240 87380 12582912

net.ipv4.tcp_wmem = 18240 87380 12582912
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.somaxconn = 1024
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_retrans_collapse = 1

19
Load Testing Results
The attached results are included in the ‘PBUL Sizing & Stress Test Results.xlsx’ spreadsheet
available from BeyondTrust Professional Services.

20
PowerBroker Password Safe (PBPS)
PowerBroker Password Safe delivers password management across all aspects of an
organizations infrastructure. The technology provides automated management of highly
privileged accounts, such as shared administrative accounts, application accounts, and local
administrative accounts, across operating systems, applications, and infrastructure devices. For
a typical installation the following capacity planning metrics should be used per manager:
Maximum Managed Accounts 30,000 30,000 250,000 N/A

Maximum Sessions – RDP 300 300 600 N/A
Maximum Sessions – SSH 600 600 900 N/A
Maximum Assets 20,000 20,000 50,000 65,000
Maximum Smart Rules 150 150 500 N/A
Database growth
Growth is determined by the number of password changes, the number of session requests,
and keystrokes logged. Keystroke figures are approximate, and representative of average
RDP/SSH sessions; In use, there is a vast difference between simple SSH commands such as
nslookup, and SFTP sessions that will generate vast quantities of screen output.
Password Change
 Each change: 8KB
 Example: 100K password changes per year = 800MB
Requests
 Per request: 0.25KB
 Per approval: 0.13KB
 Per session recording: 0.35KB
 Example: (assume session length of 2 hours in 18hr working day = 9 sessions per
concurrent user per day x 100 concurrent users = 900 sessions per day).
o 900 x 0.73KB = 0.67MB per day for requests with approvals.
o 900 x 0.6KB = 0.54MB per day for auto-approved requests.
Session Recording Files
 RDP session file (on disk): ~350KB per minute of recording
 SSH session file (on disk): ~25KB per minute of recording
 Example: (assume 900 sessions per day x 120 mins = 108,000 minutes of
recording).
o SSH: 108,000 x 25KB = 2.7 GB per day
o RDP: 108,000 x 350KB = 37.8 GB per day

21
Keystrokes (in database)
 This metric directly reflects the number of keystrokes performed via SSH or
RDP and database indexes required to search the information. It can vary
greatly per deployment and is dependent on the average number of
keystrokes each environment processes per protocol.
PowerBroker Identity Services (PBIS)

PowerBroker Identity Services centralizes authentication for Unix, Linux and Mac environments
by extending Active Directory’s Kerberos authentication and single sign-on capabilities to these
platforms. By extending Group Policy to non-Windows platforms, PowerBroker provides
centralized configuration management, reducing the risk and complexity of managing a
heterogeneous environment. For capacity planning purposes, the following metrics should be
applied when deploying the solution:
Active Directory (AD) Bridge Functions

There are several reasons that customers choose to use the AD bridging provided by PBIS in
their environment. These include:
Centralized Identity Management – PBIS bridging relieves the customer of the
requirement to maintain separate directories for authentication in their UNIX
environment. This has traditionally been a function handled by native LDAP in most
customer environments, and users typically were faced with remembering several
different ids and passwords within a customer environment.
Faster user id provisioning and removal – Leveraging the power of Active Directory,
customers can provision an id in one place, and it will cascade to all authenticated
systems. User id removal will similarly cascade throughout the environment.
Centralized Identity Mapping – User ids can be mapped to specific roles or functions
using native Active Directory User Controls (ADUC).
Centralized control of User Accounts – Users can be placed within Organizational

Units (OU) structures that permit or deny access using native AD tools.
Kerberos SSO features – Active Directory identity management offers customers the
ability to incorporate Kerberos (strong authentication) into their UNIX environment.
The health of Active Directory is critical for the successful deployment of PBIS. PBIS is, an AD
client and relies on the same infrastructure being in place for native Microsoft Windows assets
22
and their Active Directory domain. In a pure Windows environment, many problems can be
masked by the myriad technologies that Windows has incorporated over the years. For
example, WINS and NTLM authentication often cover up problems with DNS and Kerberos.
Because of the possibility that underlying AD problems may not be causing day-to-day issues
with a customer’s environment, it is necessary to take a step back and ensure that AD is
functioning optimally before proceeding with the installation of a product that extents its native
functionality. Problems with AD, or poorly implemented architectures, must be resolved before
the installation of PBIS or could become pronounced if not resolved.
Account Collection
When consolidating to a central directory source, such as Active Directory, it is necessary to
consider all existing account databases in a customer environment. There are often multiple
account databases in a UNIX environment that contain different, and often conflicting, sets of
account data. Examples of such databases include: NIS, LDAP, winbind (samba), and local
group/passwd files pairs. It is important to collect and review all data sources to consider them
for reconciliation. Users and groups could exist with different names (or more commonly
UID/GIDs) on multiple servers, NIS Domains, or LDAP directories.
Since the goal of PBIS is to leverage the power of AD to centralize these accounts, it is
important to collect and reconcile all user and group information for administration and
reporting. To this end, it is also necessary to collect account information from AD to be used for
mapping the account sources. Additionally, in some cases, you may have will already
performed a previous AD migration with PBIS and will have to utilize Active Directory as
another source for UNIX account information.
The account collection stage is performed by the end user. As a user, it is required to gather
account and group data from their local server databases, NIS domains, LDAP, and AD
databases. BeyondTrust has several tools and methods that will assist the customer in
gathering this information. At this point in time, account data should be considered in a
“frozen” state with respect that any accounts created after Account Collection may not be
considered in the following Account Reconciliation stages. Although it will be possible for the
manual addition of data before the Account Provisioning stage, you will need to keep careful
track of changes to account sources, and ensure that no further conflicts are created.
The table below summarizes the various database types as well as the mechanisms which can
be used to retrieve information from them:

23
Account Database Types and Retrieval Mechanisms
Retrieval Mechanisms
Account Database passwd/group getent LDIF get-nis- ypcat CSVDE Retina Discovery PowerBroker
Sources files maps.sh DART
Local System files
   
LDAP
 
NIS Domain (single)
      
NIS Domain (multiple)
  
NIS with netgroups
     
Winbind
 
Active Directory (UNIX
Info)
   
Active Directory (AD
Info)
      
The following sections detail the tools involved to collect the user and group accounts spread
throughout the other account databases with an environment.
Account Retrieval Mechanisms
passwd/group
The output for the user and group accounts will already exist under the /output/reports
directory in the form of passwdlines.txt and grouplines.txt respectively. These
were generated by the viewhealthstatus.py during the Initial Audit stage.
getent
The Linux getent command (or PS tool getent.pl) can be run with the group or passwd
parameters. This command pulls information from the local system passwd/group files as
well as any NIS domains and/or LDAP databases configured via the system’s nsswitch
configuration. This is often the quickest way to get the entire cross-section of all account
domains on a single box. However, as this output does not delineate which accounts are from
which sources, it is not the best method when looking to assign priority to account source.
LDIF
LDIF can be used to pull information from an LDAP database. The LDIF file format must be
converted to standard passwd/group format after it is collected. The can be done with the
ldif2passwd.pl tool, detailed below:
Location:
/deployments/account-mapping/
HELP:

24
usage: ldif2passwd.pl [options]
get-nis-maps.sh
The get-nis-maps.sh script is used to extract information from a NIS domain. Both the get-
nis-maps.sh and the get-nis-maps-2.sh described below must be edited to suit a
customer’s environment prior to running. These tools must be run if the
viewhealthstatus.py tool outputs a /customer/output/reports/nisdomains.tab file. The
nisdomains.tab file will list all NIS domains, and a list of suitable NIS servers for each domain.
The script should be run by the customer on a linux-based machine in the environment where
the NIS servers exist. Their purpose is to pull the various NIS maps and compress them into a
tarball for delivery to Professional Services.
Finally, package the edited get-nis-maps.sh script, and the ypmaplist-<OS> binary
into a zip file and send this to the customer to run from a Linux computer with “nis-tools”
installed. The script will output a domains folder. Have the customer zip this file and send it
back for analysis.
ypcat
Yellow Pages Cat or ypcat can also be used from a PBIS joined UNIX machine for pulling the
information on the currently provisioned Cell.
Example:
/opt/pbis/bin/ypcat passwd;
/opt/pbis/bin/ypcat group;
CSVDE
The purpose of CSVDE in the Account Collection process differs slightly than the previous
mechanism to collect account information detailed above. All of the previous methods are
used to collect UNIX account information from various sources (local,NIS,LDAP, etc). CSVDE on
the other hand is used to collect Windows account information from Active Directory. The
extracted information is used during the Account Mapping stage of Account Reconciliation
discussed later in this document.
CSVDE is a native windows command, and should be run from one Domain Controller in each
AD domain hosting user accounts. The following command can be used exactly to extract the
relevant information:
Retina Discovery
BeyondTrust’s Retina Vulnerability Management Solution is available to all PowerBroker users
for asset intelligence and discovery scanning. The solution will discover all user accounts on
Windows, most Unix and Linux platforms, infrastructure like Cisco, and display the results in
BeyondInsight. Once PBIS is implemented, BeyondInsight and Retina can report on PBIS

25
account activity when used with other modules. While Retina discovery is typically not used for
onboarding PBIS accounts, it is key component of the workflow for maintaining and monitoring
Active Directory bridged accounts.
PowerBroker DART
PowerBroker DART scans the IT infrastructure to find, profile and report on user credentials and
SSH keys to help security teams quickly identify and take control of privileged account risks.
 Finds and counts user accounts, local accounts, SSH keys, Windows and Linux groups,
default and hard-coded passwords, and more, reducing risk and ensuring that no
accounts, users, or assets are left unsecured.
 Displays high-level metrics on password strength, age and other key indicators of risk in
a dashboard format for fast review and analysis by stakeholders.
 Generates an easy-to-read, customized HTML or Excel-based report, helping security
leaders make informed decisions on how to immediately reduce the risks to privileged
access.
 Provides the ability to export data via XML into PowerBroker Password Safe and
PowerBroker Identity Services for complete privileged account management.
Account Reconciliation
Once all the data from the Account Collection process has been gathered and placed into the
appropriate staging folders, the process to reconcile the data can begin. The following sections
detail the steps involved to reconcile the groups and users found in the customer’s UNIX
environment.
1. Initial Merge - his phase, consolidates all the collected account information into a single,
merged database of user accounts for importation into Active Directory. There will likely
be changes to make to the merge based on the toolset and desired results.
2. Account Mapping - Maps serve to correlate the gathered UNIX account information to
Active Directory accounts. The toolsets can aid in the map creation process, but a
manual review is strongly recommended to ensure that all accounts are matched
properly.
3. Merging Account Data -During this phase the data is reviewed and processed to ensure
it is consistent with migration goals. The data may be reprocessed iteratively multiple
times, each time fine-tuning individual accounts and data source priority.
4. Final Merge - The final merge can be viewed as the last iterative cycle in the data
massage process. Its resultant output is a definitive set of files which will be used in the
Account Provisioning process.
Account Provisioning
Once the Account Reconciliation stage has completed, it is time to pull all the reconciled data
into Active Directory. This process may involve the creation of new AD users and/or group to
correspond to their UNIX counterparts. Additionally, the key task of Provisioning each AD user
and Group with their UNIX account information will be performed.
26
The Account Provisioning stage can be broken down into several key phases:
 Active Directory Preparation

 Cell Creation
 AD object creation
 AD Provisioning
The preceding stages are discussed in more detail below:
Active Directory Preparation
Prior to Provisioning any account information, the AD environment must be prepped for PBIS.
This includes:
 Installing the PBIS windows components on one or more administrative workstations or

servers.
 Modifying the AD schema using the Schema Wizard when appropriate.
These tasks are beyond the scope of this document. Please see the PBIS Installation and
Administration Guide available on the BeyondTrust website for more information.
Cell Creation
Cell creation is a negligible process, but the information of what kind of Cell to create, and in
which domains are critical questions that must be resolved before continuing. After the
Account Reconciliation phases and the collect of all information, a decision as to the proper Cell
design mode can be made.
AD Object Creation
The AD Object Creation phase is the first step in actually bringing over the UNIX accounts into
Active Directory. In most cases, user account creation will be limited, as most UNIX accounts
will already exist in AD. Creating groups, and populating those groups with the appropriate
users are usually the key steps within this phase. Although this can be a manual process, PBIS
provides scripting tools to assist in this endeavor.
AD Provisioning
Provisioning is the process of assigning the UNIX account information to the AD objects. The
data sets created in the Account Reconciliation stage are used as the basis for this.
Active Directory Sizing and impact
Modifying Active Directory to support DI mode and the creation of Cell objects have, by
themselves, a negligible effect on the size of the Active Directory database (NTDS.DIT) and
associated replication. The instantiation of a Cell object is only a few KB in size and the
replication and indexing of the required values will not impact growth until those attributes are
populated. Therefore, it is not until users and groups are provisioned within the Cell, and their
associated data added to directory, that any discernible growth will occur.

27
Once account objects are provisioned, the AD database will increase in size – both from the
population of the required attributes and from their associated indexes. Use the following
guidelines to understand the type of data stored and/or replicated to each DC in an enterprise
environment:
Each Domain Controller in a Domain with provisioned users will receive a full copy of the
AD database for its Domain. This means that every attribute added for a provisioned
user will be replicated to each DC in the Domain.
 The uid, uidNumber, gidNumber, and displayName attributes are replicated to the
Global Catalog (GC). This means that these 4 values, once populated, will be replicated
and stored to every GC in the Forest.
 Starting with PBISE 8.0, the loginShell, unixHomeDirectory, and gecos attributes are
also replicated to the GC as those above.
 AD does not replicate indexes between Domain Controllers, even those from the same
Domain. Indexes are rebuilt with the appropriate data on each Domain Controller.
While it is not possible to provide estimates on replication traffic due to the specific
configuration settings and bandwidth consideration of each AD environment, it is possible to
provide estimates of AD database growth.
Per Microsoft (http://technet.microsoft.com/en-us/library/cc961779.aspx), individual
attributes require approximately 100 bytes in the AD database. Based on internal testing,
BeyondTrust has qualified this as a relative approximation of the actual size used by each
object. Additional space however will also be used for the indexing of the appropriate
attributes.
On average, each provisioned user object will require approximately .8 KB additional space
within the AD database. Of this .8 KB, approximately .7 KB is utilized for attribute storage with
the remaining .1 KB used for indexing.
Since group objects utilize only 1 of the RFC2307 attributes (gid) and the optional Alias setting
(displayName), the space required per provisioned group should be approximately .27 KB, of
which approximately .015 is used for indexing.
Therefore, to estimate growth of the AD database for PBIS provisioning, use the following
formulas:
((# of Users * 0.8KB) + (# of Groups * .27KB)) = Total # of KB of growth
e.g.
((100,000 * 0.8KB) + (50,000 * .27KB)) = 93,500 KB = 93 MB of growth
The resulting output should provide a good estimate of the database growth required. The
actual value may vary by 10-20% in either direction depending on the specific attributes
provisioned (see Testing Methodology below).

28
This formula determines the growth from the provisioning of user and group object only. It
does not account for growth due to the creation of user and group objects. Please follow
standard Microsoft sizing guidelines for the creation of additional user and group objects.
The above calculations were performed against a Default Cell in Directory Integrated mode. In
Schemaless mode approximately the same amount of data is required on each AD object
however this data will be stored in the single keywords value instead of on individual RFC2307
values. The keywords value is replicated and indexed in the Global Catalog by default and
therefore similar growth sizes can be estimated in either mode. For Named Cells, a conservative
estimate would be that Named Cells impact DIT growth approximately 2-2.5x greater than a
Default Cell. This is due to Named Cells utilizing a serviceConnectionPoint (SCP) object for each
provisioned account.
Unix and Linux Agents
For PowerBroker Identity Services to bridge a non-windows system (Unix, Linux and Mac) to
Active Directory an agent needs to be installed. For capacity planning, the only real
requirement is that the target host is a supported platform and meets the minimum
requirements outlined in the documentation, as the agent itself has a very small foot print and
uses very little system resources, the stability or performance planning should really focus on
Active Directory which typically will already be spec’d to handle enough users and machines
even when rolling the non-windows platforms into the directory.
Agents store PBIS reporting events within their local PBIS eventlog. Standard agent event
configuration captures all PBIS specific events (authentication, agent state, GPO, etc) as well as
external authentication against the system (sudo, ssh, etc.). Group Policy provides the flexibility
to match additional events from the syslog files for inclusion into the PBIS event log.
On Individual agent systems how much and how long data is retained on the individual boxes is
determined by a variety of configuration settings. On average an agent will generate ~.5 MB of
eventlog data / day.
Agent best practices are as follows:
 Keep a 90-plus day history in the Event Log

 Set a maximum disk size at least 75MB
 Remove events as needed
NOTE: Capturing *all* syslog events at error level and above, requires ~2-3MB / day / agent
Agents can be queried directly for their events, or configured to forward them onto the
Reporting Database (SQL backend) via a Collector Server

29
PowerBroker Identity Services Reporting Sevices
The one area of a PowerBroker Identity Services deployment that may require correct sizing
would be the database and collector services for the optional reporting component. At a high
level, the two main things to consider for a PowerBroker Identity Services deployment are
Collectors and a SQL Database to store collected events:
Collectors
Collector Servers (PBIS software installed on Windows Server) aggregate received events from
agents and forward them to the SQL and BeyondInsight backend. Using collectors both reduces
the connection load on the audit database, as well as potentially limits network traffic (in
distributed scenarios).
Collector best practices are as follows:
 Maximum 400 agents per collector

 Virtual machines are supported
 Can support agents from multiple domains
Events are held for 24 hours on each Collector after sending to the SQL server. The SQL Lite
database on the Collector utilizes ~10 MB / agent under normal operating environments.
Providing 2-3x this amount as a cushion of space may be preferred for when the Collector
server is unable to communicate with the SQL database for a period of time (network outage,
server downtime, etc).
For example, a Collector server which services 400 agents will require a minimum of 4 GB of
space (400 * 10 MB) under normal operations. Increasing this to 12 GB (4 GB * 3) allows for ~3
days of logging to be stored on the Collector.
Events can be recovered up to their maximum retention period on either the individual agents
or the Collectors. In the event of extended downtimes or total system failures, the events can
be resent from the agents to the Collectors and then forwarded back to the SQL backend.
Agent settings can be adjusted to throttle how frequently connections are made to Collectors
and how many events (data) are transferred per connection period.
NOTE: The default location of the collector database is
c:\Program Files (x86)\BeyondTrust\PBIS\Enterprise
Audit Data
The auditing system utilizes 1MB / 1000 events in the audit database. Each agent reporting
through the collector servers will generate an average of 400-500 PBIS and authentication
events / day. Systems with high utilization (logins. regular cron jobs, non-standard logging
options) may generate substantially higher logs.

30
For example, an environment with 500 agents will generate an average of 250 MB of event data
per day (500 * .5 MB). This equates to ~7.5 GB per month of auditing data. If your organization
needs to keep 6 months of data, the audit database should be sized to be at least 45 GB to
accommodate.
SQL Database
Each SQL server will service connections from each Collector server as well as any system
performing Audit Reports. The Collector’s connection intervals and events / connection can be
adjusted from within the reporting configuration.
SQL best practices are as follows:
 Microsoft SQL 2008 R2 or above.

 Virtual machines are not recommended
 Clustering is supported
 Non-default instances are supported (Use “LIKEWISE” as instance name)
 Data should be archived per Microsoft’s standard best practices and an organization’s
requirements
NOTE: Using MSDE or SQL Express versions (including the version provided on the installation
CD) are not supported in production environments due the file size limits on databases.
Audit Reports are run directly against the database from the BeyondTrust Management
Console (BMC). If required, ensure hardware requirements are sufficient to produce adequate
performance when running reports during production hours.
SQL Database Security
To strengthen the security of the PBISE reporting environment, it is recommended that only the
required rights necessary to perform specific actions are granted to the appropriate users and
service accounts. Below is a general guideline for securing the Reporting components.
Create the following Active Directory Groups:
 PBISE_DB_Administrators – Contains accounts that are required to configure and

maintain the PBISE reporting database. It is recommended that a minimum number of
PBISE administrators tasked with maintaining the reporting infrastructure are included
here.
 PBISE_Collectors – Contains the service accounts used to run the Collector services.
 PBISE_DB_Archive_Administrators – Contains the (service) account(s) used for
automated archiving.
 PBISE_Report_Viewers – Contains accounts that need to run reports only.
 PBISE_LDBUpdate – Contains the (service) account(s) that need to run the LDBUpdate
utility to import Active Directory information into the database.

31
Create the following roles with these (minimum) permissions on the SQL database and assign
them to the corresponding AD groups:
 PBISE_DB_Administrators
o dbo
 PBISE_Collectors
o collectors : insert, select, update
o CollectorsStat : insert, select, update, delete
o Events : insert
o CollectorsView : select
 PBISE_DB_Archive_Administrators
o Archives – insert, select, update, delete
o Events – select, delete
 PBISE_Report_Viewers
o All Tables - select
 PBISE_LDBUpdate
o dbo
Collector Server Configuration

After the database is created and security configured, you should install the Collector services
on an allocated server using the PowerBrokerDBUtilities package. During the Collector
installation, you will be prompted to enter a connection string to connect the collector to the
Database (SQL) server.
Database provider: System.Data.SqlClient
Connection String: Data Source=InstanceName;Initial Catalog=DatabaseName;Integrated
Security=True; Connection Timeout=30
Example (default instance):
Data Source=SPP-VP-SQL01;Initial Catalog=LikewiseEnterprise;Integrated
Security=True;Connection Timeout=30
Example (named instance):
Data Source=SPP-VP-SQL01\PBISREPORTING;Initial Catalog=LikewiseEnterprise;Integrated
Security=True; Connection Timeout=30

32
NOTE: The connection details can also be manually configured via the bteventdbreaper.exe
command line tool.
Reaper Service Considerations
The BTEventDBReaper Service requires the ability to write events into the SQL database. In
order to provide this functionality, the service must be modified to run using a service account
included in the PBISE_Collectors Group.
1. Create an account to run the BTEventDBReaper service under
2. Place this account in the PBISE_Collectors Group (to grant DB access)
3. Grant the account read/write access to the following registry keys on the local Collector
box:
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BTEventDBReaper
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BTCollector
4. Modify the BTEventDBReaper service to Log On as this account.

33
5. Restart the BTCollector service (which will also restart BTEventDBReaper).
6. Review the Application Log on the local Collector server to ensure the services have
started without error.
Collector Security and Performance Tuning

After the Collector and Reaper services are running, the BeyondTrust Management Console is
utilized to connect to and configure the Collector service.
1. Launch the BeyondTrust Management Console as a member of the
PBISE_DB_Administrators group.
2. Right-click on the Enterprise Database Management node and choose “Connect to
database…”
3. Modify the connection string to match the string used for the Collector configuration
above.
4. Navigate to the "Collectors" tab. If the Collector service and security has been properly
configured, each Collector should be listed. Right-click on the desired Collector and
choose “Set collector parameters”

34
5. Modify the default settings, so the Collector Period is 15 seconds, the Maximum events
per period is 5000 per collector and 1000 per endpoint. These settings are best-practice
in most environments with adequately performing network links. Additional tuning may
be required based on network architecture.
6. Change the Remote ACL via the “Set Permissions…” button to grant the following access
rights:
 PBISE_DB_Administrators: Full Control - Required to modify the Collector
database via the btcollector-cli.exe command.
 Domain Computers: Write Events – Required for agents to write events to the
Collector database.

35
 When utilizing Collector servers cross-domain it is also necessary to add
Write Events access for computer accounts from remote domains.
 Reaper Service Account: Full Control – Required for the Reaper to remove
events from the Collector database after committed to the SQL database.
 Collector Server Computer Account: Full Control – Required for the system itself
to have full access to the Collector database.
7. Restart the BTCollector Service
NOTE: The default permissions on the Collector Remote ACL are defined by the following SDDL syntax:
O:LSG:BAD:PAR(A;;CCDCRP;;;BA)(A;;CCDCRP;;;DA)(A;;CC;;;DC)
O:LS - Owner:Local Service Account
G:BA - Group:Built-in Administrators
D:PAR - Inheritance Flags:SDDL_PROTECTED,SDDL_AUTO_INHERIT_REQ
 SDDL_PROTECTED - Inheritance from containers that are higher in the folder hierarchy are blocked.
 SDDL_AUTO_INHERIT_REQ - Child objects inherit permissions from this object.
(A;;CCDCRP;;;BA) – ACE 1
 Allow:Built-in Administrators
 Create All Child Objects
 Delete All Child Objects
 Read All Properties
(A;;CCDCRP;;;DA) – ACE 2
 Allow:Domain Administrators
 Delete All Child Objects
 Read All Properties
(A;;CC;;;DC) – ACE 3
 Allow:Domain Computers

36
Scheduling LDBUpdate
The LDBUpdate utility performs an import of selected Active Directory database objects in
order to run agent reports that correlate to the Active Directory hierarchy. While this
command can be run on a manual basis by those with the necessary rights, it is recommended
that a scheduled task be configured on the Collector server to import this data on a regular
basis. This ensures that the Reporting Database has up-to-date information when utilized by
those running reports (who may not have access to update the database). It also serves to
schedule the update to take place at repeatable and expected intervals. LDBUpdate can be
called directly from a Scheduled Task or via a batch/cmd file with the following options:
Example:
"C:\Program Files\BeyondTrust\PBIS\enterprise\ldbupdate.exe" --transaction -f
dc=mydomain,dc=com -c "Data Source=SPP-VP-SQL01\PBISREPORTING;Initial
Catalog=LikewiseEnterprise;Integrated Security=true;Connection Timeout=30" –v
Using the syntax above, schedule a recurring task to run as a user in the PBISE_LDBUpdate
group on a server with the BMC Tools installed.
Capacity Testing (Methodology)
Testing was performed utilizing a two Domain Forest with a single Windows 2008 R2 DC in each
domain. Tests were performed prior to PBISE 8.0 which means the observed index growth is
slightly smaller due to not all of the listed attributes being indexed.
User Testing
Users were provisioned with the following attributes set:
 uid - 13-15 characters

 uidNumber -10 digits
 gid - 8-10 digits
 unixHomeDirectory - 16-18 characters
 loginShell - 9 characters
 gecos – empty

37
User provisioning operations were performed in batches of 10,000 users up to 100,000 objects.
After 100,000 objects were provisioned, one additional batch of 100,000 users was provisioned
for a total of 200,000 provisioned users. Calculations from each batch were taken to
extrapolate data out to a known 640,000 user environment. The extrapolated numbers were
within 2% of the observed values in an actual 640,000 user environment.
The growth values observed in the NTDS.DIT database for 200,000 users can be seen as follows:
INDEX_00150001 (uid): 636 pages * 8 KB = 5088 KB = 0.02544 KB /user
INDEX_00250000 (uidNumber): 405 pages * 8 KB = 3240 KB = 0.0162 KB /user
INDEX_00250001 (gidNumber): 360 pages * 8 KB = 2880 KB = 0.0144 KB /user
PBIS can integrate within an existing AD environment in a flexible and unobtrusive way.
Required modifications pose little or no risk to an existing environment and should negligibly
impact existing AD databases and replication cycles while increasing performance for account
queries and authentication.
PowerBroker for Windows (PBW)

PowerBroker for Windows provides fine-grained policy-based privileged delegation for the
Microsoft Windows desktop and server environments. This solution allows organizations to
remove local admin rights from end users to execute applications with elevated privileges
without any changes in the workflow. This solution also performs optional session monitoring,
keystroke logging, event log monitoring, and real time vulnerability assessment during
application elevation. In addition, policies can be hosted in Active Directory, BeyondInsight, or
McAfee ePO. All of these factors contribute to capacity planning based on the number of rules
implemented and typical utilization:
Planning
Early stages of a PowerBroker for Windows or PowerBroker for Mac rollout consist of
organizational planning. This includes:
 Number of departments and potential geolocations within the organization.

 Type and number of unique applications such as commercial, custom, and legacy.
 Version and types of operating systems and hardware to be managed:
o Operating system version
o Desktop or server class
o Platform from servers, desktops, laptops, tablets, virtual, or embedded
o Supported verses end of life
While exact numbers are not required at this stage, the numbers are used to properly balance
policies, administration, and reporting resources.

38
Learning Mode
PowerBroker for Windows and PowerBroker for Mac can be used in Learning, Discovery or
Profiling mode. Using this model, the least privilege client is installed to a subset of machines
and set to listen to process launches and user behavior, but not apply and application rights
policies. Learning mode should only be enabled for 10-25% of the target group and no more
than a few hundred users at a time due to the volume of data generated. For departments with
little change or difference in their application set, profiling should be limited to 10% of the
whole. For departments with a diverse set of applications between them or where users
require unique applications, up to a 25% profiling target can be used but the upper limit should
be monitored closely for event and profiling saturation. This will help ensure the audit data
does not exceed maximum resource thresholds, as well as limit repetitive or redundant data to
be evaluated by your least privilege administrators.
Once a rule set is created and tested for a target group, administrative rights can be removed
from those users and the software taking out of Learning mode by disabling the ‘Application
Requested Elevation’ setting. This will reduce the amount of data collected from the clients by
as much as 70% or more. To accommodate auditing of applications requiring elevation access
not discovered during the Learning process, the Shell Rule, (for Windows the UAC rule can also
be used) and event tracking is used to complete the necessary rule set. This will allow the
environment to build an effective rule based on the commonality of applications used in an
environment.
Rule Types
When getting started with PowerBroker for Windows, the essential concept is straight-forward
to understand; there is some process, script, software installation, application, or task, that
requires elevated rights on the system to function properly. When a user with limited rights
executes these items, it will not function properly, and in some cases, not open at all.
PowerBroker for Windows allows administrators to create a policy or rule using the PBW GPME
snap-in, BeyondInsight, or McAfee ePO to allow the application the rights it needs, while
maintaining the integrity of the user’s domain rights at a lower level. The solution can
accomplish this goal with a wide variety of rule types. The question then becomes, which type
of rule should I use and why? While there are limits to the number of rules an agent should
have for performance, choosing the correct rule for capacity planning is equally important. For
example, if you can create one Publisher Rule for an entire application verses dozens of Hash,
rules, you should choose the Publisher rule to keep the rule base manageable and not increase
the ruleset size unnecessarily. This section covers which rule type to use for solution
effectiveness and capacity planning. The available rule types are:
 Publisher
 Path, Hash
 Folder
 MSI Path
39
 MSI Folder
 ActiveX, Shell
 CD/DVD
 UAC
This section provides guidance on which rules are most applicable for each given situation to
minimize the quantity deployed.
PUBLISHER Rule
Used to target a digitally signed file by any element of that signature. Since its introduction in
PBW v5.0, Publisher Rules are becoming almost as common as Path rules. It provides the
highest value in single rule coverage for elevating applications while minimizing rule count.
 Pros:
 Effectively targets a specific application (with or without version information)
 Is location agnostic, application can be launched from a local path, UNC, DFS or a
Junction Point
 Can target signed .EXE, MSI, or .MSP files
 Cons:
 Application must be signed by a trusted signature
 Best Use Case:
 Whenever you are targeting a digitally signed application
 When choosing to Blacklist or Whitelist an application’s execution
PATH Rule
Used to target an application or process based on its location. Path rules have historically been
the most common rule type in use within a company’s rule set.
 Pros:
 Path location can easily be typed into the rule’s properties
 Can use wildcards and environment variables within the Path and Arguments fields
 Can be used to target any process in a folder or specific extensions within a folder
 Easy to troubleshoot if the intended policy isn’t triggering when the targeted process
is launched
 You do not need access to the process to create a rule for it
 Cons:
 Can be limiting when applying a policy to an application whose location can be
different on different machines
 Does not protect against a user replacing another application and renaming it to
what the rule is targeting
 Best Use Case:
 When you are new to PowerBroker Desktops
40
 When choosing a rule from the Built-In template library
 When applying a rule to an MS Internet Explorer URL, Scripts or Registry Merges
HASH Rule
Used to target a specific version of an application regardless of its location. This the highest cost
rule type since it is one rule per one application.
 Pros:
 Targets based on an exact match of a file including its version
 Does not require the application to be digitally signed
 Is location agnostic, application can be launched from a local path, UNC, DFS or a
Junction Point
 Is not reliant on the name of the application
 Cons:
 Any update to the binary application will affect a Hash rule from applying (e.g. v1 to
v1.1)
 Hash rules may require more maintenance and additional rules needed for the same
application than other rule types
 There can be a noticeable impact to the end user for poorly written hash rules since
the solution needs to calculate the hash for each application launch that could
potentially be a match.
 Best Use Case:
 When targeting an application not digitally signed in a location the logged on user
has write/modify access to
 When targeting a batch (.bat) file a user could edit. This requires a manual entry of
the .bat file name since the UI defaults to .exe files.
FOLDER Rule
Used to target all applications in a specific folder. The folder rule type is considered nearly
obsolete with the introduction of wildcards in PBW v5.0. To use a path rule to target a folder it
is recommended you create the rule like this, Path: ‘C:\DirectoryOne\DirectoryTwo\*’
MSI PATH Rule
Used to target MSIEXEC.EXE (32 or 64 bit) while still targeting individual Windows Installer
Packages (MSI Files).
 Pros:
 Consistent rule properties regardless of the bit of the MSI file
 Only the Windows Installer Package location/name needs to be specified in the rule
properties, the rule assumes MSIEXEC.EXE
 Can use wildcards and environment variables in the Arguments field
 Can be used to target all Windows Installer Packages in a folder (and/or sub-folders)
41
 Cons:
 May not apply if the .MSI is called with additional arguments, as can be the case
when using Transforms
 Best Use Case:
 When you want to target one or more .MSIs with a PBW elevation or blacklisting
rule
 Any time you want to elevate an approved Windows Installation File
 To target of a shared folder of approved software installs
MSI FOLDER Rule
Used to target MSIEXEC.EXE (32 or 64 bit) while still targeting individual Windows Installer
Packages (MSI Files). The MSI folder rule type is considered nearly obsolete with the
introduction of wildcards in PBW v5.0. To use an MSI path rule to target a folder it is
recommended you create the rule like this, Package: ‘C:\DirectoryOne\DirectoryTwo\*’
ACTIVE X Rule
Used to target installation of ActiveX controls or installations initiated by MS Internet Explorer.
 Pros:
 Allows you to elevate the installation of an ActiveX control without elevating the
web page it was initiated from.
 You can use any combination of a control’s Source, Name, or ID in addition to its
version to target a control.
 Can be used in conjunction with a PBW User Message to better inform the end user
why a given control/page isn’t displaying information properly.
 Cons:
 May conflict with Java applet calls if the rule is not targeted well enough
 May not complete the install of the control if IE is the controlling process. Use a URL
Path rule instead.
 Best Use Case:
 When a user requires the installation of an approved ActiveX control
SHELL Rule
Provides the user with a Right-Click Context Menu option allowing them to elevate an
application not otherwise targeted with a PBW rule. This is the lowest cost rule in the set since
it can be applied to almost any application. This rule should only be given to trusted users and
may represent a security threat if given to inexperienced or untrusted users.
 Pros:
 Allows users who normally would be stuck due to rights to continue their business
tasks without involvement or waiting for help desk staff

42
Assist Help Desk staff to perform administrative and other tasks on an end user’s
machine without the need to log on as an admin user or use a secondary account.
 Allows for a variety of extensions including: EXE, LNK, MSI, MSP, MSC, CPL, CMD,
PS1, VBS, WSF, BAT
 Cons:
 Without additional controls the end user may be able to elevate processes not part
of their normal job functions
 Best Use Case:
 When users are working remotely and may or may not have access to remote PBW
policy updates.
 When users are involved at customer sites or otherwise in a location that doesn’t
allow for calling the help desk to assist
 In the beginning stages of a PBW rollout to help fill in the gaps between auto-
generated rules and new processes
CD/DVD Rule
Used to target all applications from a specified CD or DVD
 Pros:
 Allows you to create rules on a specified CD or DVD without creating a rule for
anything executed from a Drive Letter
 Creating a rule for a specific CD/DVD will also apply to any full copy made from that
CD/DVD
 Cons:
 You must have access to the CD/DVD to create a rule for it
 Best Use Case:
 When creating a CD/DVD with updates or installs that need to be shared with a large
number of end users in different locations
UAC Rule
Used to target an application that triggers a UAC prompt
 Pros:
 Can apply a rule to applications seamlessly to the user, without being presented
with a UAC prompt
 Can be used to effectively track what applications require elevated rights within the
PBW Auto Rule Creation tool.
 Can target a subset of applications that trigger UAC while allowing UAC to prompt
for non-approved software.
 Cons:
 Additional controls may be needed to limit what the UAC rule applies to
 Must be running on a UAC enabled OS to apply
43
 Best Use Case:
 In combination with the Challenge Response feature to allow Help Desk and Remote
staff to run processes requiring elevated rights
 In combination with PowerBroker Logging to assist in the discovery of applications
requiring elevated rights
Use Cases
Based on the various Rule Types defined in the previous section, these can be translated into
the following Use Cases. Please reference these as follow:
“When modifying permission and privileges of...” in the first column of the table, the best Rule
Type to “Use is a…”
To modify permissions and privileges of… Use is a…
A Windows process Path rule
A program in a specific location Path rule
A specific program regardless of location Hash rule
All applications published by a specific company Publisher rule
All programs in a specific folder Path rule with trailing

wildcard
A specific version of an application Publisher rule
An MSI package in a specific location MSI Path rule
All MSI packages in a specific folder MSI Path rule
All installations initiated by Internet Explorer ActiveX rule
Specific installations initiated by Internet Explorer ActiveX rule
Installation of all ActiveX controls ActiveX rule
Installation of specific ActiveX controls ActiveX rule
All applications on a certain CD or DVD CD/DVD rule
Any application that a user specifies Shell rule
An application that triggers a UAC prompt UAC rule

44
When “You want to...” in the first column of the table, the best Rule Type to “Use is a…”
You want to… Use is a…
Elevate the permission level for restricted users Path rule or Hash rule
performing a common Windows task or running an
application requiring higher privileges
Elevate the permission level for restricted users running Path rule with trailing wildcard
any applications in a specific folder
Reduce the permissions for administrators when using Path rule or Hash rule
applications such as Internet Explorer and Outlook
Elevate all applications from a specific company Publisher rule
Elevate a specific version of an application Publisher rule
Provide a self-service software installation point for Path rule for executable and MSI
restricted users Path rule for MSI packages, (both
with trailing wildcard)
Enable restricted users to use the Add Hardware wizard Path rule
or prevent users from using the wizard
Enable restricted users to add or remove plug and play Path rule
hardware or prevent users from adding plug and play
hardware
Enable restricted users to shut down their computers Path rule
Enable users to elevate applications on demand Shell rule
Enable users to elevate all applications on a certain CD or CD/DVD rule

DVD
Enable certain users to use credentials in UAC dialogs to UAC rule

initiate application launch

45
Scalability
To aid with the scaling of the solution in production, the statistics listed are based on Group
Policy Processing, Security Driver and Retina CS Tracing (BeyondInsight) disabled.
Metric / UVM Model Amount Per UVM20 UVMv20 UVM50

Metric
Maximum Assets N/A 5,000 5,000 12,500
Maximum Rules per 400 400 400 400
Policy
Max Number of File 20 N/A N/A N/A
Integrity Rules
Max Number of PBW 250 See BI Statistics See BI Statistics See BI Statistics
Events per Client/Day
Max Number of 20 See BI Statistics See BI Statistics See BI Statistics
Windows Events per
Client/Day
Max number of N/A 8 8 8
stacked policies, (BI)
stacked policies, (GPO)
stacked policies, (ePO)
Average Data Per 10MB N/A N/A N/A
Asset/Day (Dis)
Asset/Day (Prod)
Average Session Mon 2.7MB (50MB 10 10 25
Size/Session/Min per session)
PowerBroker for Mac (PBMac)

PowerBroker for Mac provides fine-grained policy-based privileged delegation for the Apple OS
X and MacOS environments. This solution allows organizations to remove local admin rights
from end users without changing the user’s behavior to execute an application. Policies for
PowerBroker for Mac are hosted within BeyondInsight and contribute to the capacity planning
requirements:
Metric / UVM Amount Per UVM20 UVMv20 UVM50

Model Metric
Maximum Assets N/A 5,000 5,000 12,500
Maximum Rules per 400 400 400 400
Policy

46
Asset/Day
PowerBroker Endpoint Protection Platform (PBEPP)

The PowerBroker Endpoint Protection Platform (Retina Protection Agent is a subset of the PB
EPP) combine system, web, and application firewalls, intrusion prevention, anti-malware and
virus, with a local vulnerability assessment capability. Policies are hosted by BeyondInsight and
frequency of vulnerabilities scans, malware, attack data, file integrity monitoring, and Windows
event log monitoring all contribute to capacity planning requirements:
Maximum Assets 5,000 5,000 10,000 N/A
Average Utilization Metrics per Agent

 Virus Scan of Type “Quick” with normal priority average 5 minutes
 Virus Scan of Type “Full” with normal priority average 15 minutes
 Vulnerability scan average 6 minutes and generate 1.5MB of data back to
BeyondInsight.
PowerBroker Auditing and Security Suite (PBASS)

BeyondTrust PowerBroker Auditing & Security Suite provides centralized real-time change
auditing for Active Directory, file systems, Exchange, SQL and NetApp. The solution also offers
the ability to provide real-time backup and restore Active Directory objects or attributes; and
helps to establish and enforce entitlements across the Windows infrastructure. Capacity
planning for each sub component is listed below:
Active Directory
Events Per Minute With Agent Performance Range
100 Changes CPU & Memory 2% higher 0% - 2% (5 Runs)
1000 Changes CPU & Memory 5% Higher 2% - 6% (5 Runs)
10,000 Changes CPU & Memory 6% higher 4% - 7% (5 Runs)
Exchange
47
*Testing was limited to 5,000 Events as data consistency beyond this varied
File Systems
100 Changes CPU & Memory 0% higher 0% (5 Runs)
500 Changes CPU & Memory 0% higher 0% (5 Runs)
Microsoft SQL
5000 Changes CPU & Memory 5% higher 3% 4% (5 Runs)
RETINA
Retina is a family of solutions from BeyondTrust that delivers complete coverage for
Vulnerability Management (VM) from vulnerability and configurator assessments to patch
management.
Retina Network Security Scanner (RNSS)

The Retina Network Security Scanner is designed to discover, profile and assess all assets
deployed on an organization’s network. When the Retina Network Security Scanner is
configured with BeyondInsight, organizations can efficiently discover, identify, prioritize and
optionally remediate vulnerabilities at remote client locations. As a standalone tool, the Retina
Network Security Scanner can be operated locally as a Windows application and has the
following capacity planning metrics. Please note, these apply for a single scan job and these
limitations and capacity planning guidelines also apply when the scanner is connected to
BeyondInsight.

48
Maximum Assets 20,000 20,000 50,000 5,000
Vulnerability Assessment Metrics

 Absolute Maximum Assets per Discovery Scan: Class-A
 Recommended Maximum Assets per Vulnerability Scan Job: 10,000
 Maximum Concurrent Administrative Users: 1
 Default Number of Simultaneous Scan Targets: 24
 Maximum Number of Simultaneous Scan Targets: 128
 A Discovery Scan of a single IP averages 0.04MB of bandwidth and 2 seconds.
 An Authenticated Detailed Discovery Scan of a single IP averages 8MB of bandwidth and
40 seconds.
 A Default Unauthenticated Vulnerability Scan of a single IP averages 11MB of bandwidth
and 250 seconds too complete.
 A Default Authenticated Vulnerability Scan of a single IP averages 55MB of bandwidth
and 325 seconds.
 A Default Authenticated Vulnerability Scan with the deployment of the Retina Local Scan
Service of a single IP averages 56MB of bandwidth and 365 seconds.
 A PCI Authenticated Vulnerability Scan with the deployment of the Retina Local Scan
Service of a single IP averages 73MB of bandwidth and 480 seconds.
Retina Recommended Scan Throttling Settings for Bandwidth Control
Slowest Simultaneous Adaptive Speed Ping Timeout Data Timeout

Common Link Targets
10GB Full 64* 5 1 1
Duplex
1GB Full Duplex 48* 5 2 2
100MB Full 24 5 3 3
Duplex
100MB Half 12 4 3 3
Duplex
10MB Full 10 3 4 4
Duplex
10MB Half 5 2 4 4
Duplex
* Each increase in the number of targets (by 24) increases RAM utilization on the scanner. An
additional 1GB of RAM should be included for 48 simultaneous targets and an additional 2GB of
RAM for 64 targets.
49
Retina Host Security Scanner (RHSS)
The Retina Host Security Scanner is a standalone headless of version of the Retina Network
Security Scanner designed to be an agent based solution for vulnerability assessment. It
requires BeyondInsight (Retina CS) or PowerShell for command and control. Capacity planning
requirements are not government by the agent since it only assesses the host it is installed on.
Metrics for performance and BeyondInsight management are listed below:
Maximum Assets 20,000 20,000 50,000 N/A

Please reference Appendix A for performance test results
Retina CS (RCS, BeyondInsight)

When BeyondInsight is only used for vulnerability management in an environment (no
PowerBroker or other Privileged Access Management components), the solution is commonly
referred to as Retina CS (Retina Compliance and Security). Retina CS is a combination of
BeyondInsight and the Retina Network Security Scanner deployed in a tiered architecture to
perform enterprise wide vulnerability management. It is important to note that the capacity of
a standalone scanner represents a single engine performing a single workload while Retina CS,
and distributed Event Collectors (a BeyondInsight Role) allow for the solutions capacity to scale
to hundreds of thousands of assets above a base installation. The capacity metrics below
represent a single base installation with no distributed scanners or Event Collectors:
Maximum Assets 20,000 20,000 50,000 65,000

Logged In Users
Maximum number of smart rules 150 150 500 NA
Retina Protection Agent (RPA)

The Retina Protection Agent is a subset of the PowerBroker Endpoint Protection Agent. It is
functionally identical except the firewalls and antivirus are disabled for compatibility with other
endpoint products. It is primary purpose is local vulnerability assessment* (like the Retina Host
Security Scanner) but also contains local Intrusion Prevention and File Integrity Monitoring
(FIM) layers required for various regulatory compliance initiatives. Policies for the Retina
Protection Agent are hosted by BeyondInsight and frequency of vulnerabilities scans and other
layers contribute to capacity planning requirements:

50
Maximum Assets 5,000 5,000 10,000 NA
 Vulnerability Scans average 5 minutes and 1.5 MB of data is sent back to BeyondInsight.
INFRASTRUCTURE
BeyondInsight contains several additional modules for performing updates, scalable
architectures, and routing of policies and password management. Each module has its own
capacity metrics for a typical deployment.
Enterprise Update Server (EUS)

The Enterprise Update Server is a piece of software (included with appliances) designed to
manage binary and audit updates for all BeyondTrust auto update (SyncIT) enabled solutions.
Architecturally, this is deployed within an organization to provide change control for
BeyondTrust software distribution. Capacity planning should consider the number of revisions
stored, number of modules and agents connected, and scaling of the Enterprise Update Server
from a primary to data centers, labs, and air gapped environments.
Maximum Number of Child EUS Connecting 50 50 50 NA

to a Single Parent EUS (Parent EUS being on
the UVM20, UVM50)
Maximum Number of Concurrent Logged in 10 10 10 NA
Users. This is for the control panel, not
updates.
Maximum concurrent RNSS bits updates* 500 500 1000 NA
Maximum concurrent RNSS audit updates* 500 500 1000 NA
Maximum concurrent RHSS bits updates* 500 500 1000 NA
Maximum concurrent RHSS audit updates* 500 500 1000 NA
Maximum concurrent RPA bits updates* 500 500 1000 NA
Maximum concurrent PBEPP bits updates* 500 500 1000 NA
Maximum concurrent PBEPP Anti-Virus 500 500 1000 NA
Signature updates*
 Assuming daily updates, the average audit update is <1 MB in size.
 Assuming daily updates, the average virus signature update is 4 MB in size.
 Assumes that enough bandwidth is available to serve updates.
Event Collector Role (EC)

The Event Collector (sometimes referred to as the Event Server) is a Role based component of
BeyondInsight which aggregates policies and events from distributed clients. The placement of
Event Collectors can electronically close to the BeyondInsight database or geographically

51
disperse to handle large and complex architectures. Below are the capacity planning
requirements for a single Event Collector acting in this Role:
Maximum Events per Day 5,000,000 5,000,000 10,000,000 N/A

Maximum Concurrent Agent 5,000 5,000 10,000 N/A
Connections
Worker Node Role (WN)

The Worker Node is a component of PowerBroker Password Safe and embedded as a Role
within BeyondInsight. It provides a mechanism to route password changes through the Worker
Node to remote targets as a secure “fan out” technology from the Password Safe primary
installation. Typically, this Role is deployed with an Event Collector and Retina Network Security
Scanner for performing remote discover and data aggregation. Capacity planning metrics below
consider this architecture:
Maximum Managed Accounts 30,000 30,000 250,000 N/A

Maximum Sessions – RDP 300 300 600 N/A
Maximum Sessions – SSH 600 600 900 N/A
CONCLUSION
This document detailed the capacity planning requirements per module for the PowerBroker
and Retina family of solutions by BeyondTrust. It covered each module individually and when
applicable, operating together. Special considerations have been noted for basic installations
and capacity planning when architecting for scalability, throughput, and distributed storage
requirements. This Capacity Planning Guide provides the foundation for designing and planning
for the life of your BeyondTrust solutions.

52
APPENDIX A PERFORMANCE TESTING RESULTS
Scenario 1 - Test environment for all bandwidth calculations and raw data
Vendor Component Version Host Details
Microsoft Microsoft SQL Server 2014 SP1 (12.0.42130.0) Windows Server 2012 R2
Standard
BeyondTrust UVM20 2.0.1
Password Safe 6.0.1.105 UVM20
BeyondInsight 6.0.1.105 UVM20
Retina Host Security Scanner 5.25 Windows 8.1
PowerBroker for Windows 7 Windows 7, Windows 10
PowerBroker for Unix & Linux 7.5 RedHat Enterprise Linux 5.5

Scenario 2 – Test environment for disk storage and throughput
Based on a standalone SQL environment for BeyondInsight, BeyondTrust has been able to extract the following performance and
capacity metrics. The profiled systems are virtual, with non-SSD disks, and average disk queues lower than 1 during profiling.
The data presented extrapolated is from 2 different test environments. In addition, all SQL servers have less RAM than the total
database size by approximately 33%:
 A SQL 2014 AlwaysOn HA pair for PowerBroker for Windows (PBW) only
 SQL 2008 R2 standalone server for PowerBroker Unix & Linux (PBUL), PowerBroker Password Safe (PBPS), Retina Network
Security Scanner (RNSS), and PowerBroker Endpoint Protection Platform (PBEPP)
Each set of data has been averaged across at least 3 runs of the respective tools. The column named “IDLE” is the baseline for each
environment. Each dataset used was 10 minutes long, and statistically datasets where the job being profiled was not running for at
least 90% of the log was discarded. The test criteria included:
 RNSS: 1 scanner, scanning 256 IPs, discovering 35 assets, credentialed scan.

 PBPS: 10% of discovered assets enrolled new, 1 account each asset. Includes RNSS Scanner processing.
 PBW: normalizing > 4000 events. Double the disk stats to get continuous storage of new events as well.
Values* IDLE PBPS PBW RNSS Grand Total
Average of Disk Read KBps 14.3 275.0 11.9 366.0 200.2
Max of Disk Read KBps 19.0 422.0 46.0 919.0 919.0
Average of Disk Write KBps 37.0 168.0 253.0 495.6 308.0
Max of Disk Write KBps 83.0 262.0 549.0 1391.0 1391.0
Average of Disk IOPs 4.4 16.0 3.8 35.7 19.4
Max of Disk IOPs 8.8 18.0 8.0 68.0 68.0
Average of Mirror Data KBps 0.0 17.8 11.9
Max of Mirror Data KBps 0.1 71.0 71.0
*All values are in Kilobytes, per Microsoft Performance Monitor. IOPs combine read and write. All disk stats combine log and
database.
54
ABOUT BEYONDTRUST
BeyondTrust® is a global security company that believes preventing data breaches requires the
right visibility to enable control over internal and external risks.
We give you the visibility to confidently reduce risks and the control to take proactive, informed
action against data breach threats. And because threats can come from anywhere, we built a
platform that unifies the most effective technologies for addressing both internal and external
risk: Privileged Account Management and Vulnerability Management. Our solutions grow with
your needs, making sure you maintain control no matter where your organization goes.
BeyondTrust's security solutions are trusted by over 4,000 customers worldwide, including over
half of the Fortune 100. To learn more about BeyondTrust, please visit www.beyondtrust.com.


Beyond Trust Capacity Planning Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Beyond Trust Capacity Planning Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Tech Brief

Capacity Planning Guide

Version 2.0 December 2016

Capacity Planning Guide 0

Appendix A Performance Testing Results 53

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

This document contains information, Limitations of Liability

The information contained in this document is

No trademark, copyright, or patent licenses are

For the latest updates to this Disclaimer

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

BeyondTrust Security Management Appliance UVM20 [Link]

Operating System Microsoft Windows 2012 R2 Server Standard

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

BeyondTrust Security Management Virtual Appliance UVMv20 [Link]

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

BeyondTrust Security Management Appliance UVM50 [Link]

Operating System Microsoft Windows 2012 R2 Server Standard

Retina Security Management Appliance 651 (VA651) [Link]

Operating System Windows 8.1 Embedded

Metric / UVM Model UVM20 UVMv20 UVM50 VA651

Maximum Active Assets 20,000 20,000 50,000 65,000

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Metric / UVM Model UVM20 UVMv20 UVM50 VA651

Maximum Assets 20.000 20,000 50,000 NA

PowerBroker Unix Linux (PBUL) and PowerBroker Sudo (PBSudo)

UNIX/Linux host in the customer environment

Operating System Most currently supported *NIX Operating systems

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

UNIX/Linux Policy Server host in the customer environment – Minimum Requirements

Operating System Most currently supported *NIX Operating systems

UNIX/Linux Log host in the customer environment – Minimum Requirements

Operating System Most currently supported *NIX Operating systems

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

UNIX/Linux Solr host in the customer environment – Minimum Requirements

Operating System Most currently supported *NIX Operating systems

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Optimizing to reduce Network Latency

Built-in network time-out and delay settings

Built-in alternative network port settings

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Optimizing Name Resolution

Nameresolutiontimeout - This keyword designates the length of time to wait

Optimizing Infrastructure Input/Output and resource limits

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Capacity Optimization summary

Capacity Planning Calculator (Generic)

RAM is disregarded for server capacity

Total Environment Size 25000

Total Environment Size 150000

Total Environment Size 300000

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Policy Server(s) Log Server(s) Clients(s)

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

############################ custom additions ########################

net.ipv4.tcp_rmem = 18240 87380 12582912

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

Metric / UVM Model UVM20 UVMv20 UVM50 VA651

Maximum Managed Accounts 30,000 30,000 250,000 N/A

Capacity Planning Guide © November 2016. BeyondTrust Software, Inc.

PowerBroker Identity Services (PBIS)