Privileged Identity Deployment and Sizing Guide

Transcription

1 Privileged Identity Deployment and Sizing Guide 2018 Bomgar Corporation. All rights reserved worldwide. BOMGAR and the BOMGAR logo are trademarks of Bomgar Corporation; other trademarks shown are the property of their respective owners. TC:5/21/2018

2 Table of Contents Deploy Privileged Identity 4 Planning for Deployment 5 What Platforms will be Managed? 6 Windows Considerations 7 Linux/UNIX Considerations 10 Cisco Device Considerations 12 AS400 Considerations 14 OS390 Considerations 15 IPMI Device (Lights Out) Considerations 16 Database Considerations 17 SQL Database Considerations 18 Oracle Database Considerations 19 Sybase ASE Considerations 20 MySQL and MariaDB Considerations 21 PostgreSQL Database Considerations 22 Teradata Considerations 23 DB2 Considerations 24 Xerox Phaser Printer Considerations 25 LDAP Considerations 26 McAfee epolicy Orchestrator Considerations 27 SAP Considerations 28 Oracle WebLogic Considerations 29 IBM WebSphere Considerations 30 Azure Active Directory Considerations 31 Amazon Web Services Considerations 32 RackSpace Public Cloud Considerations 33 SalesForce Considerations 34 Softlayer Considerations 35 VMware ESX Considerations 36 Other SSH & Telnet Considerations 37 Where are the Target Systems Located? 38 CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 2

3 What Accounts will be Managed? 39 Will High Availability be Employed? 40 How will the Infrastructure be Deployed? 41 Firewall Considerations 42 When to use Zone Processors 43 Zone Processor Use Case Scenarios 44 Deploying Zone Processors 48 Zone Processor Support Files 51 Deployment Strategies 52 Deployment: Single Server No HA 53 Deployment: Multi-System No HA 54 Deployment: Multi-System Minimum HA 55 Deployment: Multi-System Full HA 56 Deployment: Application Launching Minimum 57 Deployment: Application Launching Recommended 58 Customer Deployments 59 Sizing 61 Licensing 62 Database Host Sizing 64 Management Console and Zone Processor Sizing 68 Web App and Service Host Sizing 69 Application Launcher Sizing 70 Session Recording Sizing 71 Privileged Identity Limited Warranty 72 Privileged Identity License Agreement 73 CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 3

4 Deploy Privileged Identity Privileged Identity can be deployed centrally to manage one or more domains, whether trusted or untrusted, as well as adding management capabilities to DMZ systems or offline machines across multiple platforms. The goal of management, in the context of Privileged Identity is to gain control of privileged credentials, privileged sessions, remove permanent administrative access, and audit when the access is granted, to whom, and what they did with that access. Privileged Identity can perform thousands of management operations per minute from a single node, infrastructure permitting. This makes it one of the fastest management platforms in this space available and ideal for incident response. By placing Privileged Identity at the center of your network, it can integrated with Identity and access management product, governance products, security assessment products, orchestration products, and help provide automated incident response. This guide describes some of the key concepts when deploying Privileged Identity including database concepts, zone processors, high availability, and more. This guide also includes examples of real deployments and explanations. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 4

5 Planning for Deployment Privileged Identity requires some basic installation pre-requisites: Database IIS Web Server Service Account(s) There are also some advanced features: Application Launching Session Recording Zone Processing The database will be Microsoft SQL 2008 or later with Microsoft SQL 2014 or 2016 recommended. The IIS Web Server will be hosted on Windows Server 2012 R2 or Windows Server A service account is required for the web application to access the database. The same service account or a different one (recommended) can be used for the deferred processor or zone processors to perform scheduled jobs. The system will require Microsoft.Net Framework v4.5.2 or later versions from the CLRv4 family. The management console and deferred and zone processors may also need Windows Management Framework v4 or later. See the installation guide for more information on specific pre-requisites. There are no permanent agents deployed with Privileged Identity so network connectivity will be required across a variety of ports depending on what is being managed. See the installation guide for more information on specific port pre-requisites. When planning for a deployment you will need to answer six basic questions: What platforms will be managed and where? 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 we use during this deployment and for what components? How will the infrastructure supporting Privileged Identity be deployed? This chapter will help define the questions further and describe options. One important element to keep in mind as you plan for deployment is that needs change and new challenges arise during projects like this. Unlike some competing products, if you find your original deployment plan no longer meets the ever evolving needs, you can simply change the design and move systems and related information around as needed to meet these new requirements. If you need more capacity, add more capacity. Capacity comes in the form of server resources like CPU and RAM and capacity comes in the form of more supporting infrastructure like additional web servers or zone processors. If you need to move managed systems between management sets due to zone processor requirements, delegation requirements or anything else, do so without fear of losing any password information. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 5

6 What Platforms will be Managed? The question of what platforms will be managed relates directly to additional pre-requisites such as additional database providers, additional required components, ports and therefore firewall rules, as well as information regarding password policies, change frequencies, etc.. This section describes considerations for the management targets supported by Privileged Identity. The sections are presented in the default order listed in the management console, account store view. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 6

7 Windows Considerations Windows systems are typically domain joined systems and are managed with remote RPC calls. Windows systems, unlike other managed platforms provide management of subsystems, e.g. services, tasks, etc., via additional RPC calls beyond the normal system management RPC calls. How a Windows system is managed may vary depending on whether the target system is trusted or not. Consider the following topics: Account Discovery Local systems will allow administrators to enumerate all accounts on a Windows systems. For Active Directory, if you are not an administrator, you may successfully refresh portions of active directory for which you have read access to, though you will still receive a non-fatal error during the refresh as you will be unable to refresh domain controller system information without administrative rights. Password Management When changing a local account password, the change can occur by an administrative account or by the target account changing its own password. When performing an administrative password change, a password reset is actually being performed. When an account is used to change its own password, a change, not a reset, is being performed. When changing a domain account, this change can occur by an administrative account or by the target account changing its own password or by a delegated reset. The rights required for domain account password management by different accounts will vary based on the target account. In the default case, an administrator can change any other user's passwords, including other administrators. A user who has been delegated the reset password permission can reset any user's password, unless that user is in a protected group, unless you have modified the default permissions in Active Directory for the AdminSDHolder object to allow such changes by lower powered users. once permissions are defined on AdminSDHolder, a process called SDProp will periodically enforce those permissions. Thus if you change permissions on a protected account or group, those permissions will be replaced with those defined by AdminSDHolder when SDProp runs. As of this writing, this is the list of protected accounts and groups in Active Directory by Operating System: Windows 2000 <SP4 Windows 2000 SP4 - Windows Server 2003 RTM Windows Server 2003 SP1+ Account Operators Account Operators Account Operators Administrator Administrator Administrator Administrators Administrators Administrators Administrators Backup Operators Backup Operators Backup Operators Cert Publishers Domain Admins Domain Admins Domain Admins Domain Admins Enterprise Admins Domain Controllers Domain Controllers Domain Controllers Enterprise Admins Enterprise Admins Enterprise Admins Krbtgt Krbtgt Krbtgt Print Operators Print Operators Print Operators Windows Server Windows Server 2016 CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 7

