In a system report, there are fields labeled with headers such as Description, Instance Name and Client IP that are easy to identify in syslog output based on the words strung together in detail for the Description. For example, the FQDN and Instance Name of the primary or replica(s) and the Client IP field listing the IP address of agents, but there are other fields in the system report that are not intuitive (e. g.. Argument 1 through 10).
This article provides a comprehensive listing of these fields names to improve the reading of this message when sent to a syslog.
Authentication Manager reports have fields that are titled Argument1, Agument2, Argumentn, etc. Depending on the report type there can be six or ten argument fields in a report. Some reports have a More Arguments or More Args field as well. For the Argument fields, we might see the following in a Run Time Authentication Activity report:
Here, Argument1 is the authentication event type, this all in a RunTime Activity Authentication report we may see Argument1 we might see AUTHN_LOGIN_EVENT, under Argument2 we might see a number like 6, under Argument3 might have another number like 4 and Argument8 has what looks like an ID, for an agent or other authenticator shown here as 4dd565180f5d2a0a1af9877e490eecf0
All of the argument fields in Authentication Manager logs are context based for that specific log and are not universal. They are basically for RSA Engineering debug purposes and not for customer reports. The argument fields contain information such as internal database user IDs, device IDs, agent IDs, etc.; that is, long strings of numbers that would never be useful in a report, but may be useful when debugging. This is why some fields are not even clear within the runtime or admin audit reports, let alone in the syslog.
Please open a support case and ask the support engineer to open a JIRA defect that we can present to Engineering if your issue meets the following criteria:
You cannot glean the meaning of the information in the syslog based on the limited information contained in KB 000032240 and the syslog data explained.xlsx file;
You believe that you need to know this specific argument field in a specific use case, and
You cannot figure out the information from the context.
Creating a Report
To create a report login to the Security Console.
Select Reporting > Reports > Add New.
Select either the Authentication Activity, Administrator Activity or System Log Report template.
Enter a name for this report (e. g., Authentication Activity).
Running a Report
From the Security Console select Reporting > Reports > Manage Existing.
Click on the report name and select Run Report Job Now.
In the Input Parameters Values, enter the relevant values.
When done, click Run Report.
Click Refresh List.
When the report disappears, click the Completed tab.
Click on the report name and choose your viewing option (i. e., browser, CSV, XML or HTML).
There are three pieces of information that will allow an administrator to work out the data being sent to the remote syslog server.
RSA Authentication Manager has three tables that store runtime (authentication), administrative and system log data. The RSA Authentication Manager 8.2 Developer Guide, available in the RSA Authentication Manager 8.2 SP1 Extras.zip, provides the table structures for the runtime log table (IMS_LOG_AUDIT_RT), administration log table (IMS_LOG_AUDIT_ADM) and system log table (IMS_LOG_SYSTEM).
The Security Console provides three reporting templates called Authentication Activity (for runtime), Administrator Activity (for admin) and System Log Report (system) that report data from the three logging tables.
Action Key: AUTH_NODE_VERIFICATION Column C = action id: 23005
Field 8: IP addresses for the agent or Client and Authentication Manager server that authenticated this transaction,
Field 9: IP addresses for the agent or Client and Authentication Manager server that authenticated this transaction,
Field 13: Column G = result key or reason: NS_MISMATCH_SERVER_HAS_BUT_AGENT_DOESNT
Field 21 shows an agent ID or a Security Domain ID, but either way, that information is useless off of the Appliance, it is something Engineering might need if debugging a report or agent or priv problem
Field 22 with 000000000000000000000100e0011000 looks like Argument 4 from an Authenticaiton activity report, which should translate into User identity source ID, either the Internal Database or an external LDAP Identity Source like Active Directory
Field 23 is the same as field 8. It looks like a client or agent IP address, but you could verify from an authentication activity report.
Field 25 is Agent Type. Many older types are not specifically called out in Authentication Manager 8.x because they are no longer needed. Agent types are as follows:
Password authentication for Security Console/Self-Service Console/Operations Console (Authentication Manager 7.1 and 8.x)
Communication Server; migrated from RSA Authentication Manager 6.1, wider acceptable passcode window of +/- 2
Single Transaction Server; cannot handle New PIN or Next Tokencode Mode and will not prompt for them.
Net OS Agent; migrated from RSA Authentication Manager 6.1
Authentication from agents (e. g., agents for Apache/IIS, PAM, Windows, Native SecurID, local authentication client, etc.) and from RADIUS clients.
Passcode authentication for Security Console/Self-Service Console (Authentication Manager 7.1 and 8.x)