Reports

Reports

Lynx 1.6.0 only provides one report, the All Audit Events report. This report is explained below. If you wish to create other reports then you would need to write SQL queries against the Lynx database. However, in order to do this, you must have Lynx configured to use a Microsoft SQL Server database and not the embedded database. This is because there is no way to connect to and query the embedded database.

All Audit Events

To run the All Audit Events report, sign-on to the Lynx Admin web app, click Reports (on the left) then click the All Audit Events link. The All Audit Events report displays all the events that Lynx has audited (recorded in the database). These events can be sorted by any of the available columns by clicking on the column header. The number of records per page can also be controlled by the “Show (X) entries” dropdown at the top of the report. You may also search through the audit events by typing text in the Search text box. Audit events that contain the text that you type will be displayed in the list.

Columns

Name

• Id
  • The number itself is merely a system-generated number to identify the event. Clicking on the Id link will take you to a detailed view of the event (see below).
• AppName
  • The name of the Lynx client for which the event was posted.
• IpAddress
  • The IP address of the client system for which the event was recorded.
• RequestDateTimeUtc
  • The date and time in Universal Time Coordinated (UTC) format that the client system made the request. The client system will send this data to Lynx to be audited. So it is actually the date and time on the client system. Lynx does not check this data. It merely records what the client system sends.
• RequestId
  • A unique (GUID) value that is sent by the client system. It is the responsibility of the client system to send a unique (GUID) value with each request it sends to Lynx. Lynx then simply records this value.
• SessionId
  • A unique (GUID) value that is sent by the client system. It is the responsibility of the client system to track the activity of a particular user under a session and each call to Lynx on behalf of that session should use the session ID for the session. Therefore, it should be possible to query a particular session ID and determine all the activity for a particular user during that session. Lynx does not validate the session ID, it simply records what the client sends for this value.
• MethodName
  • The name of the method that the client called during the request to Lynx.
• ResultCode
  • The outcome of the request to Lynx. This is the value that Lynx sends back to the client as a result of the request the client has made.

Audit Event Detail View (Example)

Following is a sample detail view of a particular audit event. You can get a detail view of an audit event by running the All Audit Events report, then clicking the Id link of the event you are interested in. An explanation of each of the values in the detail view is provided below. Note that depending on the particular audit event, some of these fields may not have a value. For example, if the particular audit event did not occur as the result of a prox card action, then the ProxCardId and ProxCardBitCount fields will not have values. In the detailed explanation below, each field that is required to have a value for all audit events is designated with “Required” while the others are designated with “Optional”.

• Id (Required)
  • This value is automatically generated by Lynx for each audit event that is recorded. It provides a unique identifier for each event.
• AppName (Required)
  • When a request is sent to Lynx, the app that sent the request is required to provide its name in the AppName value.
• AppVersion (Required)
  • The version of the app that is making its request to Lynx.
• Hostname (Required)
  • The name of the host system on which the app is running that is making its request to Lynx.
• IpAddress (Required)
  • The IP address of the host system on which the app is running that is making its request to Lynx.
• OsName (Required)
  • The name of the operating system (OS) on which the app is running that is making its request to Lynx.
• OsVersion (Required)
  • The version of the operating system (OS) on which the app is running that is making its request to Lynx.
• RequestDateTimeUtc (Required)
  • When an app makes a request to Lynx, it must include the date and time of the request (in UTC time). This will be the date and time as it is on the client system, which may not match the date and time on the Lynx system.
• ResponseDateTimeUtc (Required)
  • When Lynx returns its response, it fills this field with the date and time (in UTC time) of the response. This will be the date and time on the Lynx system.
• RequestId (Required)
  • When an app makes a request to Lynx, the app must generate a unique Id (in the form of a GUID) and include it in the request. Lynx simply records the value that the client sends for this RequestId.
• SessionId (Required)
  • It is the responsibility of the app on the client system to track the activity of a particular user. This activity is subsumed under a “session” and each call to Lynx on behalf of that session should use the session ID for the session. Therefore, it should be possible to query a particular SessionId and determine all the activity for a particular user during that session. Lynx does not validate the SessionId value, it simply records what the client sends for this value.
• MethodName (Required)
  • When an app makes a call to Lynx it calls a particular method such as GetProxCardUser or ValidatePassword. Lynx records (audits) which method was called by the app and fills in this field with the name of the method that was called.
• ResultCode (Required)
  • When Lynx returns the result of a request, it records the result in this ResultCode field.
• ProxCardId (Optional)
  • If an app makes a request to Lynx that is the result of a prox card action on the client system, then the app must include the id number of the prox card in this field. However, this field may not have a value if the request was not the result of a prox card action on the client system.
• ProxCardBitCount (Optional)
  • If an app makes a request to Lynx that is the result of a prox card action on the client system, then the app must include the bit count of the prox card in this field. However, this field may not have a value if the request was not the result of a prox card action on the client system.
• UserName (Optional)
  • If the client app has the user name for the user on whose behalf it is making the request to Lynx, then it must send the user name to Lynx and Lynx will then record it in this field. However, this field may be blank in cases where the username is unknown. For example, if a person taps a prox card and the card is not yet registered then there would be no username associated with the card and therefore this field would be blank.
• LogOnTo (Optional)
  • This field will contain the domain or realm or area to which the user is associated. Typically this will be the Windows domain to which the user belongs.
• RequestReasonCode (Optional)
  • In the case where the client app makes a request to Lynx to update the prox card user record, it must include a code that indicates the reason for the request. Lynx will record (audit) the reason code in this field. In other cases, this field will be blank. The valid reason codes are:
    • 1 = PIN Authentication Failed
    • 2 = Tap-Out
    • 3 = Tap-In
    • 4 = Tap-Lock
    • 5 = Tap-Unlock
• ResultMessage (Required)
  • Lynx will supply a short readable message that corresponds to the ResultCode value. This makes it easier to see the result of a request without having to know all the ResultCode values.
• EventParams (Optional)
  • Client apps can send an audit record to Lynx for any reason. When they do, they should include information that specifies why they are sending the audit record and any additional data to include with the record. This field will then contain this additional data.