On the agent side, Error 13002 may display for a Windows agent.
In the authentication activity log, the result is Authentication method failed:
Description: User “<user ID>" attempted to authenticate using authenticator “SecurID_Native”. The user belongs to security domain “<security domain>” Result Key: Failure Result Key:AUTHN_METHOD_FAILED Result:Authentication method failed
This is a classic SecurID problem, compounded by RSA terminology that is less than intuitive. You have not yet successfully authenticated from this agent, which means the node secret - a symmetric encryption key - used between the agent and the Authentication Manager server has not yet been created.
Before the node secret is created, the initial encryption algorithm uses the agent's IP address to complete the authentication request. The agent encrypts the authentication request with its' primary IP address, but with so many IP addresses assigned to ethernet and wireless interfaces this becomes a percentage thing. What you think is the agent's primary IP address might not be what the agent selects when running the RSA authentication agent software.
Customer Support seen many instances where a secondary IP address was used, either from a multihomed agent or from a second Network Interface Card (NIC), such as wireless or sometimes the management IP address for VPN type devices. The problem arises when the Authentication Manager server tries to decrypt the authentication request with what it believes is the primary IP address for that agent, as defined in the agent host record in the Security Console under Access > Authentication Agents. It is this encryption and decryption with different IP addresses that causes every passcode to be incorrect.
The IP address override option forces the agent to encrypt with a specific IP address; thereby, not allowing the agent to choose its own primary IP for the initial RSA agent encryption.
As shown in the example below, the IP address entered for the IP Address Override on the agent in the RSA Control Center is 192.168.131.22 (at left). This matches the IP Address value for the authentication agent entry in the Security Console (at right).
Alternatively, create a text file named sdopts.rec that is saved on the agent to the same directory as the sdconf.rec file, with an entry like this:
If authentications continue to fail,
Get a list of all known IP addresses for the agent.
Navigate to Access > Authentication Agents > Manage Existing.
Enter an IP address from the list into the IP Address field (not the Alternate IP Address field) in the agent record and click Save.
With the Authentication Activity Monitor open, test authentication from the agent. Repeat this process until authentication is successful.
The output below is from the/opt/rsa/am/server/logs/imsTrace.log where the Authentication Manager server log level is set to Verbose. The information comes from a user named John Doe (jdoe) using an agent that encrypted the authentication request using IP address 10.0.0.8, which does not match the IP in the agent record entry in the Security Console, so the method returned the error response shown in red: