Plan for Deployment

Privileged Identity requires some basic installation prerequisites:

  • Database
  • IIS Web Server
  • Service Accounts
    • Management console user
    • Deferred processor
    • Web application

There are also some advanced features:

  • BeyondTrust Privileged Remote Access's SecureApp
  • Session recording
  • Zone processing

The database may be Microsoft SQL 2008 R2 or later, though we recommend using the most current version of Microsoft SQL Server. The IIS web server will be hosted on Windows Server 2012 R2 or later. A service account is required for the web application to access the database. The same service account can be used for the deferred processor or zone processors to perform scheduled jobs, though we recommend using a different service account.

Host systems require Microsoft .NET Framework version 4.5.2 or later. The management console host and deferred and zone processor hosts may also need Windows Management Framework v4 or later.

There are no permanent agents deployed with Privileged Identity, so network connectivity is required across a variety of ports depending on what is being managed.

For more information, please see the Privileged Identity Installation Guide.

When planning for a deployment, you need to answer six basic questions:

  • What platforms will be managed?
  • Where are those platforms physically and logically located?
  • For Windows domains or AD-joined Linux/Unix hosts, are there trusts in place between the various domains?
  • What accounts will be managed on those platforms, and what accounts will perform the management?
  • How much high availability infrastructure will you use during this deployment and for what components?
  • How will the infrastructure supporting Privileged Identity be deployed?

 

Remain aware of evolving business needs as you plan for deployment, and adjust resources accordingly. If you need to move managed systems between management sets, you can do so without fear of losing any password information.

Where Are the Target Systems Located?

Where the targets systems are physically located, relative to the Privileged Identity hosts, can affect the deployment strategy. For example:

  • An Amazon Web Services instance must be managed; however, no hosts are allowed direct connectivity to the internet. You must configure the use of a proxy server in order to manage the target AWS instance.
  • A Linux machine that resides in a DMZ must be managed. You could deploy a zone processor (and install the cross-platform support library) into the DMZ, stand up another Privileged Identity instance in the DMZ, or open up specific firewall ports.
  • If the systems are located across a high-speed WAN link, you might consider deploying a zone processor or managing them directly from the central location.

Logical separation is just as important as physical separation. In the context of Privileged Identity, logical separation refers to trusted versus untrusted systems. Trusted systems, Windows systems in particular, are very easy to manage from a central location with a single trusted account. Untrusted Windows systems can potentially be managed by the central instance of Privileged Identity if managing a single local account password, but when it comes to propagating the password to items like tasks, COM, and others, account impersonation becomes an issue and must be accounted for.

Determine where the systems are located, both physically and logically, to effectively design the infrastructure.

What Accounts Will I Manage?

It is important to consider what accounts will be managed and which accounts will perform the management.

In the Linux/Unix world, more so than the Windows world, there are many options for who will perform a management task and in what context. For example:

A low-powered account will log in and manage its own password. In this case, the account will issue passwd. In order to change its own password, it must:

  • Have permission to change its own password
  • Not be in violation of the minimum password age policy
  • Not be in violation of the password history policy
  • Not violate password requirements regarding length and complexity

A root account that performs a password change can change any user's password, by executing passwd userName. There is nothing else to consider in regards to a root account. In some cases, a root account can set passwords that do not comply with the configured password length; thus, complexity requirements and minimum age and history policies are not even considered.

This concept applies to all password changes across every platform: what account will log in and what account will be changed.

Should I Employ High Availability?

High availability (HA) should be employed whenever possible. All components of Privileged Identity support a highly available configuration. In most cases, an HA deployment is a function of the infrastructure the solution is installed on.

  • Database: Install the database as a cluster, database availability group (SQL AlwaysOn), or mirror. Potentially replicate the database to an alternate location.
  • Web App: Configure IIS hosts to be load-balanced using Microsoft load balancing or an external hardware load balancer.
  • Management Console: Deploy multiple management consoles on multiple servers.
  • Deferred/Zone Processors: Deploy multiple deferred or zone processors on multiple servers.

Virtualizing these host servers adds additional HA aspects such as virtual machine failover, hot migration, etc.

 

High Availability is no replacement for a good disaster recovery strategy. Be sure to perform regular database and virtual machine backups, no matter what HA strategy is employed.

How Will I Deploy the Infrastructure?

How you deploy your infrastructure will be impacted by the physical and logical layout of the network. The general guidelines are:

  • Choose the best location for your active database. Management consoles, web applications, web services, deferred processors, and zone processors must be able to communicate directly with this database. Typically clustered resources (cluster, AlwaysOn, mirror) are located on the same LAN. Databases may then be replicated to off-site databases.
  • Web application and web service hosts should be kept logically close to the database host. The information sent from client to web app and web service or vice versa is relatively small compared to the work sent between the web app and web service host and database. It is best to ensure a fast and reliable connection between the database and web app and web service host, even when web application users are far away or over a slow link.
  • Management consoles are typically installed on a central server and accessed via a remote desktop session (RDS). It is best to ensure a fast and reliable connection between the database and the primary management console, even when managers must use RDS over a slow link.
  • Zone processors should be deployed to the same network as managed targets. This minimizes the number of firewall configurations required and keeps management traffic close to the managed targets.

