The sdconf.rec file

The sdconf.rec file is an encrypted configuration record file that specifies how the agent is to communicate with the RSA Authentication Manager realm. The file specifies four servers by IP address: 

• First, a replica server that can act as a primary server;
• Second, a replica server that can act as a replica server;
• Third, the server on which the sdconf.rec file was prepared; and
• Fourth, the primary server in the realm.

For modern agents, all of the servers can be used, but the first two IP addresses can also be specified as alternate IP addresses (aliases) which allow authentication requests to be sent to those servers through firewalls.

When an RSA administrator creates an sdconf.rec file, the actual IP addresses of all servers known to be in the realm (up to 11 in all), as well as up to three alias IP addresses for each server, are collected from the server database and compiled into a list known as the server list. One purpose of the list is to ensure that the agent can make its initial server connections. As the sdconf.rec file is generated, the server list is included with the other information in the file. After the file is created, an administrator must copy the sdconf.rec file to the agent for use by the agent. This is done from the Security Console (Access > Authentication Agents > Generate Configuration File).

NOTE: You do not have to replace an agent's sdconf.rec file. As long as the primary and replica servers specified in each RSA agent's sdconf.rec file are still reachable, they will continue to function normally.
 

The sdstatus.1 (Linux) and sdstatus.12 (Windows) file

The sdstatus.1 file is used with Unix agents. Windows uses a file called sdtatus.12.

The sdstatus file is an encrypted internal record for the agent that specifies its last known status, including its settings for communicating with servers in the realm. It also contains a timestamp value for both the sdconf.rec and the sdopts.rec. When the agent starts, it immediately reads the sdstatus file to determine what has changed since the agent was last started. If neither the sdconf.rec nor the sdopts.rec has changed since the last startup, the agent will process authentication requests according to the information it reads in the sdstatus file.

If the agent determines that its sdstatus timestamp for the sdconf.rec no longer matches the timestamp of the sdconf.rec file, the agent reads the latest information into the sdstatus file from the new or changed sdconf.rec file and discards any previous sdstatus information. Any existing sdopts.rec priority setting information is also discarded because the sdconf.rec file has changed. If the agent determines that its sdstatus timestamp for sdopts.rec no longer matches the timestamp of the sdopts.rec file, the agent discards its previous sdstatus information and reads the latest information from the new or changed sdopts.rec file into sdstatus. After processing the sdstatus information, the agent waits for its first authentication request.
 

The sdstatus file can be renamed at any time so that the next time the agent tries to authenticate it will be recreated.

How the sdconf.rec and sdstatus.12 files are used by RSA Authentication Agents

The RSA agent sends its first authentication request randomly to any of the servers listed in its sdconf.rec file. When the server validates the request, the agent will request the latest server list from that server. After the server sends its latest list to the agent, the agent stores the list information in its sdstatus file.
 

The sdopts.rec file

Automatic Load Balancing

Configure RSA Authentication Agent to automatically balance authentication request loads by creating an sdopts.rec) file. The sdopts.rec file is a text file stored on the machine on which an agent is installed. Within the file, you can specify dynamic or manual load balancing. Important: You must log on with an administrator account if you plan to modify the sdopts.rec file.

Dynamic Load Balancing

With dynamic load balancing, Authentication Agent sends a time request to each RSA Authentication Manager server in the realm and determines a priority list based on the response time of each Authentication Manager server. The Authentication Manager server with the fastest response time gets the highest priority and receives the greatest number of authentication requests. Other Authentication Manager servers get lower priorities and fewer requests. This arrangement lasts until Authentication Agent sends another time request or times out.

To perform dynamic load balancing, the Authentication Agent connects to the Authentication Manager server through firewalls by using alternate IP addresses (aliases) for the Authentication Manager servers. The Authentication Manager servers provide the aliases to the  Authentication Agent upon request. The addresses are stored in the sdconf.rec on the Authentication Agent host. You specify dynamic load balancing by excluding the USESERVER statement from the sdopts.rec file. 

Manual Load Balancing

With manual load balancing, you specify the RSA Authentication Manager server that each Agent host uses. You also assign a priority to each Authentication Manager server so Authentication Agent can direct authentication requests to some Authentication Manager servers more frequently than others. You specify manual load balancing by including the USESERVER statement in the sdopts.rec file and associating priority settings with each Authentication Manager server you specify for use. For more information, see below.

Manage an sdopts.rec File

This section describes the components that you can use to create an sdopts.rec file. It also gives examples of ways you can use the components to set up load balancing.

Create an sdopts.rec File

You can create and edit an sdopts.rec file using any text editor. After you create the file, save it in the directory specified by the following registry setting: AuthDataDir value under the HKLM\Software\RSA\RSA Authentication Agent key. To protect the file from unauthorized changes, change the permission settings so that only administrators can modify the file.

Important: Each time you modify the sdopts.rec file, restart Authentication Agent to register the changes. The file can include:

• Comment lines, each preceded by a semicolon.
• Keyword-value pairs, which can be any of the following:
  • CLIENT_IP=<IP address>. Specifies an overriding IP address for the Authentication Agent host. The CLIENT_IP keyword can appear only once in the file. For information, see “Specify an Overriding IP Address” on page 85. (Authentication Agent ignores this setting if the IP override is already set through the Advanced Tools option in the RSA Control Center.
    For more information, see the RSA Authentication Agent (RSA SecurID) Help.)
  • USESERVER=<IP address>, priority. Specifies an RSA Authentication Manager server to receive authentication requests from
    the Authentication Agent host according to a specified priority value. Use one setting for each RSA Authentication Manager server that the Authentication Agent host uses. The combined maximum number of Authentication Manager servers you can specify in the sdopts.rec and sdconf.rec files is 11.

Note: Including this value in the sdopts.rec file enables manual load balancing.

Each USESERVER keyword value must consist of the actual RSA Authentication Manager IP address separated by a comma from the assigned priority. The priority specifies if or how often an RSA Authentication Manager server receives authentication requests. The following table lists the priority values that you can specify.

Key words must be written in uppercase. If none of the servers with USESERVER statements are responsive, then the default server is the primary or the Authentication Manager server used to create the sdconf.rec file is the primary.

The value for the ALIAS keyword must consist of the actual IP address for the RSA Authentication Manager server, followed by up to three aliases for that Authentication Manager server. The Authentication Agent sends timed requests to the actual IP address and to the alias(es).

Only the actual IP address specified by the ALIAS keyword must be known by the specified RSA Authentication Manager server. In addition, the actual IP address must be included on any Authentication Manager server list received by Authentication Agent. The Authentication Manager server list provides actual and alias IP address information about all known Authentication Manager servers in the realm. Authentication Agent receives the list from the Authentication Manager server after Authentication Manager validates an authentication request.

• ALIASES_ONLY=<IP address>. When you provide an actual IP address of an RSA Authentication Manager server as the value, this keyword tells the Authentication Agent to use only the alias IP addresses to contact Authentication Manager. When you do not provide a value, this keyword tells Authentication Agent to send requests only to the RSA Authentication Manager servers that have alias IP addresses assigned to them. You can create exceptions by including no more than 10 IGNORE_ALIASES keywords in the sdopts.rec file to specify which Authentication Manager servers must be contacted through their actual IP addresses. For an example showing these exceptions, see “Specify Alias IP Addresses for Use or Exclusion” on page 84. (If you use this keyword, make sure that at least one RSA Authentication Manager has an alias IP address specified for it in the sdconf.rec file or in the sdopts.rec file.) 
• IGNORE_ALIASES=<IP address>. When you do not provide a value, this keyword specifies that all alias IP addresses found in the sdopts.rec and sdconf.rec files, or on the RSA Authentication Manager list, are ignored. You can create exceptions by including no more than 10 ALIASES_ONLY keywords in the sdopts.rec file to specify which Authentication Manager servers must be contacted through their alias IP addresses. For an example showing these exceptions, see “Specify Alias IP Addresses for Use or Exclusion” on page 84. When you provide an actual IP address as the value, this keyword tells Authentication Agent to use only the actual IP address to contact Authentication Manager.
• AVOID=<IP address>. When you provide an actual IP address of an RSA Authentication Manager server as a value, this keyword tells Authentication Agent to exclude this Authentication Manager server from use during dynamic load balancing. Use the AVOID keyword only for dynamic load balancing. Do not use it with the USESERVER keyword for manual load balancing.

