Establishing CA Directory replication for policy data and session artifacts in EEM 8.4

Products

CA Directory CA IT Asset Manager CA Software Asset Manager (CA SAM) ASSET PORTFOLIO MGMT- SERVER CA Service Management - Service Desk Manager CA Workload Automation AE - Business Agents (AutoSys) CA Workload Automation AE - Scheduler (AutoSys) Workload Automation Agent CA Process Automation Base

Issue/Introduction

This is considered a slight alternative to the EEM Getting Started Guide section covering application and data store failover. One key difference is the use of CA Directory native tools for establishing server trusts.

Environment

Release: ETRIA199000-8.3-Embedded Entitlements Manager
Component:

Resolution

This technical document assumes you have the following pre-requisites covered:

Working DNS environment or hosts files that can resolve names to IP Addresses from server to server. CA strongly recommends using a DNS forward and reverse lookup zone to minimize troubleshooting later. CA Support cannot account for every customer environment and scenario, so this doc cannot assume at any point it will work for every single customer environment. Server name resolution can play a pivotal role in determining proper functionality. Therefore adjustments to the configuration may be required.
Basic knowledge of CA Directory text based knowledge files and configuration files and their locations.
Installs of EEM and edits of files are to be done as an Administrator or Root on the system. For Unix/Linux you would SU - dsa to edit CA Directory files. This technical document will be using the Windows environment as the example but can be easily adapted to Unix/Linux flavors.
The practice below was performed using EEM Server build 8.4.410 (8.4 SP4 CR10)

Establish the trust relationship between EEM servers from the iGateway UI.

Login to the EEM spin page depicted in the following figure on <Hostname1>:
Click the Go button to launch the iTech Admin page, click the login hyperlink and login with your <eiamadmin> account and password used during Install. Select iauthority and click login:
Navigate to the Configure tab and add the Second EEM server to the Trusted iAuthority Hosts section on this page:
Next visit the iAuthority tab and add the rootcert.cer from the remote host machine to primary EEM server. It needs to be the literal path to this cert file. You may copy it to the primary server or map a drive to it. After you browse to the file enter in the other EEM server host name under Label and then click "Add Trusted Root".

Repeat steps i-iv on the secondary EEM server.

Modify Ipoz.conf on both servers:

· Open $IGW_LOC$\iPoz.conf and make the following changes on both servers:
- Add <BackboneMember><Hostname2></BackboneMember> on <Hostname1>
- Add <BackboneMember><Hostname1></BackboneMember> on <Hostname2>
  - This addition can be done anywhere in the file but is normally placed right above the Artifact Manager line below.
Change this line from "local" to "federated" on both servers:
- <ArtifactManager SessionTimeout="10" RequestTimeout="30"ArtifactStore="local/federated"></ArtifactManager>
  - NOTE: This is only necessary for the Autosys and Workload Control Center products. Leave this set to local if you are not using these products or are unsure of the outcome of this setting.

Prepare the CA Directory config for replication.

For this section, you will be working out of the %DXHOME%\config location. <Hostname1> edits:
- Copy the iTechPoz-<Hostname2>.dxc and iTechPoz-<Hostname2>-Router.dxc from <Hostname2> into the same location as the dxc knowledge on <Hostname1>. Edit iTechPoz-<Hostname2>.dxc to reflect the change from a single DSA to a multi-write server. The changes are in bold:
  
  #
  # iTechPoz - iTechnology rePOZitory
  #
  set dsa "iTechPoz-<Hostname2>" =
  {
  prefix = <cn iTechPoz>
  dsa-name = <cn iTechPoz><cn PozDsa><cn <Hostname2>>
  #address = tcp localhost port 509
  #for failover configuration
  address = tcp <Hostname2> port 509
  snmp-port = 509
  #for dxconsole debugging. info: make sure that the port is not used
  #console-port = 10510
  auth-levels = anonymous
  dsp-idle-time = 120
  #for failover configuration
  dsa-flags = multi-write
  link-flags = ssl-encryption-remote
  };
- For the iTechPozRouter.dxc copied from <Hostname2> you only need to change the address line to reflect the server name instead of localhost.
- Open the file iTechPoz-<Hostname1>.dxc and change the address line to reflect the hostname of this server and not use localhost.
- Save all of these files.
- Open iTechPoz.dxg and add the source information for the files you have just edited. Here is the example on <Hostname1>:
  - source "iTechPoz-<Hostname1>-Router.dxc";
    source "iTechPoz-<Hostname2>-Router.dxc";
    
    source "iTechPoz-<Hostname1>.dxc";
    source "iTechPoz-<Hostname2>.dxc";
- Go to this same file on <Hostname2> and make these edits:
  - source "iTechPoz-<Hostname2>-Router.dxc";
    source "iTechPoz-<Hostname1>-Router.dxc";
    
    source "iTechPoz-<Hostname2>.dxc";
    source "iTechPoz-<Hostname1>.dxc";
Visit the same %DXHOME% location on <Hostname2> and copy the iTechPoz-<Hostname1>.dxc and iTechPoz-<Hostname1>-Router.dxc knowledge files from <Hostname1> respective of those copied from <Hostname2>.
- Make the same edits to these knowledge files as you just did on <Hostname2>. Make sure to use the hostname of <Hostname1> where necessary and un-commenting the multi-write flag.
  
  NOTE: The only knowledge files that should be referring to the address "localhost" are the local itechPoz-localserver-Router.dxc on either system. So only one of the four files will use the address "localhost" The local machine's iTechPoz Router dxc.
Go back to <Hostname1> open a command prompt and run the following command:
- >dxcertgen -d <number_of_days> certs
- For example >dxcertgen -d 7300 certs
- This would generate certificates with a validity period of 20 years.
- This will generate a new set of certificates based on the new knowledge created for the replicated server. Open the file %DXHOME%\config\ssld\trusted.pem and copy out the last string certificate chain at the bottom. Here is a sample of what you need to copy:
```
-----BEGIN CERTIFICATE-----<EncryptedCertificateString>-----END CERTIFICATE-----
```
- Copy this string into the file iTechPoz-trusted.pem at the end. Make a backup copy of this file on <Hostname2> and copy this new file with the added string to the same ssld folder on <Hostname2>. Then copy the following four .pem files from the ssld/personalities over to <Hostname2> ssld/personalities.
  - itechpoz-<Hostname1>-router.pem
  - itechpoz-<Hostname1>.pem
  - itechpoz-<Hostname2>-router.pem
  - itechpoz-<Hostname2>.pem
- The two EEM servers now have the shared certificate and host knowledge of each other and are ready for replication and failover.

You can now test the config and test replication by performing the following:

At the command prompt on both servers run the command 'dxsyntax'. If there is no error then there will be no problem starting the Directory DSA's. Run the command "dxserver start all" on both servers. Then run "net start gateway" if this is not done already.
Login to the EEM UI on both <Hostname1> and <Hostname2> separately. From there click on the "Manage Access Policies" tab. Create a new delegation policy of the name "<Hostname1>" mark it with the disabled flag, and then save it. Visit the same Manage Access Policies tab on the server you did not create the new policy and check to see that it was replicated. Repeat this process on the server that was just replicated.
Additional testing includes logging into a registered application instance in EEM such as AutoSys, WCC, or Service Desk, and checking to see that Artifact replication is working. This requires that the product supports session failover so that the session remains intact when one EEM server is shut down.
If there is a failure in replication, you can troubleshoot this by editing the knowledge dxc files to use IP addresses instead of hostnames. CA support cannot account for every customer environment so please be prepared to make edits to the configuration and keep track of all changes.

As always, if you have additional questions or concerns about the topics covered in this technical document, please do not hesitate to open a case with CA Support Online.