BusinessObjects XI 3.x Post-Installation Step
Chapter 8: High Availability Provisioning Installation 97
Chapter 8: High Availability Provisioning Installation
Based on the guidelines in this chapter, you implement high availability for provisioning components by installing alternate Provisioning Servers and Provisioning Directories, and connector servers for C++ and Java connectors.
This section contains the following topics:
Installation Status (see page 97)
How to Install High Availability Provisioning Components (see page 98) Redundant Provisioning Directories (see page 98)
Redundant Provisioning Servers (see page 102) Redundant Connector Servers (see page 105) Failover for Provisioning Clients (see page 114)
Installation Status
The following table shows you where you are in the installation process:
You Are Here Step in Installation Process
1. Install prerequisite hardware and software and configure your system as required.
2. Perform one of these installations:
■ Single node installation
■ Installation on an application server cluster 3. (Optional) Create separate databases.
4. (Optional) Install the Report Server.
X 5. (Optional) Install alternate Provisioning Directories, alternate Provisioning Servers, and connector servers to support failover and load balancing.
How to Install High Availability Provisioning Components
98 Installation Guide (WebLogic)
How to Install High Availability Provisioning Components
The following table describes the steps involved in installing provisioning components for high availability:
Step
1. Install primary and alternate Provisioning Servers and provisioning directories for load balancing and failover.
2. Install several connector servers for load balancing and failover.
3. Enable clients of the provisioning server to fail over.
Redundant Provisioning Directories
To support failover, you can install primary and alternate Provisioning Directories. For example, you may have two systems, one with the Provisioning Server on it and a second system with the primary Provisioning Directory. A third system has the alternate Provisioning Directory. If the primary Provisioning Directory fails, the alternate
Provisioning Directory is assigned automatically.
You install alternate Provisioning Directories if they were not configured during the installation.
Redundant Provisioning Directories
Chapter 8: High Availability Provisioning Installation 99 Follow these steps:
1. Install the primary Provisioning Directory using the Provisioning Directory installer from where you unpacked the install package.
■ Windows:
Unpacked-Install-Package\Provisioning\Provisioning Directory\setup.exe
■ UNIX:
Unpacked-Install-Package/Provisioning/ProvisioningDirectory/setup
If you have already installed a primary Provisioning Directory during the installation, you can omit step 1.
2. Perform the prerequisite configuration for the new Provisioning Directories.
3. Install one or more alternate Provisioning Directories.
Perform Prerequisite Configuration for New Provisioning Directories
You use the High Availability Configuration command before you use the Provisioning Directory installation program.
Follow these steps:
1. Log into the system where the primary Provisioning Directory is installed.
2. On a command line prompt, navigate to the highavailability sub-directory where you unpacked the install package. For example:
Installed-Provisioning-Directory-location\Provisioning\Provisioning Directory\highavailability
3. Enter this command:
highavailability.bat
The command displays a summary of the current configuration: the domain name, the hostname of each Provisioning Server and Provisioning Directory, and which one is the Primary Provisioning Directory.
4. Respond to the prompts to provide the hostnames required for each alternate Provisioning Directory that you want to add.
If you plan to install alternate Provisioning Servers, you can add their hostnames now by responding to the prompts.
5. Log in to all other Provisioning Directory and Provisioning Servers and repeat steps 2 through 4.
Redundant Provisioning Directories
100 Installation Guide (WebLogic)
Install Alternate Provisioning Directories
Once you have performed the prerequisite configuration required, you can install alternate Provisioning Directories.
Follow these steps:
1. Log in as a Local Administrator (for Windows) or root (for Solaris) into the system where you plan to install the alternate Provisioning Directory.
2. Be sure that CA Directory is installed on this system.
3. Copy custom schema files to the %DXHOME%/config/schema directory if any of the following is true for the primary Provisioning Directory:
■ COSX (etrust_cosx.dxc) has been modified
■ LDA connector (etrust_lda.dxc) is installed
■ A custom C++ connector schema has been created
The Provisioning Directory installation checks the %DXHOME%/config/schema directory for extra schema files named etrust_*.dxc, and adds them to the group schema file, impd.dxg. If the custom schema files are not copied locally, data replication between the Provisioning Directories fails.
4. Run the Provisioning Directory installer from where you unpacked the install package.
■ Windows:
Unpacked-Install-Package\Provisioning\Provisioning Directory\setup.exe
■ UNIX:
Unpacked-Install-Package/Provisioning/ProvisioningDirectory/setup
5. Select High Availability, and respond to the questions about the hostnames for systems where other Provisioning Directories are installed and which system is the primary Provisioning Directory.
Redundant Provisioning Directories
Chapter 8: High Availability Provisioning Installation 101 6. Respond to other questions using the same answers given during the primary
Provisioning Directory installation for:
■ Deployment Size
■ Shared Secret
■ FIPS key
7. Respond to this question based on how and when you want to replicate data from the Primary Provisioning Directory:
Do you want to start replication to the Provisioning Directory.
If you are upgrading from a previous release, you may have a significant amount of data to replicate. You should deselect the checkbox if you do not want replication to start at this time. After the installation, you would then need to copy an LDIF data dump or online backup files from an existing Provisioning Directory and load the data or start the DSAs manually, which will start automatic replication.
Important! If alternate Provisioning Directory installation failed, data replication may have occurred before the failure. If so, the master and alternate Provisioning Directories have a record that replication occurred. If you now reinstall the alternate Provisioning Directory, that data is not replicated again. Instead, use the High Availability
Configuration command on the primary and alternate Provisioning Directories to remove and add back the alternate Provisioning Directory before you reinstall it.
Redundant Provisioning Servers
102 Installation Guide (WebLogic)
Redundant Provisioning Servers
Multiple Provisioning Servers share the workload of a provisioning domain, providing performance, scalability, and high availability. The first Provisioning Server installed is called the primary Provisioning Server. Additional servers are called alternate
Provisioning Servers.
As shown in this illustration, you can configure multiple alternate Provisioning Servers for one primary Provisioning Server.
In this illustration, three Provisioning Servers are configured to serve the provisioning domain. All servers are configured to use the Provisioning Directory of the primary Provisioning Server installation.
Router DSA for the Provisioning Server
The Provisioning Server communicates through a CA Directory router DSA, and not directly to the Provisioning Directory. The router DSA, imps-router, is installed with the Provisioning Server installer. This DSA accepts requests from the Provisioning Server and routes them to the appropriate Provisioning Directory DSA (impd-co, impd-main, impd-inc, or impd-notify) depending on the prefix.
In a high-availability installation, the imps-router DSA has connection information for Provisioning Directory DSA on at least one alternate Provisioning Directory system. If a primary Provisioning Directory DSA becomes unavailable, the router DSA attempts to use an alternate DSA.
The imps-router DSA has been assigned ports 20391, 20391, 20393 (for address, SNMP, and console respectively).
Redundant Provisioning Servers
Chapter 8: High Availability Provisioning Installation 103 Note: In previous releases of this software, the etrustadmin DSA used port 20391. Any connections to 20391 on the Provisioning Directory system fail unless the Provisioning Directory and Provisioning Server are on the same system. Therefore, reroute these connections to port 20391 on the Provisioning Server system.
For CA Directory DSAs running on one system to communicate with DSAs on another system, they must have connection information for each other. So during Provisioning Directory installation, you identify each Provisioning Server that can connect to it.
Install Provisioning Servers
To support failover, you can install primary and alternate Provisioning Servers. If you have already installed a Provisioning Server, you can omit step 1.
Follow these steps:
1. Install the primary Provisioning Server using the Provisioning Server installer from where you unpacked the install package.
■ Windows:
Unpacked-Install-Package\Provisioning\Provisioning Server\setup.exe
■ UNIX or Linux:
Unpacked-Install-Package/Provisioning/ProvisioningServer/setup
2. Perform prerequisite configuration for the new Provisioning Servers.
3. Install one or more alternate Provisioning Servers.
4. Enter the alternate Provisioning Server host and port number when you enable provisioning in the CA IdentityMinder Management Console. For details, see the Configuration Guide.
Perform Prerequisite Configuration for New Provisioning Servers
To configure knowledge files, you use the High Availability Configuration command on each system with a Provisioning Directory.
Follow these steps:
1. Log into the system where the primary Provisioning Directory is installed.
2. On a command line prompt, navigate to the highavailability sub-directory where you unpacked the install package. It is a sub-directory of where you install the Provisioning Directory or Provisioning Server. For example:
cd C:\\Program Files\Provisioning Directory\highavailability
Redundant Provisioning Servers
104 Installation Guide (WebLogic)
3. Enter this command:
highavailability.bat
The command displays a summary of the current configuration: the domain name, and the hostname of each Provisioning Server and Provisioning Directory.
4. Respond to the prompts to provide the hostnames required for each Provisioning Server that you want to add.
If you plan to also install alternate Provisioning Directories, you can add their hostnames now by responding to the command prompts.
5. Log in to each system that will host a Provisioning Directory and repeat Steps 2 through 4.
Install Alternate Provisioning Servers
Once you have performed the prerequisite configuration involving the highavailability command, you can install one or more Provisioning Servers.
Follow these steps:
1. Log in as a Local Administrator (for Windows) or root (for Solaris) on each system that will host an alternate Provisioning Server.
2. Make sure that CA Directory is installed on this system.
3. Copy custom schema files to the %DXHOME%/config/schema directory if any of the following is true for the primary Provisioning Directory:
■ COSX (etrust_cosx.dxc) has been modified
■ LDA connector (etrust_lda.dxc) is installed
■ A custom C++ connector schema has been created
The Provisioning Directory installation checks the %DXHOME%/config/schema directory for extra schema files named etrust_*.dxc, and adds them to the group schema file, impd.dxg. If the custom schema files are not copied locally, the Provisioning Server will not route any custom schema.
4. Run the Provisioning Server installer from where you unpacked the install package.
■ Windows:
Unpacked-Install-Package\Provisioning\Provisioning Server\setup.exe
■ UNIX:
Unpacked-Install-Package/Provisioning/ProvisioningServer/setup
5. Complete the instructions in the installer dialog boxes.
You can select a check box during installation to configure Provisioning Directory high availability. If you choose this option, you must supply the hostnames of any alternate Provisioning Directories and specify the primary Provisioning Directory.
Redundant Connector Servers
Chapter 8: High Availability Provisioning Installation 105
Configure Provisioning Server Failover
For CA IdentityMinder to distinguish the primary from the alternate Provisioning Server, you create server definitions in JIAM in the Management Console. You create these definitions in the directory object associated with the CA IdentityMinder directory for your environment. During initialization, CA IdentityMinder reads any failover server definitions defined in that object, adding them to the JIAM failover server definitions.
Note: For details on setting up server definitions, see the Configuration Guide.
Redundant Connector Servers
With the Connector Server Framework (CSF), you can run multiple Connector Servers and configure the Provisioning Servers to communicate with Connector Servers in specific contexts.
As a result, the Provisioning Server can:
■ Support Connector Servers on different platforms to manage endpoint types that are unavailable on the platform where the Provisioning Server is installed.
■ Communicate with multiple Connector Servers, which each manage a different set of endpoint types or endpoints. Therefore, endpoint types or endpoints can be managed on a parallel basis to achieve load balancing.
Installing Multiple Connector Servers
When you configure multiple instances of a connector server as network peers, they automatically synchronize the password used by their administrative account. For this reason, we recommend that you set the same account details during installation.
If you install multiple instances of a connector server on the same computer, ensure that each instance uses unique port numbers. If any port numbers are used by more than one instance of a connector server, the servers will behave unpredictably.
Connector Server Framework
The use of several Connector Servers is called the Connector Server Framework. The Connector Server Framework has two important characteristics:
■ Scalability - multiple connector servers may share the load of working on a set of endpoints.
For example, a lengthy exploration of an endpoint on one connector server does not influence the ability to operate on an endpoint that is being controlled by another Connector Server
Redundant Connector Servers
106 Installation Guide (WebLogic)
■ Communication channel security - communication between Provisioning Server and connector server is encrypted using TLS.
If an endpoint type uses a proprietary protocol to communicate between the connector server and endpoints of that protocol, the extent of use of the proprietary protocol may be limited to a local network, or even to just local communication inside one server.
When deciding on an implementation strategy, consider these factors so that you protect the Connector Servers in your organization against unauthorized access:
■ The Connector Server may be configured to disclose passwords in clear text.
Any person with access to the system running the Connector Server and with sufficient privileges to modify the configuration of the Connector Server and to restart the Connector Server can make the Connector Server log passwords appear in clear text.
The Connector Server is based on the open source slapd process. The instructions to make a slapd process log incoming passwords in clear text are in the public domain, for example, by looking at the manual pages at http://www.openldap.org
■ The Connector Server is only protected by a bind password.
The Connector Server trusts any client who connects to it and is able to provide the proper credentials, such as Bind DN and Bind Password. The Connector Server does not know if the connection comes from a Provisioning Server or not. Any user with internal access may disclose the bind password, then connect to the Connector Server from another server, and so have administrator privileges over the endpoints controlled by the Connector Server.
■ The Connector Server is not protected against brute force attacks on the bind password
Unlike the Provisioning Server, the Connector Server is not protected against repeated attempts at binding with different passwords. An attacker may therefore try to guess the password by brute force attack. Should an attacker succeed in guessing the bind password, then the road is open for the attacker to control the endpoints under control of the Connector Server.
For these reasons you are advised to design your implementation such that
■ The same organizational unit is responsible for administrative access to all Provisioning Servers and connector servers.
■ Your connector servers are suitably protected by firewalls or similar such that the ports may not be reached by unauthorized means.
■ The ability to connect to Provisioning Servers and connector servers on non-TLS ports should be disabled in your production environments.
If you install multiple connector servers on one computer, make sure that each instance uses a unique set of port numbers.
Redundant Connector Servers
Chapter 8: High Availability Provisioning Installation 107
Load-Balancing and Failover
Failover and load-balancing of connector requests is achieved by each provisioning server based on the CSF configuration defined using csfconfig or Connector Xpress.
Each provisioning server consults the CSF configuration that applies to it and determines which Connector Servers it should use to access each endpoint or endpoint type.
Failover and load-balancing occur when there are multiple connectors servers configured to serve the same endpoint or endpoint type.
Failover and load-balancing are unified and cannot be controlled separately. One cannot indicate that a particular connector server is to remain idle except when needed for failover. Instead, a provisioning server that is configured to use two or more
connector servers interchangeably will distribute work between these connector servers (load balancing) during normal operation. Should one or more of the Connector Server become unavailable, the remaining connector servers will provide failover support for the unavailable connector servers.
Reliability and Scalability
With the Connector Server Framework (CSF), the Connector Server high availability features increase reliability and scalability.
Reliability is enhanced by having multiple Connector Servers serve a Provisioning Server, so it can continue to function if one or more Connector Servers become unavailable.
For example, if one Connector Server manages the UNIX endpoint type and another manages the Active Directory endpoint type; and the Active Directory Connector Server becomes unavailable, the Provisioning Server can still manage the UNIX endpoint types.
Scalability is achieved by having a mechanism to add more Connector Servers to manage an increasing amount of endpoint types or endpoints. For example, if the number of endpoint types increases to 100, the Provisioning Server can be configured to have 20 Connector Servers, with each Connector Server managing five endpoint types. Or configure 20 Connector Servers with each Connector Server managing overlapping sets of 10 endpoint types to allow for failover and load balancing behaviors as well.
Redundant Connector Servers
108 Installation Guide (WebLogic)
Multi-Platform Installations
The Connector Server Framework is the configuration of Connector Servers that exist on multiple systems, which could be Windows or Solaris systems.
The following use cases are supported:
■ Use Case 1
– Provisioning Server and connector server installed on a Solaris system.
– A second Connector Server installed on a Windows system, serving the non-multi-platform connectors.
■ Use Case 2
– Provisioning Server and connector server installed on a Windows system.
– A second Connector Server installed on Solaris system, serving the multi-platform connectors.
– A third Connector Server installed on a remote Windows system, serving the other connectors.
■ Use Case 3
– Provisioning Server installed on a Windows or Solaris system and a Connector Server installed on the same system.
– Multiple additional Connector Servers installed on Windows or Solaris systems, serving as endpoint agents. This scenario is important for cases where the connector is using a proprietary or un-secured communication channel. Using this topology, the important segment of network traffic is secured by the standard Provisioning Server to Connector Server communication protocol and not by the proprietary protocol.
Configure Connector Servers
You configure the Connector Server Framework by using the csfconfig command or by using Connector Xpress. The csfconfig command uses the data in the Windows Registry (or UNIX counterpart created for Provisioning Server) to connect to a Provisioning Server. The csfconfig command must run on the system where one of the Provisioning Server runs.
Using the command, you can:
■ Add or modify a Connector Server connection object with information such as the connector server, host, and port.
■ Define for which endpoints or endpoint types the connector server is used; possibly varying this definition for alternate provisioning servers.
■ Delete the Connector Server connection information object.
Redundant Connector Servers
Chapter 8: High Availability Provisioning Installation 109
■ List all connector server connection objects in a domain.
■ Show one or all connector server connection objects for one or all connector servers
The csfconfig command uses the authorizations provided by a global user credential, so that global user must have the necessary administrative privileges to manipulate the appropriate ConfigParam and ConfigParamContainer objects.
csfconfig Command
To use the csfconfig command, the command line syntax is:
To use the csfconfig command, the command line syntax is: