RSA Authentication Manager 6.1 continues to support legacy Agent Hosts (those running versions of RSA ACE/Agent software prior to 5.0). This section discusses issues relating to legacy Agent Hosts.
Authentication Manager Designations Required By Legacy Agent Software
RSA Authentication Manager 6.1 is based on architecture introduced in version 5.0.
Two changes in RSA ACE/Server 5.0 architecture improved authentication rates over previous major versions: the use of multiple authenticating Replicas and the ability of the new RSA Authentication Agent software to select the Replica that will respond most quickly to an authentication request. Agent software based on 5.0 architecture is aware of all the Replicas in your realm and can send authentication requests to any one of them.
Lacking the load balancing capability, legacy Agent Hosts can request authentication of users only from a Master or a Slave, because the Agent Host’s configuration file (sdconf.rec) can identify only these two Authentication Managers.
RSA Authentication Manager 6.1 Administrator’s Guide
76 3: Agents and Activation on Agent Hosts
If your installation includes legacy Agent Hosts, the RSA Authentication Manager 6.1 installation software saves the identities of the original Master and Slaves when it modifies the Authentication Manager configuration file, sdconf.rec. This information, which is in the configuration file of each legacy Agent Host, has the effect of
assigning the original Master and Slaves (now configured as Replicas in the 6.1 environment), as the Acting Master and Slaves for legacy Agent Hosts in the new environment.
Note: If, after installation, you add a legacy Agent Host—that is, an Agent Host running RSA ACE/Agent software earlier than 5.0—you must enter the name of the Acting Master and Acting Slaves in the Agent Host configuration record manually.
This is true even if the record was created through the auto-registration process. For information about modifying the Agent Host record, see “Legacy Agent Hosts” on page 75.
Merging Realms That Include Legacy Agent Hosts
After installing RSA Authentication Manager 6.1, you can merge your database with that of another realm that also includes legacy Agent Hosts. If you do this, you must ensure that these “imported” legacy Agent Hosts will continue sending authentication requests to their own original Master and Slaves.
Before you begin the merge procedure, edit sdconf.rec on the Primary so that it specifies the Master and Slaves of the realm you are importing rather than the former Master and Slaves of your own realm.
This change does not affect the behavior of the legacy Agent Hosts already in your realm, which continue to direct authentication requests to the Acting Master and Slaves specified in their own configuration files. In the database merge procedure, however, the new Acting Master and Slaves are copied from sdconf.rec on the Primary to the Agent Host record of each new legacy Agent Host. If the specifications in that file have not been changed, authentication requests from all legacy Agent Hosts, including those just added to the realm, will be addressed to the same pair of Authentication Managers.
To Begin: See the database merge procedure described in the Installation Guide for your platform.
3: Agents and Activation on Agent Hosts 77 The following diagram illustrates the scenario described in this section.
In the shaded area on the left are Agent Hosts that were part of the sample realm when it was upgraded to RSA Authentication Manager 6.1. Because Authentication
Managers “Eakins” and “Cassatt” were the Master and Slaves prior to the upgrade, they are identified in each legacy Agent Host record as Acting Master and Slaves for this set of legacy Agent Hosts. The configuration file of each Agent Host, which is not changed in the RSA Authentication Manager upgrade process, specifies Eakins and Cassatt as the Master and Slave respectively, and the Agent Host must therefore address all authentication requests to these two Authentication Managers only.
In the center area are Agent Hosts that have been upgraded to RSA ACE/Agent 5.0 or later. These Agent Hosts can send authentication requests to any Replica in the realm.
The shaded area on the right identifies a set of legacy Agent Hosts that were added to the realm by merging its database with that of another realm. The former Master and Slaves in that realm, “Copley” and “Pollock,” are now the Acting Master and Slaves to which the newly added Agent Hosts must direct all their authentication requests. If the Agent Host records did not identify Copley and Pollock in these roles, the legacy Agent Hosts would be unable to function, since these are the Master and Slaves specified in their configuration files.
Note: The illustrated system requires an RSA Authentication Manager Advanced license. The RSA Authentication Manager Base license allows a Primary and one Replica only.
Eakins
Hopper
Cassatt O'Keefe Homer Whistler Copley Pollock
Original Legacy Agent Hosts
Legacy Agent Hosts Added through Database
Merger Upgraded Agent
Hosts Primary
Server
Replica Servers
Agent Hosts
Servers and Agent Host Connections in an Upgraded RSA ACE/Server 5.2 Realm
RSA Authentication Manager 6.1 Administrator’s Guide
78 3: Agents and Activation on Agent Hosts
Auto-Registration Support for Legacy Agent Hosts
Auto-registration is not fully supported on legacy Agent Hosts. The legacy Agent Host sdconf.rec file must contain a Master and Slave that matches the Acting Master and Slave assigned in the Agent Host record in the database. If the Agent Host sdconf.rec file and the database do not match, users cannot authenticate through the legacy Agent Host.
This is a problem for auto-registration, because it uses the Authentication Manager sdconf.rec file, which may or may not agree with the Master and Slave information in the Agent Host sdconf.rec file and the Acting Master and Slave information in the database. If a legacy Agent Host updates its own sdconf.rec file through
auto-registration, it may be retrieving an sdconf.rec file that contains Acting Master and Slaves that are different than those assigned in the database. When the legacy Agent Host attempts to authenticate to the Acting Master and Slave in its updated sdconf.rec file, the authentication fails.
For this reason, if you have any legacy Agent Hosts using auto-registration, they must all use the same Acting Master and Slave. Additionally, the Authentication Manager sdconf.rec file must contain the same Acting Master and Slave as the Agent Host sdconf.rec file.
If at some time after installation you add another Agent Host running the same pre-5.0 version of the Agent software, you must enter the name and IP address of the Acting Master (and, optionally, the Acting Slave as well) in the Agent Host record before the Agent Host can handle authentications successfully. This is true whether the Agent Host record in the Authentication Manager database is created automatically through auto-registration or manually by an administrator. Until you edit the Agent Host record and supply the identity of the Acting Master, the Agent has no destination to direct authentication requests to.
To Begin: Click Agent Hosts > Edit Agent Host. Select the Agent Host whose record you want to edit and click OK to open the Edit Agent Host dialog box. Click Assign Acting Servers and, if you need instructions, click Help.