You must choose whether to deploy on physical or virtual systems, on-premises, or in the cloud. Most deployments occur on virtual machines located on-premises, though all of these scenarios, or combinations of these scenarios, are fully supported. There is no inherent difference to deploying on-premises versus in the cloud, and the basic connectivity and infrastructure requirements remain the same.

No component of Privileged Identity will work if the database is offline or inaccessible. Deferred and zone processors need constant connectivity to the database to maintain functionality. If a deferred processor attempts to start when the database is unavailable, it will fail to start and must be manually started. Web applications and web services will attempt a new connection to the database on each activation attempt.

Firewall Considerations

Firewall Diagram

You must take your firewall into consideration when deploying Privileged Identity. There are many components in Privileged Identity that must speak with each other and with other systems. Here are some of the communications that occur:

  • In the basic scenario, the management console, zone processors, deferred processors, web application, and web services all require communication with the central database, which listens on port 1433 by default.
  • Management occurs from the management console or zone/deferred processors over a variety of ports depending on the management targets.
  • Users connect to the web application and web services over HTTPS, port 443.
  • If the user clicks an application launch link, they will be directed to a remote desktop session (RDS) using port 3389.
  • The RDS server requires web service connectivity over HTTPS, port 443.
  • The RDS server creates a connection from itself to the management target with a specific application, which may further operate on a variety of ports.

 

Port Direction Description
22 TCP, outbound, SSH Used to manage SSH-based devices.
23 TCP, outbound, Telnet Used to manage non-Windows devices that support Telnet.
25/465/587 TCP, outbound, SMTP Used to send email. Only required if email notifications will be sent from Privileged Identity.
80/443 TCP, inbound, HTTP/S Used to access the web application and web service.
88 TCP/UDP, outbound, Kerberos Used by the jump server when authenticating with Kerberos.
135 & Ephemeral ports TCP/UDP, outbound, RPC port mapper service

Used for most Windows COM/DCOM-based operations. The remote DCOM management port and ephemeral ports are typically provided by granting access to DLLHOST.EXE in the %systemroot%\system32 directory. Ephemeral ports vary by target Windows operating systems.

  • COM/DCOM/MTS
  • Internet Information Services (IIS)
  • Scheduled Tasks (iTask interface)
  • SQL Server Reporting Services action account (SSRS)
  • SCOM RunAs accounts
161 TCP, outbound, SNMP

Used during system/network discovery operations and device management functions.
389/636 TCP, outbound, LDAP/LDAPS Used for LDAP-compliant directories such as Active Directory.
443 TCP, outbound, HTTPS Used for ESXi native management, as well as various cloud service providers and SAML/OAUTH authentication providers.
445 TCP, outbound, SMB

Used for Windows Server.
464 TCP/UDP, outbound, Kerberos Used by the jump server when authenticating with Kerberos.
514 UDP, outbound, syslog Used to communicate to logger systems such as ArcSight, QRadar, Splunk, syslog, etc.
623 UDP, outbound, IPMI Used to manage lights-out devices such as Dell DRAC, HP iLO, etc.
1025 TCP, outbound, Teradata Used to discover and manage Teradata databases.
1433 TCP, outbound, MS SQL Server Used to connect product components to the Microsoft SQL Server data store.
1521 TCP, outbound, Oracle Used to discover and manage Oracle databases.
3306 TCP, outbound, MySQL Used to discover and manage MySQL databases.
3389 TCP, outbound and inbound, Remote Desktop Protocol (RDP) Used for remote connections to target servers (automatic sessions) as well as inbound to the application launch server.
Port 5000 TCP, outbound, Sybase Used to discover and manage Sybase ASE databases.
Port 5432 TCP, outbound, PostgreSQL Used to discover and manage PostgreSQL databases.
Port 50000 TCP, outbound, DB2 Used to discover IBM DB2 databases.

When to Use Zone Processors

Privileged Identity can perform many different types of work, such as system discovery, account discovery, password rotation and propagation, and more. You can perform this work interactively (from the management console), or you can schedule this work to be performed at a specific time. Scheduling work for Privileged Identity to perform creates a job.

Running scheduled jobs requires a service to be present to run these jobs. The zone processor is employed to handle not only multiple network segments and divisions but also specific job types.

In this section, we'll identify multiple cases, as well as consider design and purchase decisions regarding zone processors.

In terms of code, there is no difference between a zone processor and a deferred processor. However, functionally, the difference is significant:

  • A deferred processor handles all job types for all systems in all management sets.
  • A zone processor handles specific job types for systems in one or more specific management sets.

The deferred processor does not account for additional zone processor assignments. As such, the deferred processor will run all jobs against all systems in all management sets.

Assign a zone processor to at least one specific management set and at least one specific job type, for example, password rotation. The zone processor will run only that specific job type against that specific set of systems defined in that specific management set. A zone processor will never try to manage anything else.

Zone processors are a licensed feature of Privileged Identity.