Exclude an Authentication Manager Server 

During Dynamic Load Balancing In dynamic load balancing, you exclude an RSA Authentication Manager server from use for authentication by including the AVOID keyword in the sdopts.rec file. When you provide an actual IP address of an RSA Authentication Manager server as a value, this keyword tells Authentication Agent to exclude this Authentication Manager server from use during dynamic load balancing.

Important: Use the AVOID keyword only for dynamic load balancing. Do not use it with the USESERVER keyword for manual load balancing. If the AVOID keyword is included in an sdopts.rec file that includes a USESERVER statement, the AVOID statement is considered an error.

If you use the AVOID statement with the IP address of the default RSA Authentication Manager server, the statement is ignored unless another Authentication Manager server is available. The default Authentication Manager server is the one where the sdconf.rec file was created. If an Authentication Manager server is designated as the master, however, it becomes the default Authentication Manager server regardless of where the sdconf.rec file was created.

The following example shows how to use the AVOID keywords in the sdopts.rec file:

AVOID=192.100.123.5

In this example, the RSA Authentication Manager server with the IP address 192.100.123.5 will not be used for authentication.

Configure Manual Load Balancing

You configure manual load balancing by including the USESERVER keyword in the sdopts.rec file to specify the IP addresses of the RSA Authentication Manager servers that you want each Agent host to use.

You can list the IP addresses in the sdopts.rec file in any order, but you must list each separately, one per line. The following example shows how to use the USESERVER keywords to specify the IP addresses.

;Any line of text preceded by a semicolon is considered a comment and is ignored.
;Do not put a blank space between a keyword and its equal sign. Blank spaces are permitted after the
;equal sign, after the IP address, and after the comma that separates an IP address from a priority value.
USESERVER=192.168.10.23, 10
USESERVER=192.168.10.22, 2
USESERVER=192.168.10.20, 1
USESERVER=192.168.10.21, 0

You can use the USESERVER and ALIAS keywords together in the sdopts.rec file. However, USESERVER keywords do not affect the alias addresses used to connect to the Authentication Manager servers, and ALIAS keywords have no effect on which Authentication Manager servers are specified for use.

Specify Alias IP Addresses for Use or Exclusion

You can use the sdopts.rec file to specify alias IP addresses for use or for exclusion. The Authentication Agent ignores this setting if the IP override is already set through the Advanced Settings option in the RSA Control Center. For more information on setting the IP address through the Control Center, see the RSA Authentication Agent (RSA SecurID) Help. 

You can list the settings in the sdopts.rec file in any order, but you must list each setting separately, one setting per line. The following example shows how to use the ALIAS keywords in the sdopts.rec file.

;Do not put a blank space between a keyword and its equal sign. Blank spaces are permitted after the
;equal sign, after the IP address, and after the comma that separates an IP address from a priority value.
USESERVER=192.168.10.23, 10
USESERVER=192.168.10.22, 2
USESERVER=192.168.10.20, 1
USESERVER=192.168.10.21, 0
ALIAS=192.168.10.23, 192.168.4.1, 192.168.4.2, 192.168.4.3
ALIAS=192.168.10.22, 192.168.5.2, 192.168.5.3
ALIAS=192.168.10.20, 192.168.5.1
ALIAS=192.168.10.21, 0, 192.168.1.1
ALIAS_ONLY=192.168.10.23
IGNORE_ALIASES=192.168.10.22

In this example, the default is to use alias or actual IP addresses, with some exceptions. The RSA Authentication Manager server with the actual IP address 192.168.10.23 has three alias addresses specified for it, while Authentication Manager servers 192.168.10.20 and 192.168.10.21 each have only one alias. RSA Authentication Manager server 192.168.10.22 has two alias addresses. The aliases specified by the ALIAS keywords are additions to any aliases specified in the sdconf.rec file and in the RSA Authentication Manager server. 

This example shows how to use the USESERVER and ALIAS keywords together in the sdopts.rec file. However, USESERVER keywords do not affect the alias addresses used to connect to the Authentication Manager servers, and ALIAS keywords. In this example, the Authentication Manager server identified by IP address 192.168.10.23 receives more authentication requests than Authentication Manager server 192.168.10.22. Authentication Manager server 192.168.10.20 is used only if the Authentication Manager servers of higher priority are unavailable. Authentication Manager server 192.168.10.21 is ignored except in rare circumstances  described above.

In this example, the default is to use aliases with two exceptions. RSA Authentication Manager server 192.168.10.23, as specified by the ALIASES_ONLY keyword, will be contacted only through its alias IP addresses. RSA Authentication Manager server 192.168.10.22, specified by the IGNORE_ALIASES keyword, will be contacted only by using its actual IP address.

In the following example, the default is to ignore aliases, with two exceptions:

IGNORE_ALIASES
ALIASES_ONLY=192.168.10.23
ALIASES_ONLY=192.168.10.22

The ALIASES_ONLY exceptions specify that Authentication Agent should send its requests to RSA Authentication Manager server 192.168.10.23 and 192.168.10.22 by using only their alias IP addresses.

In the following example, the default is to use aliases, with two exceptions:

ALIASES_ONLY
IGNORE_ALIASES=192.168.10.23
IGNORE_ALIASES=192.168.10.22

The IGNORE_ALIASES exceptions specify that Authentication Agent should send its requests to RSA Authentication

Specify an Overriding IP Address

When Authentication Agent runs on a host that has multiple network interface cards, and therefore multiple IP addresses, you must specify a primary Agent host IP address to use for encrypted communications between Authentication Agent and RSA Authentication Manager. Agent hosts typically attempt to discover their own IP addresses. An Agent host with multiple addresses might select one that is unknown to RSA Authentication Manager, making communication between Authentication Agent and Authentication Manager impossible. You can specify an overriding primary IP address by including the CLIENT_IP keyword in an sdopts.rec file on the Authentication Agent host. 

Note: The Dynamic Host Configuration Protocol (DHCP) allocates IP addresses to Agent hosts dynamically. To avoid address conflicts, install the Auto-Registration utility when you install Authentication Agent.

To specify an IP address override in the sdopts.rec file, follow this example:
CLIENT_IP=192.168.10.19

This statement ensures that the Authentication Agent host always uses the specified IP address to communicate with Authentication Manager.
The Authentication Agent ignores this setting if the computer has the IP address override option set in the RSA Control Center. However, if you installed the Auto-Registration utility (during or after the Authentication Agent installation process), the address that the utility registers overrides the IP setting in the Control Center. (The IP address override setting field also appears inactive once you install the Auto-Registration utility.) 

***********

The RSA Authentication Agent also checks the IP addresses of servers specified in its sdopts.rec file against this latest server list. Each server specified in the sdopts.rec must be listed by IP address in either the sdconf.rec file or on the server list. Otherwise, the server is considered by the agent to be an unknown server that cannot receive authentication requests. A message is also recorded about the server with status of Unknown in the trace log on the agent.

As it checks the IP addresses, the agent will set its server priorities based on the those specified by the USESERVER or AVOID keywords in the sdopts.rec file, which have been copied to sdstatus. If those keywords are not present, the agent computes priorities by comparing server response times, as found in sdstatus. Thereafter, the agent sends authentication requests based on its set priorities until the next time the agent is restarted.

Format for adding the USESERVER and AVOIDSERVER keywords are to list one or more servers in a list (one server per line, followed by the IP address and a weighted score. For example, 

USESERVER=86.75.30.9

The ALIASES keyword in the sdopts.rec file helps a version 5.x and 6.x  agent make successful network connections to the ACE/Server or Authentication Manager server when authentication requests must be sent to those servers through firewalls. The agent checks the alternate IP addresses (aliases) specified in the sdopts.rec file against its latest server list. If the aliases are valid, the agent will send authentication requests to those aliases, in addition to the alias IP addresses specified in sdconf.rec and on the server list.

Note: You must enter keywords in uppercase.
If none of the servers with USESERVER statements are responsive,
then the default server is the master (if one exists) or the
Authentication Manager server used to create the sdconf.rec file is the
master.