8 Windows 2000 <SP4 Windows 2000 SP4 - Windows Server 2003 RTM Windows Server 2003 SP1+ Replicator Replicator Replicator Windows Server Windows Server 2016 Read-only Domain Controllers Schema Admins Schema Admins Schema Admins Schema Admins Server Operators Server Operators Server Operators Windows Server 2012 R2 (and Windows 8.1) also introduced a special protected groups called Protected Users. Your domain based service accounts should not be placed in this group. For more information, please refer to Microsoft documentation: Ports and Protocols Windows management will occur via various RPCs over a range of ports including port 445, 135 and ephemeral ports. Basic system refresh and local password management occurs over port 445 for all recent versions of Windows. Older versions of Windows, like Windows NT4 will accept management over ports Ephemeral ports are used during account usage discovery and password propagation. The ephemeral port range varies by Windows distribution and can be controlled in the Windows registry. The default ephemeral port range is as follows: Windows 2003 and earlier = Windows 2008 and later = These port ranges must be accounted for when configuring firewall rules for management of these hosts. Windows Propagations The service account performing management of the target Windows system must be an administrator to perform a refresh of account usage or perform password propagation. Below are special considerations for some of the possible Windows propagations. Windows Services - This uses the service control manager (SCM) to manage services. You can interactively call the SCM using the sc.exe program on a Windows machine. Management for this interface occurs over standard SMB port 445. Clustered services represent another management issue for administrators. The cluster API is OS specific. That means a Windows 2008 R2 cluster can only be remotely managed by another Windows 2008 R2 host. This concept is the same for Server 2012, Server 2012 R2, and Server If you will be managing clustered resources on Version-X of the Windows operating system, but Privileged Identity is hosted on Version-Y, you will likely need host a zone processor on a server running Windows Version-X. Windows Scheduled Tasks - This uses the itask interface over port 135 and ephemeral ports. The task interface is backwards compatible but not forward compatible. This means a Server 2012 R2 cannot manage a Server 2016 system's scheduled tasks. SCOM RunAs Accounts - Management and discovery of SCOM requires the SCOM SDK files be placed in the same directory as the Privileged Identity executables. SharePoint - Only a single admin port can be defined per installation of Privileged Identity. This means management of multiple installations of SharePoint farms from a single instance of Privileged Identity will require all SharePoint instances be set to use the same administrative port. The farm account cannot be managed by the SharePoint propagation. Rather, you must run an arbitrary process to call stsadm.exe from a command line to update this account. COM+ - Remote COM+ access is not enabled by default. Attempting to refresh or propagate to a COM+ application in this state will generate a non-critical error during management operations. COM+ Remote Access must be enabled through the CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 8

9 Application Server role or my enabling it in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3 and setting RemoteAccessEnabled=1. DCOM - Enumeration and management of the Windows DCOM system leverages remote registry. If the remote registry service is not running when this operation is performed, DCOM discovery and propagation will fail..net Config Files - This propagation is for management of the ASP.NET Data Sources object in IIS allowing IIS websites to connect to databases. Management of this item will deploy a temporary helper service to the target Windows machine called LiebsoftRemoteSvc.exe to \\servername\admin$\liebrmt. When the operation is finished, the file will self terminate and be removed. Anti-Virus programs can cause problems with this process. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 9

10 Linux/UNIX Considerations Linux and UNIX systems, also inclusive of OSX, Solaris, or other *NIX based platforms are managed by an interactive terminal session, very much like what an administrator will encounter when using other remote terminal products like PuTTy. One of the hard parts about *NIX management is the number of distributions throughout the world, let alone at a single customer's location. Different distributions can change many things regarding how management can occur such as password policy, encryption and MAC algorithms, password change interaction process, etc. Add to this any custom configurations such as login banners, prompt changes, type of account logging in, sudo replacements, and you have a lot to overcome to successfully manage any possible *NIX platform out there. Consider the following topics: Authentication Authentication to a *NIX host when establishing an SSH session can occur using a certificate or password. Users can be either local or from a central directory. While all scenarios are supported by Privileged Identity, each requires different considerations and planning, especially when using certificates. You must know how your systems require authentication. Account Discovery Account discovery for *NIX systems and Privileged Identity relies on the ability to read from /etc/shadow and /etc/password. Any permission or policy that prevents the Privileged Identity login account from reading this file, up to and including the files don't exist in the /etc directory or at all will prevent account enumeration from working. Versions of Privileged Identity prior to version 5.5.0, would copy the files from the *NIX host using SCP to the local Privileged Identity host for local parsing. This has since changed with version and later. The new process lists the contents of the files within the session which in turn allows for quicker operations and a low powered account that is allowed to use sudo to cat the files, specifically: sudo cat /etc/shadow. Password Management Privileged Identity can perform password management using a variety of methods. It is important to know which account will be managed and which account will manage it. Finally, you must know exactly what process is followed to perform that management. Management of passwords is performed using answer files (see the Admin Guide for more information). An answer file identifies what input is given to the system and what the expected output from that command will be. Any deviation can cause the password change job to incorrectly report the final status of the operation. Common password management scenarios include: Root changing its own password. Low powered account changing its own password. Low powered account will su to root, and root will change its own password. Low powered account will login and run a command using sudo to change another password. Each of the scenarios just listed can be different from machine to machine, even for the same distribution. This it is important to know how each of your target *NIX systems operate. Ports and Protocols Modern *NIX systems will use SSH as the defacto protocol for management operations. SSH uses a single port which defaults to TCP 22. If you are using Telnet for any reason, the default port is 23, but that can also be changed. Whether using SSH or Telnet, you will need to know the target port if you are configured to use an alternate port. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 10

11 Ports are configured in the answer files used for password management. If multiple systems are on different ports, you will need multiple answer files. If using Telnet, passwords cannot be programmatically passed, as they can with SSH. This means when using Telnet, your answer files must include not only the management steps but also the login process and you must edit/work with the Telnet portion of the answer file. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 11

12 Cisco Device Considerations Cisco devices are managed by an interactive terminal session, very much like what an administrator will encounter when using other remote terminal products like PuTTy. One of the hard parts about Cisco management is the changes introduced with various IOS revisions over time and custom configurations. Custom configurations can change many things regarding how management can occur such as password policy, encryption and MAC algorithms, password change interaction process, etc. Consider the following topics: Authentication Authentication to a Cisco device when establishing an SSH session can occur using a certificate or password. Users can be either local or from a central directory. While all scenarios are supported by Privileged Identity, each requires different considerations and planning, especially when using certificates. You must know how your systems require authentication. Account Discovery Cisco devices are not supported for account discovery. Password Management Privileged Identity can perform password management using a variety of methods. It is important to know which account will be managed and which account will manage it. Finally, you must know exactly what process is followed to perform that management. Management of passwords is performed using answer files (see the Admin Guide for more information). An answer file identifies what input is given to the system and what the expected output from that command will be. Any deviation can cause the password change job to incorrectly report the final status of the operation. Common password management scenarios include: Logging in as a vty account, switching to enable mode and changing the enable password/secret. Logging in as a vty account, switching to enable mode and changing the original vty account password. Logging in as a TACACS enabled account on a Cisco device joined to TACACS to change its own password. The same scenarios above but the login account is a priv15 account. Each of the scenarios listed can be different from device to device or customer to customer, even for the same physical device. This it is important to know how each of your target devices operate. If you login to the Cisco device as a non-priv15 user, you will need to enter enable mode which means you need an enable password to start with before you can change the enable password. Then you must know if you intend to set the enable secret or the enable password. After that process is complete, you may need to also perform a write memory command and possibly also a copy run start command to write and save the configuration, then again you may not. The need to perform either of the final actions is configuration dependent and IOS version dependent. Inclusion of TACACS and TACACS joined devices can further convolute this concept. When using TACACS accounts that will change their own password, the password must change more frequently than the password expiration cycle. The process for such a change with Privileged Identity will require an initial successful login to a joined Cisco device after which the account will re-ssh to the same device and initiate the userchangepassword function. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 12

13 Ports and Protocols Cisco devices ship with Telnet enabled by default and SSH must be enabled. It is highly recommended you use SSH for all password management to avoid the transmission of clear text passwords. SSH uses a single port which defaults to TCP 22. If you are using Telnet for any reason, the default port is 23, but that can also be changed. Whether using SSH or Telnet, you will need to know the target port if you are configured to use an alternate port. Ports are configured in the answer files used for password management. If multiple systems are on different ports, you will need multiple answer files. If using Telnet, passwords cannot be programmatically passed, as they can with SSH. This means when using Telnet, your answer files must include not only the management steps but also the login process and you must edit/work with the Telnet portion of the answer file. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 13

14 AS400 Considerations AS400 systems management varies by version and configuration to some extent. Consider the following topics: Authentication Authentication to an AS400 host when establishing an SSH session can occur using a certificate or password. Users can be either local or from a central directory. Telnet can only support password authentication. While all scenarios are supported by Privileged Identity, each requires different considerations and planning, especially when using certificates. You must know how your systems require authentication. Account Discovery Account discovery is not supported for AS400 systems. Password Management Privileged Identity can perform password management using a variety of methods. Ports and Protocols When not using SSH connectivity, they rely on a 5250 terminal terminal emulation is supported in Privileged Identity through an add-on component provided by DN-Computing ( terminals run over telnet, with or without SSL. You must know which port to use and if SSL is enabled. If using SSH, be aware of the target SSH port as well as allowed encryption and HMAC algorithms. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 14

15 OS390 Considerations OS390 systems management varies by version and configuration to some extent. Consider the following topics: Authentication Authentication to an OS390 host when establishing an SSH session can occur using a certificate or password. Users can be either local or from a central directory. Telnet can only support password authentication. While all scenarios are supported by Privileged Identity, each requires different considerations and planning, especially when using certificates. You must know how your systems require authentication. Account Discovery Account discovery is not supported for OS390 systems. Password Management Privileged Identity can perform password management using a variety of methods. Ports and Protocols When not using SSH connectivity, they rely on a 3270 terminal terminal emulation is supported in Privileged Identity through an add-on component provided by DN-Computing ( terminals run over telnet, with or without SSL. You must know which port to use and if SSL is enabled. If using SSH, be aware of the target SSH port as well as allowed encryption and HMAC algorithms. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 15

16 IPMI Device (Lights Out) Considerations IPMI devices, also known as Integrated Lights Out or Lights Out management devices cover a broad range of devices from many manufacturers. The IPMI specification was created by Intel and given to the world. Consider the following topics: Authentication Authentication to an IPMI device can occur using local credentials. This means the password for the management account must be known to Privileged Identity for initial management. Account Discovery Account discovery is supported on IPMI devices. Password Management Privileged Identity expects the login account, defined when enrolling the IPMI device, to be able to read all IPMI properties and change passwords. Ports and Protocols IPMI runs over UDP port 623. IPMI over Lan must be enabled on the target device and the target device must conform to the IPMI v1.5 or 2.0 specification. IPMI over Lan is not always enabled automatically and may require administrative configuration to enabled it. UDP port 623 is not typically opened by default on routed segments protected by firewalls. Contact your firewall administrator for more help on this matter. Known IPMI Device Issues HP ILO 2 device require BIOS revision 2.05 to be compatible with the IPMI specification. BIOS revisions earlier than 2.05 will likely encounter management errors until the BIOS can be upgraded. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 16

17 Database Considerations Each database platform has its own provider that must be installed. Where the provider is installed will depend on which Privileged Identity host will be managing the target database. For example, if host ZP1 will be managing Oracle databases, and host ZP2 will be managing Teradata databases, then ZP1 needs the 32bit Oracle OLEDB provider installed while ZP2 needs the Teradata 32bit provider installed. This section lists any known configuration requirements for target managed databases. See the installation guide for more information on obtaining and installing database providers and management account considerations. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 17

18 SQL Database Considerations Microsoft SQL Server versions 2000 through 2016 are supported for management and account discovery. Consider the following topics: Authentication Authentication to a Microsoft SQL server can be performed using an explicit SQL account (e.g. sa) or a trusted account from the local Windows host or joined directory. When working with a SQL server from a trusted domain, it is expected that the account running the console or scheduling service will be granted the appropriate permissions to the target SQL server or that the SQL Server will permit and be enrolled a proper explicit SQL server account. If attempting to manage a SQL instance on an untrusted host, relative to the Privileged Identity component server host, you will only be able to use an explicit SQL Server account. Account Discovery Account discovery is supported for target SQL Server instances provided the connection account has the Control Server server permission or is a member of the sysadmin role. Password Management Privileged Identity can manage passwords for target SQL Server instances provided the connection account has the Control Server server permission or is a member of the sysadmin role. Ports and Protocols For most installations of SQL server, including clustered resources, there will be no additional steps to take. However, SQL server does allow the configuration for the requirement of an SSL protected connection. If the connection is enabled for SSL or TLS 1.0, you will not need any additional software, but you will need to be aware of this fact when enrolling the SQL Server instance. If the SQL Server instance is configured to require TLS 1.2, you will need to install the latest SQL Server native client on any host that will manage such a SQL Server instance. SQL server listens on port 1433 by default, but this port can be configured per IP address or SQL instance. Be aware of any port changes to the SQL server or named instance requirements. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 18

19 Oracle Database Considerations Oracle databases are supported for management and account discovery. The versions supported by Privileged Identity will vary based on the installed provider. See below for more information. Consider the following topics: Authentication Authentication to an Oracle database can be performed using an explicit account only. Directory accounts are not supported for management of Oracle databases. Account Discovery Account discovery is supported for target Oracle database instances. Password Management Privileged Identity can manage passwords for target Oracle databases. Ports and Protocols For most installations of Oracle databases, including clustered resources, there will be no additional steps beyond installing the proper OLEDB provider on the Privileged Identity host performing the management. Oracle listens on port 1521 by default, but this port can be configured based on service/sid name. Be aware of port changes and to the names configured in the listeners file on the target Oracle database host. It will be helpful to obtain the listener file from the target Oracle databases. Provider Limitations Oracle artificially restricts management of down level database versions. Refer to Oracle documentation for more help. Privileged Identity supports use of 32bit Oracle OLEDB providers from version 11 and version 12. Oracle Client Version 11 supports oracle databases version 9-11g. Oracle Client Version 12 supports Oracle database version 10gR2-12 CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 19

20 Sybase ASE Considerations Sybase databases are supported for management and account discovery. See below for more information. Consider the following topics: Authentication Authentication to an Sybase database can be performed using an explicit account only. Directory accounts are not supported for management of Sybase databases. Account Discovery Account discovery is supported for target Sybase database instances. Password Management Privileged Identity can manage passwords for target Sybase databases. Ports and Protocols For most installations of Sybase databases, including clustered resources, there will be no additional steps beyond installing the proper OLEDB provider on the Privileged Identity host performing the management. Sybase listens on port 5000 by default, but this port can be changed. Be aware of port changes. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 20

21 MySQL and MariaDB Considerations MySQL and MariaDB databases are supported for management and account discovery. See below for more information. Consider the following topics: Authentication Authentication to an MySQL database can be performed using an explicit account only. Directory accounts are not supported for management of MySQL databases. MySQL uses a scheme to identify the source of the login account. For example, root@localhost can only login at localhost while root@% can login from any host. Your MySQL instances must each be configured with an account that allows access from your Privileged Identity host servers. You will need to know the default database name to connect to. Account Discovery Account discovery is supported for target MySQL database instances. Password Management Privileged Identity can manage passwords for target MySQL databases. Ports and Protocols For most installations of MySQL databases, including clustered resources, there will be no additional steps beyond installing the proper OLEDB provider on the Privileged Identity host performing the management. MySQL listens on port 3306 by default, but this port can be changed. Be aware of port changes. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 21

22 PostgreSQL Database Considerations PostgreSQL databases are supported for management and account discovery. See below for more information. Consider the following topics: Authentication Authentication to an PostgreSQL database can be performed using an explicit account only. Directory accounts are not supported for management of PostgreSQL databases. PostgreSQL authentication does not allow remote connections from anywhere out of the box and rules must be established to allow communications from specific hosts or networks. You will need to know the default database name to connect to. Account Discovery Account discovery is supported for target PostgreSQL database instances. Password Management Privileged Identity can manage passwords for target PostgreSQL databases. Ports and Protocols For most installations of PostgreSQL databases, including clustered resources, there will be no additional steps beyond installing the proper OLEDB provider on the Privileged Identity host performing the management. PostgreSQL listens on port 5432 by default, but this port can be changed. Be aware of port changes. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 22

23 Teradata Considerations Teradata databases are supported for management and account discovery. See below for more information. Consider the following topics: Authentication Authentication to an Teradata database can be performed using an explicit account only. Directory accounts are not supported for management of Teradata databases. You will need to know the default database name to connect to. Account Discovery Account discovery is supported for target Teradata database instances. Password Management Privileged Identity can manage passwords for target Teradata databases. Ports and Protocols For most installations of Teradata databases, including clustered resources, there will be no additional steps beyond installing the proper OLEDB provider on the Privileged Identity host performing the management. Teradata listens on port 1025 by default, but this port can be changed. Be aware of port changes. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 23

24 DB2 Considerations DB2 Database support associated account enumeration only. Consider the following topics: Authentication Authentication to an DB2 database can be performed using any non-managed account. You will need to know the default database name to connect to. Account Discovery Account discovery is supported for target DB2 database instances. Password Management There is no password management for DB2 databases as the accounts DB2 uses come from the local host or from a central directory. Ports and Protocols For most installations of DB2 databases, including clustered resources, there will be no additional steps beyond installing the proper OLEDB provider on the Privileged Identity host performing the management. DB2 listens on port by default, but this port can be changed. Be aware of port changes. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 24

25 Xerox Phaser Printer Considerations Xerox Phaser printers are simple to manage and have only once account: Administrator. Consider the following topics: Authentication Authentication to a Xerox Phaser Printer occurs over SNMP via the administrator account. This account can be renamed which means you must be aware of the current name of this account. Account Discovery Account discovery is not supported for Xerox Phaser printers as there is only one account. Password Management Privileged Identity can perform password management for Xerox Phaser printers, but will use the administrator account to change its own password. Ports and Protocols All management operations are performed via SNMP. The default SNMP port is 161. SNMP relies on a community name to aid in authentication. The default community name is public. The community name is subject to change during printer configuration. SNMP with SSL is not supported at this time. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 25

26 LDAP Considerations LDAP directories are supported for discovery and management. You will need to know a login name and the base LDAP path among other properties. See the admin guide for information on enrolling LDAP directories. There are four LDAP directory nodes re-defined in Privileged Identity. All four nodes operate the same way. The difference between any of the nodes is the default search and attribute parameters. You may use any node for any LDAP compliant directory you intend to discover and manage. Consider the following topics: Authentication To authenticate to an LDAP directory, you need the following information: Target server - the target server to query. Base LDAP path - the base LDAP path from which to begin the query. Authentication type - Integrated authentication is for Active Directory domains, anonymous authentication passes the anonymous username and no password, while explicit authentication passes a specific username and password. You must be aware of how the login username and password must be formatted and whether simple authentication is required or not. Login name and login format (simple vs not-simple logins). Port and protocol information - see below. Account Discovery Account discovery is supported by Privileged Identity for LDAP directories. To properly identify accounts you will need to know what the proper LDAP search filter is and the proper object identifier property is for your target LDAP directory. Searches will start at the base LDAP path. Assuming the base LDAP path and search filter is correct, the search may still fail if the LDAP authentication record is configured to use paged queries but the directory cannot use paged queries (or vice versa). Password Management Privileged Identity can perform password management for LDAP users provided the login account has the ability to reset target user passwords. Ports and Protocols All management operations are performed via LDAP. LDAP listed on port 389 by default, but directories can be configured for alternate LDAP ports or to use SSL. LDAP with SSL defaults to port 636. Typically, the port configuration doesn't change but the requirement for SSL (or TLS) may be required, where by default it is not. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 26

27 McAfee epolicy Orchestrator Considerations McAfee epolicy Orchestrator password changes occur by directly manipulating information in the ORION table or the epo database, which runs on Microsoft SQL Server. Access to this database must be available to Privileged Identity. Consider the following topics: Authentication Authentication to a Microsoft SQL server can be performed using an explicit SQL account (e.g. sa) or a trusted account from the local Windows host or joined directory. When working with a SQL server from a trusted domain, it is expected that the account running the console or scheduling service will be granted the appropriate permissions to the target SQL server or that the SQL Server will permit access with a proper explicit SQL server account. If attempting to manage a SQL instance on an untrusted host, relative to the Privileged Identity component server host, you will only be able to use an explicit SQL Server account. Account Discovery Account discovery is supported for target McAfee epo instances provided the connection account has the ability to read from the ORION table. Password Management Privileged Identity can manage passwords for target McAfee epo instances provided the connection account has the the ability to write/update the ORION table. Ports and Protocols For most installations of SQL server, including clustered resources, there will be no additional steps to take. However, SQL server does allow the configuration for the requirement of an SSL protected connection. If the connection is enabled for SSL or TLS, management of EPO accounts will not be possible. SQL server listens on port 1433 by default, but this port can be configured per IP address or SQL instance. Be aware of any port changes to the SQL server or named instance requirements. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 27

28 SAP Considerations Management of SAP targets is specific to SAP accounts in the core SAP product. Management can occur directly or through a NetWeaver gateway. Consider the following topics: Authentication Authentication to an SAP instance can occur with a local SAP account or a trusted account from another directory. If not using a gateway, you will need to know the following information: System Number Client Destination Table Name - default table name is USERLIST and Column Index is 0. If using a gateway, you need to know the following information: HTTP or Non-HTTP port URL Path to the server The Netweaver add-on must be installed on the gateway host. Account Discovery Account discovery is supported for target SAP instances for accounts found in the core SAP product. Password Management Privileged Identity can manage passwords for target SAP instances. Ports and Protocols Ports will vary based on your use of the Netweaver Gateway vs direct connection. Other Requirements Librfc32.dll must be provided and copied into the \Windows\system32 directory of the Privileged Identity host that will manage the SAP instance. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 28

29 Oracle WebLogic Considerations Management of Oracle WebLogic targets is specific to accounts in the core WebLogic product. Consider the following topics: Authentication Authentication to a WebLogic instance must use a local WebLogic account. Account Discovery Account discovery is supported for target WebLogic instances for accounts found in the core WebLogic product. Password Management Privileged Identity can manage passwords for target WebLogic instances. Ports and Protocols Ports for WebLogic can vary with installation and the use of SSL. The default ports are 7001 and 7002 with SSL. Other Requirements An EAR file must be installed as an enterprise application and start with the WebLogic instance. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 29

30 IBM WebSphere Considerations Management of IBM WebSphere targets is specific to accounts in the core WebSphere product. Consider the following topics: Authentication Authentication to a WebSphere instance must use a local WebSphere account. Account Discovery Account discovery is supported for target WebSphere instances for accounts found in the core WebSphere product. Password Management Privileged Identity can manage passwords for target WebSphere instances. Ports and Protocols Ports for WebSphere can vary with installation and the use of SSL. The default ports are 9080 and 9443 with SSL. Other Requirements An EAR file must be installed as an enterprise application and start with the WebSphere instance. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 30

31 Azure Active Directory Considerations Management of Azure Active Directory accounts is supported by Privileged Identity. Consider the following topics: Authentication Authentication to Azure AD will use an Azure AD account supplied as an address. You will also require the following information: Client ID Tenant ID Subscription ID Management Certificate and Certificate password - optional - used for discovering systems in the Azure instance. Account Discovery Account discovery is supported for Azure AD. Password Management Privileged Identity can manage passwords for Azure AD accounts. Standard Active Directory account management permissions apply. Ports and Protocols All management functions will occur over an HTTPS connection. If the Privileged Identity host cannot connect directly to the internet, you may also need to configure a proxy server connection when enrolling the Azure instance. Other Requirements If using Azure AD as an authentication source for users logging into the web application, an application must also be configured in Azure AD. See the Admin Guide for more information. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 31

32 Amazon Web Services Considerations Management of Amazon Web Services accounts is supported by Privileged Identity. Consider the following topics: Authentication Authentication to Amazon will use an Amazon account configured with an API certificate. This certificate (alternate name and password) is what will be used for AWS management. Account Discovery Account discovery is supported for AWS. Password Management Privileged Identity can manage passwords for AWS accounts. Ports and Protocols All management functions will occur over an HTTPS connection. If the Privileged Identity host cannot connect directly to the internet, you may also need to configure a proxy server connection when enrolling the AWS instance. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 32

33 RackSpace Public Cloud Considerations Management of RackSpace accounts is supported by Privileged Identity. Consider the following topics: Authentication Authentication to RackSpace will use an explicit username and password. Account Discovery Account discovery is supported for RackSpace. Password Management Privileged Identity can manage passwords for RackSpace accounts. Ports and Protocols All management functions will occur over an HTTPS connection. If the Privileged Identity host cannot connect directly to the internet, you may also need to configure a proxy server connection when enrolling the RackSpace instance. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 33

34 SalesForce Considerations Management of SalesForce accounts is supported by Privileged Identity. Consider the following topics: Authentication Authentication to SalesForce will use an account supplied as an address. An application must be configured in SalesForce to allow connectivity. From this application will require the following information: Consumer Key Consumer Secret Account Discovery Account discovery is supported for SalesForce accounts that are enrolled with the Chatter service. Password Management Privileged Identity can manage passwords for SalesForce accounts provided the login user is permitted to change passwords and the application allows that sort of management. Ports and Protocols All management functions will occur over an HTTPS connection. If the Privileged Identity host cannot connect directly to the internet, you may also need to configure a proxy server connection when enrolling the SalesForce instance. Other Requirements If using SalesForce as an authentication source for users logging into the web application, an application must also be configured to allow authentication in SalesForce. See the Admin Guide for more information. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 34

35 Softlayer Considerations Management of Softlayer accounts is supported by Privileged Identity. Consider the following topics: Authentication Authentication to Softlayer will use an explicit username and password. Account Discovery Account discovery is supported for Softlayer. Password Management Privileged Identity can manage passwords for Softlayer accounts. Ports and Protocols All management functions will occur over an HTTPS connection. If the Privileged Identity host cannot connect directly to the internet, you may also need to configure a proxy server connection when enrolling the Softlayer instance. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 35

36 VMware ESX Considerations Management of VMware ESX accounts is supported by Privileged Identity. Consider the following topics: Authentication Authentication to VMware ESX will use an explicit username and password. Account Discovery Account discovery is supported for VMware ESX. Password Management Privileged Identity can manage passwords for VMware ESX accounts. Ports and Protocols All management functions will occur over an HTTPS connection. If the Privileged Identity host cannot connect directly to the ESX host, you may also need to configure a proxy server connection when enrolling the VMware ESX instance. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 36

37 Other SSH & Telnet Considerations Most any network device that can be managed via SSH or Telnet can be managed by Privileged Identity, even if there is not a specific node for the target system, for example F5 devices. Custom account stores can be created for these devices or these devices can be added to other SSH/Telnet based nodes, such as the Linux/UNIX node. Consider the following topics: Authentication Authentication to an SSH host when establishing an SSH session can occur using a certificate or password. Users can be either local or from a central directory. While all scenarios are supported by Privileged Identity, each requires different considerations and planning, especially when using certificates. You must know how your systems require authentication. Account Discovery Account discovery for SSH systems and Privileged Identity relies on the ability to read from /etc/shadow and /etc/password. Any permission or policy that prevents the Privileged Identity login account from reading this file, up to and including the files don't exist in the /etc directory or at all will prevent account enumeration from working. Versions of Privileged Identity prior to version 5.5.0, would copy the files from the SSH host using SCP to the local Privileged Identity host for local parsing. This has since changed with version and later. The new process lists the contents of the files within the session which in turn allows for quicker operations and a low powered account that is allowed to use sudo to cat the files, specifically: sudo cat /etc/shadow. Password Management Privileged Identity can perform password management using a variety of methods. It is important to know which account will be managed and which account will manage it. Finally, you must know exactly what process is followed to perform that management. Management of passwords is performed using answer files (see the Admin Guide for more information). An answer file identifies what input is given to the system and what the expected output from that command will be. Any deviation can cause the password change job to incorrectly report the final status of the operation. Ports and Protocols Modern SSH systems will use SSH as the defacto protocol for management operations. SSH uses a single port which defaults to TCP 22. If you are using Telnet for any reason, the default port is 23, but that can also be changed. Whether using SSH or Telnet, you will need to know the target port if you are configured to use an alternate port. Ports are configured in the answer files used for password management. If multiple systems are on different ports, you will need multiple answer files. If using Telnet, passwords cannot be programmatically passed, as they can with SSH. This means when using Telnet, your answer files must include not only the management steps but also the login process and you must edit/work with the Telnet portion of the answer file. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 37

38 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 crossplatformsupportlibrary) into the DMZ or 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 directly from the central location. Logical separation is just as important as physical separation. In this case 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 just a 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. Determining where the system are located, both physically and logically, helps design an effective infrastructure. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 38

39 What Accounts will be Managed? What accounts will be managed and which accounts will perform the management is an important consideration. In the *NIX 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 login and will manage its own password. In this case, the account will issue passwd. In order to change its own password, it must be able 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. Whereas a root account performing a password change can change any users password, issuing passwd username. Regarding a root account, there is nothing else to consider. In some cases, a root account can set passwords that do not comply with the configured password length and complexity requirements and minimum age and history policies are not even considered. This same concept applies to all password changes across every platform: what account will login and what account will be changed. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 39

40 Will High Availability be Employed? High availability 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 - 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. Application Launcher - Configure Microsoft RDS in an RDS farm. Virtualizing these host servers adds additional HA aspects such as virtual machine fail over, hot migration, etc.. High Availability is no replacement for a good disaster recovery (DR) strategy, so be sure to perform regular database and VM backups, no matter what HA strategy is employed! CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 40

41 How will the Infrastructure be Deployed? How the infrastructure will be deployed 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, and deferred/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/service or vice versa is relatively small compared to the work sent between the web application/service host and database. It is best to ensure a fast and reliable connection between the database and web application/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. 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. Application Launcher servers will be kept close to the systems they are connecting to with launched applications. These need connectivity to the web service hosts and users must be able to use remote desktop services (remote app) to the these bastion hosts. Session recording, specifically the free session recording included with the application launcher feature, will be installed on the application launcher hosts. However, recorded files must be written back to a central location that can be accessed by the streaming media server(s). Microsoft's distributed file system (DFS) is often use to make this deployment easier. Choosing to deploy on physical or virtual systems, on premise or in the cloud, is a choice you must make. Most deployments happen on virtual machines located on premise, though all of these scenarios, or combinations of these scenarios, are fully supported. There is no inherent difference to deploying on premise 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. A deferred/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. This means there is no additional steps required to start a web service or application if the database is unavailable at any time. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 41

42 Firewall Considerations Firewall configurations must be considered 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. The database listens on a specific port, by default, Management occurs from the management console or zone/deferred processors over a variety of ports depending on the management targets. Users will connect to the web application and web services over HTTPS. HTTPS defaults to port 443. If they click an application launch link, the user will be directed to a remote app session (RDS). RDS defaults to port The RDS server will require web service connectivity over HTTPS which defaults to port 443. The RDS server will create a connection from itself to the management target with a specific application which may further operate on a variety of ports. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 42

43 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 (by the user running the administrative console) or can schedule this work to be performed at a scheduled time. Creating work for Privileged Identity to perform creates a job. To run a job which is scheduled for the future requires a service be present to run these jobs. Historically, the service Privileged Identity provided for this was simply called the Deferred Processor or Default Deferred Processor Over time it became necessary for Privileged Identity to service multiple segments or divisions of a single company. In the original design premise, the design of default deferred processor proved insufficient and/or inefficient to handle the needs of companies with multiple network segments or divisions. This led to the evolution of the deferred processor into what is presently referred to as a Zone Processor. The design premise of what is called a zone processor is to specifically handle multiple network segments or divisions within a company. In recent years, the zone processor has evolved to handle not only multiple network segments and divisions, but also to be able to handle specific job types. It is these evolutions that has led to some confusion about when or why or where a zone processor may be necessary. It is the purpose of this section to identify multiple cases and design & purchase decisions regarding zone processors. Code wise, there is no difference between a ZP and a DP; they start off life as the exact same files. Functionally, the difference is significant: A deferred processor handles all job types for all systems in all management sets. A zone processors handles specific job types for any systems in one or more specific management sets. The deferred processor is simply installed. It will run any and all jobs against any and all systems in any and all management sets. The deferred processor does not account for additional zone processor assignments. As such, the deferred processor will run any and all jobs against any and all systems in any and all management sets. A zone processor is assigned to at least one specific management set and at least one specific job type (e.g. password rotation). As such the zone processor will only run 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. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 43

44 Zone Processor Use Case Scenarios The question of when to deploy a deferred processor is easy to answer: deploy a deferred processor when you wish to schedule jobs to run in the future without a human present and there is no need to segregate any of the system management. The question of when to deploy a zone processor is also easy to answer: deploy a zone processor when you wish to schedule jobs to run in the future without a human present and there is a need to segregate at least some of the system management or the WAN links are already slow and saturated or there are security concerns around management. The third scenario shows a hybridization of the ZP vs. DP design: let the processor run against any management set, but restrict the processor to a specific job type. This additional scenario became possible once Privileged Identity could define what job types a zone processor could run. With this scenario, it is not quite as black and white as it once was when trying to license or design a zone processor topology. The following scenarios are designed to show when it would be necessary to have zone processors with or without a deferred processor and in what configurations they would be found. Scenario 1: All Access Everywhere #1 In a well-connected network with high speed highly reliable links where there is no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity then one or more deferred processors will suit the customer just fine. This scenario will make use of: One or more deferred processors only. There is no need for multiple consoles or zone processors. Scenario 2: All Access Everywhere #2 In a well-connected network with high speed highly reliable links where there is no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity, or where the customer simply wishes to improve the job processing throughput of the job scheduling system, multiple deferred processors or multiple deferred processors and zone processors will be sufficient. In Privileged Identity, a single job processor can handle only one job at a time. This can lead to other jobs getting backed up in the job queue until a job processor becomes available. If there are two processors, then two jobs may run simultaneously. This concept will scale linearly. More processors means more jobs at the same time. This scenario will make use of: Multiple deferred processors and/or multiple zone processors. No special configuration of anything is required. Scenario 3: All Access Everywhere #3 In a well-connected network with high speed highly reliable links where there is no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity then one or more deferred processors will suit the customer just fine. Additionally, the customer wants to ensure password change jobs do not interfere with account elevation jobs. The last requirement could indicate a desire - not necessarily a need - to install an additional deferred processor or zone processor to manage any and all management sets and simply be restricted to account elevation jobs. This scenario will make use of either: CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 44

45 Multiple deferred processors where one or more DPs runs all job types and additionally one or more DPs runs only account elevation jobs. Multiple consoles required. One or more deferred processors to handle all job types and one or more zone processors to handle only account elevation jobs. There are no pros or cons to either choice. The path to choose will depend on the desire to have every processor manage any system or have a specific [zone] processor be limited in scope to specific systems. Scenario 4: WAN Links with All Access Everywhere #1 In a scenario where the customer's organization is divided into multiple geographical regions separated by WAN links (wide area networks) where WAN traffic is NOT a concern, where there is no well-defined internal security boundaries, or if there are boundaries, they will not be managed by this instance of Privileged Identity then one or more deferred processors will suit the customer just fine. This scenario will make use of: One or more deferred processors only. There is no need for multiple consoles or zone processors. Scenario 5: WAN Links with All Access Everywhere #2 In a scenario where the customer's organization is divided into multiple geographical regions separated by WAN links (wide area networks) where WAN traffic IS a concern, it will be highly recommended, and likely customer required, to use zone processors. In this scenario, the customer will be concerned about the amount of traffic that Privileged Identity will send over a WAN link from a central point. Rightfully so, hundreds of simultaneous connections from a single source can be problematic over slow and/or unreliable long distance links or where there is a need from the customer's perspective to not send management traffic over the link. At this point is will be necessary to determine the number of locations/regions/offices that will require a zone processor and if it is a hard requirement to NOT send traffic over the link or only a SHOULD NOT send traffic over the link but is OK if it does type of requirement. If this is a hard requirement to ensure no management traffic goes over the WAN link, then each segment, including the segment where Privileged Identity is actually located, will need its own zone processor. Further, Privileged Identity must have the default deferred processor(s) configured to not run discovery/refresh jobs or management jobs. The DP may still be present and running and processing management set updates, but should be configured to not perform any systems management. A management set will be required for each segment where there will be a zone processor. If this is a soft requirement where the customer would prefer a zone processor to handle a job locally on the segment, but it is OK if the management traffic traverses the WAN links, then configure zone processors in each of the zones and let the default deferred processor continue with its default configuration to manage anything anywhere. It should be noted to the customer, that this is not a system of preference, it is a system of availability. If the default deferred processor is available before a ZP for a zone is available, the default deferred processor will run the job over the WAN links, even if the ZP could have run the job just one second later. Scenario 6: A Customer with a DMZ A DMZ (de-militarized zone) is a section of a network where traffic is explicitly cut off from the rest of the network. The customer thinks in terms of the internal network (where they are), the DMZ (where the secured servers are) and the external network (AKA the internet). When the customer has a DMZ to manage, they have four choices for Privileged Identity configuration: Completely open the firewall to allow the Privileged Identity host full access into the DMZ from the internal network. This will likely never happen as it defeats the purpose of having the DMZ. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 45

46 Allow the Privileged Identity host to establish a VPN (private on-demand connection) into the DMZ and have full access from the internal network. This also, will likely never happen as it defeats the purpose of having the DMZ. Stand up a separate instance of Privileged Identity in the DMZ. This sometimes happens, but since it at least doubles the MS Windows, and MS SQL licensing requirements plus the Privileged Identity management requirements, this rarely happens. Creating a standalone instance of Privileged Identity is not a bad design decision as it fully separates the infrastructure and exposure if Privileged Identity ever gets compromised internally or externally, but it is one that rarely gains traction. Install a zone processor in the DMZ to handle the DMZ systems. Allow that zone processor (known host) access through the firewall (one direction, one port, known host) to the Privileged Identity central database (known destination, known port). This is often the most accepted scenario when working with DMZ as it is familiar, comfortable, easy to manage, easy to understand, easy to secure, and the customer does not have to contend with Bomgar Lieberman's version of application security. Building on option 4, as this is the most used zone processor scenario, the customer will want - really the customer will need - to setup zone processors for each zone. In this scenario there are only two zones: internal and DMZ. The customer may allow the deferred processor to run but should (read must) turn off the ability of the deferred processor to perform password changes or discoveries. It should be relegated to admin activity reports and management set updates only. The customer will need one zone processor for the internal network and one for the DMZ. If the last two items are not configured as described, the following will occur: The default deferred processor may attempt to manage DMZ systems. This will fail as the DMZ does not allow incoming connections from the internal network. Item 1, will cause the job to fail. This will cause unnecessary alerts to be generated from Privileged Identity and cause unnecessary human response. As the deferred processor can decide what jobs are most past due more quickly than a ZP, it will likely begin to monopolize the job (which keeps failing and generating alerts) which creates a vicious cycle where the job can never run and exhausts retries causing the job to never actually run successfully on schedule. This will cause the password change cycle to become out of spec and possibly the client to be out of compliance. Scenario 7: Customer with WAN Links and DMZs See scenario 6. A DMZ will essentially mandate a zone processor for every zone and proper (limited) configuration of the deferred processor to not run password change or discovery jobs. Scenario 8: Customer Has Trust Issues This scenario applies to managing Windows workstations and servers only. In the Windows world, there is a concept of trust. Trust is what allows an identity from one domain to access a resource in another domain. If there is a trust in place and going in the correct direction (it is possible for A to trust B but for B to not trust A) and Privileged Identity is in on the correct side of that trust, then things are relatively easy. But if there is no trust or Privileged Identity is on the wrong side of that trust, then things are going to be more complex. If there are trusts in place and Privileged Identity is on the correct side of the trust, then refer to the previously described scenarios. If there are no trusts in place or Privileged Identity is on the incorrect side of the trust, then zone processors will likely be necessary if the customer desires to manage the whole network through a single instance if Privileged Identity. This will require further investigation. Specifically determine: Will the customer solely be dealing with password changes (domain or local) and not propagating those password changes to scheduled tasks, IIS, COM/DCOM or other remote COM related items? CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 46

47 If the answer to this entire question is yes, the scope will be limited AND no we will not propagate to any of those items, zone processors may not be required. Alternate administrators or cached credentials could be used in this scenario so long as the customer's environment falls under scenario 1, 2 or 3. If the customer's scenario falls under case 4, 5 or 6 a zone processor will likely be required. If the answer to the question indicates that propagation may be required, then likely, a zone processor will be required. If zone processors are a requirement there would be no less than two zone processors (assuming only two domains. The actual number of zone processors required will be determined through further discovery of the total number of untrusted domains, DMZs, regions, etc. as defined in the prior scenarios. Scenario 9: Clustered Services This scenario applied to managing Windows servers only. Privileged Identity can propagate passwords. This means that once the password is changed for the account in question, Privileged Identity can also update all the other references for the account such as those used by Windows services. Windows allows for clustered services. Clustering is a means of ensuring that even if the service in question ( , database, web, etc.) go down on one server, there is a duplicate service on another machine that will stay functional and continue to provide service to the customer. Privileged Identity can propagate password changes to Windows clustered services. However, there are some considerations: The most important consideration is that starting with Windows Server 2008, the management of clustered services is no longer backward or forward compatible. Clustered services running on a Windows Server 2008 host cannot be managed by a Windows Server 2012 host or vice versa. This is a limitation imposed by Microsoft. So when dealing with a customer who is managing clustered services the important question is if the clustered services are hosted on a version of Windows that is exactly the same as the Windows OS that is running Privileged Identity. If the operating systems are not the same, then zone processors will be required. This scenario, to guarantee there are no problems during password propagation, will require that all zones including the zone where Privileged Identity is hosted, will require a zone processor. The default deferred processor, if left enabled, must be configured to NOT perform password management jobs to guarantee the correct zone processor with the correct OS requirements manages the services or there will be a service outage or possible failover/destruction of the cluster. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 47

48 Deploying Zone Processors Management sets are used to define the lists of systems that a zone processor will be responsible for. Thus proper planning of management sets is essential to proper deployment of zone processors. Consider a network with only two segments: internal and DMZ. At a minimum, two management sets will be created, one for each zone. In turn, a zone processor will be deployed and assigned to each specific management set. In this way, when you create a job destined for an internal system, it is run by the internal zone processor. Similarly, when you create a job destined for a server in the DMZ, it is run by the zone processor in the DMZ. Zone processors require direct connectivity to the database. This communication is unidirectional from a known source to a known destination over a known port. Specifically, the communication is initiating from the zone processor host to the central database over the SQL communications port. At a Glance When the zone processor feature is enabled, the Zone Processors button will be available in the Stored Jobs dialog, available by clicking the Jobs button in the management console. Zone Processors can be deployed by pushing the zone processors files and settings from the management console (by clicking install) on the Zone Processors dialog, or by using the standalone installer, available in the in the SupplementalInstallers folder within the installation directory. The standalone installer must be configured for each zone you are deploying a zone processor to. When installing a zone processor, pre-requisites such as.net framework requirements, Windows Management Framework requirements, and required database provider requirements are not verified. If the correct database provider is not present when the zone processor attempts to startup, the startup process will fail. Pushing a Zone Processor When pushing a zone processor, you will require file system and remote registry access to the target host. If either of these is unavailable, the push will fail. When pushing a zone processor, the database configuration will be identical to that currently configured for the management console. 1. In the management console, click the Jobs button. 2. On the Stored Jobs dialog, click Zone Processors. Note, if you don't see the Zone Processors button, the feature is not enabled. 3. Click Install. 4. Supply the following information: Installation system - this is the name (simple, IP, or FQDN) for the ZP host. Unique instance ID - This is instance ID of this zone processor. It must be unique on that system to avoid collisions with other zone processors hosted on the same system. Service account FQDN - The qualified name of the account that will run the service. It must be an administrator of the target host and be granted logon as a service. If using integrated authentication to the database, this account must also have proper database access as defined in the installation guide. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 48

49 Local file path for service - The physical location for the zone processor and its supporting files to be copied to. Enabled job types - Specify the types of jobs this zone processor will be allowed to perform. Management Sets - Specify one or more management sets this zone processor will be responsible for managing. Note that if a job is created against a system in another management set, where the system is also a member of this target management set, this zone processor will attempt to manage that system. Remove all management sets to allow the zone processor to manage all management sets. 5. Click OK to begin the process. The files will be copied, the registry configured, but you will need to start the service as a separate step. Zone Processors Via Standalone Installer When a zone processor cannot be automatically pushed, such as when dealing with an untrusted system or DMZ, use the zone processor standalone installer located in the SupplementalInstallers directory. 1. Launch CreateZoneInstaller.exe. 2. Supply the following information: Installer Template - This value will already be configured. New Installer - This is the new file that will be created and distributed to the target ZP host(s). Job Log Path - Change the log file path for jobs if desired. Service Log Path - Change the log file path for the zone processor scheduling service if desired. Zone ID - This is instance ID of this zone processor. It must be unique on that system to avoid collisions with other zone processors hosted on the same system. Service Account Username - The qualified name of the account that will run the service. It must be an administrator of the target host and be granted logon as a service. If using integrated authentication to the database, this account must also have proper database access as defined in the installation guide. Service Account Password - The password for the service account. Click the Encrypt button to encrypt the password inside of the created installer package. If you don't encrypt the password, the password will be kept in clear text in the installer package. Management Set Affinity - Define one or more management sets to assign to the zone processor. If assigning more than one management set, separate management set names by a semi-colon. Job Affinity - Define the job types this zone processor will run. Database Settings - If no settings are made, this installer will use the same database settings currently defined in the console, even if they might not work for this specific zone processor. Click the ellipses (...) next to Database settings to define custom settings for this zone processor to use when connecting to the database, such as changing the server name to an IP address or changing authentication to an explicit SQL account rather than integrated authentication. After making changes, select the option for Use Customized DB Settings. Retry Options - if no settings are made, the installer will use the same retry settings as currently defined for this management console. Click the ellipses (...) to configure a different retry policy for this zone processor. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 49

50 3. Click Create. 4. Copy the new MSI file to the target machine and install it. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 50

51 Zone Processor Support Files When deploying a zone processor, it will be successful in managing Windows systems for password changes not involving propagation. Located in the SupplementalInstallers folder are additional helper files. If you need have any of the following needs, you must install IntegrationComponents.msi on the zone processor host: Password Propagation Help Desk Ticketing Integrations Event Sink notifications Help desk integration support also requires certain file system and registry information be manually copied from the management console host. See the admin guide for more information. If you need have any of the following needs, you must install CrossPlatformSupportLibrary.msi on the zone processor host: Connecting to anything with SSH or Telnet Connecting to other non-windows platforms CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 51

52 Deployment Strategies This chapter lists some of the possible deployment strategies for Privileged Identity and will also describe some customer deployment scenarios. Included are descriptions of bare minimum deployments through enterprise deployments. Zone processor are always custom implementations and are configured to meet your specific requirements. The implementations noted in this section are for reference only. CONTACT BOMGAR (US) +44 (0) (UK/EMEA) BOMGAR.COM 52

53 Deployment: Single Server No HA A bare minimum installation will use a single server. The single machine will host the database, management console, website web service. If purchased, this same system could also host the application launcher and session recording software. This system may be a virtual system or a physical system. If this is a production system, it will have at least two CPU cores and 4GB of RAM or better. Adding Application Launcher to this host will greatly increase CPU and RAM requirements. Although not required, it is recommended to install the database in its own instance (rather than a shared database instance) both for security and resource availability. Backup is achieved by backing up the virtual machine or by backing up the database and encryption key. Virtual Machine Backup is achieved using a solution appropriate to your Virtual Host. Database backup is performed by configuring a backup job using SQL Management Studio. This proposed solution provides minimum scalability and no high availability. This solution is suitable to test, and small environments due to memory, storage, and high availability constraints. The single server solution also poses the greatest security risk as the encryption key and the encrypted data are hosted on the same server. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 53

54 Deployment: Multi-System No HA A recommended minimum deployment will include two systems: one for database and a second for website and management console. If application launching is included, that is recommended to be on a separate system. See Application Launching section towards the end of this document. The database system will host the MS SQL database, preferably in its own instance, not shared with other applications. This machine may be a physical system or a virtual system and will not be shared with any other applications that utilize the system or database except for other Bomgar Lieberman solutions. The management console, website, and web service may be hosted by a single virtual system. This system should be allowed at least two CPU cores and 2GB of RAM. Hard drive space should provide for multiple Gigabytes of free space for log file growth as required by the management console and web application. This proposed solution provides scalability to meet most medium to medium-large environments that are generally well connected. Backup is achieved by backing up the virtual machine or by backing up the database. Virtual Machine Backup is achieved using a solution appropriate to your Virtual Host. Database backup is performed by configuring a backup job using SQL Management Studio. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 54

55 Deployment: Multi-System Minimum HA Recommended medium deployments will include no less than three systems: At least two servers for database HA, and one for the management console, website and web service. If application launching is included, that is recommended to be on a separate system. The solution database will utilize database availability groups, mirroring or database clustering to provide for higher availability. Availability groups, also known as always-on, was introduced with MS SQL It requires only two database servers but can leverage more. Availability groups also offer a readable secondary server which makes it very easy to work with reporting services tied to the nonmodifiable copy of the database. Availability groups also allows up to two synchronous replicas and two asynchronous replicas to be simultaneously active. Availability groups is the recommended HA architecture for the solution database. Database mirroring is a feature introduced prior to MS SQL It requires the use of at least two database servers. One DB is the primary DB and the other is a failover. Privileged Identity supports automatic and manual failover scenarios for database mirroring. At least two database systems are required for manual failover and three for automatic failover. In a manual failover, the database settings in the management console must be changed by hand. In an automatic failover the SQL Native Client and the Witness server perform the fail-over. Mirroring functionality was deprecated in SQL Server Clustering may be used for the database in this deployment but will require the use of shared hard drives and multiple network interfaces for each server. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 55

56 Deployment: Multi-System Full HA Large deployments will contain five or more servers: two or more database servers, one or two management console servers (licensing restrictions may apply), two or more password retrieval website servers. If application launching is included, that is recommended to be on a separate systems. Additional transcoder / media servers should also be placed on separate servers. See Application Launching section towards the end of this document. In the Full-HA server scenario, you will have at least two database servers, at least one management console server, and at least two web servers. There are multiple options for configuring the database the image above shows only one. The two database servers may be configured as an availability group without configuring the database as a failover cluster. If using an availability group, multiple replicas may be made available. The two database servers will be configured as a failover cluster. Additionally, you may wish to mirror the clustered database to a single system or to another cluster of systems which will add one or two more systems respectively. The Privileged Identity components will be pointed to the active node(s) in either scenario. The two web servers will be configured as a network load balanced cluster, using software NLB or a hardware device. This provides high availability to the data source and high availability to access the data (Stored passwords). This provides a constant access to stored passwords should up to two servers fail (or more if mirroring to another cluster). The variable is to deploy one or two management consoles. In order to deploy more than one management console in a highly available solution, deploy a secondary console on a separate machine (licensing restrictions may apply). Loss of the management console does not constitute anything more than loss of the following abilities in a GUI: Create/Delete managed systems lists - can be done via PowerShell or web service. Create new password change jobs - can be done via PowerShell or web service. Scheduled jobs that run from the default deferred processor will not run; zone processor operates independently on secondary systems and will continue to function. In other words, the website and web service communicate directly to the database independent of the management console and the converse is also true so disruption of one does not constitute disruption in the other. None of this is negates the need for a normal backup which should be done regularly. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 56

57 Deployment: Application Launching Minimum The following requirements are for launching applications on a separate bastion host where session recording video transcoding will occur on a separate system (e.g. the web application server). Bastion host - remote desktop services host. 2GB RAM, 2 CPU cores or more. Refer to Microsoft documentation for full remote desktop services sizing information. o o.net Framework v4.5.2 Additional requirements for launched applications Session Recorder / Media Server - 2GB RAM, 2CPU cores or more. Free disk space required will depend on amount of stored recordings. o o o.net Framework v4.5.2 IIS Microsoft Media Services (included in download) The bastion host can also function as the video transcoder and media server, though this will impact the performance of the host during video transcoding which will impact the user experience. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 57

58 Deployment: Application Launching Recommended If adding application launching and session recording the following hardware is also recommended: Bastion host - remote desktop services host. 6+GB RAM, 4-8 CPU cores or more (not including hyper-threading). Installation could be in a farm if additional redundancy is required. Refer to Microsoft documentation for full remote desktop services sizing information. o o o.net Framework v4.5.2 Additional requirements for launched applications Multiple remote desktop services host configured as an RDS farm Session Recorder / Media Server - 4+GB RAM, 4-8CPU cores or more (not including hyper-threading). Free disk space required will depend on amount of stored recordings. o o o o.net Framework v4.5.2 IIS Microsoft Media Services (included in download) Storage for recorded videos could be on a DFS share In the diagram below, use of Active Directory based DFS (distributed file system) is depicted as the storage medium for raw and converted session recording files. DFS is not a requirement, but merely a recommendation to add online redundancy for the storage of the recorded sessions. In this scenario, the bastion hosts will record the raw sessions. They will be copied to the DFS share. The media server transcode the files from the DFS share, then write the converted files back to the DFS share, and then delete the original raw files. If a DFS share is not used, the bastion hosts will move the raw files to the media server which will perform video transcoding services and provide local storage. In either case, the media server will provide access to the recorded sessions via IIS and Microsoft Media Services. CONTACT BOMGAR info@bomgar.com (US) +44 (0) (UK/EMEA) BOMGAR.COM 58