On the STA Access Management console, access logs provide information about access attempts and authentications. Each access attempt, whether it was through SAML, OIDC, RADIUS, or auth nodes, is recorded as one entry in the access logs.
The access logs include the following information about access attempts:
Timestamp: The timestamp identifies when STA completed processing the access attempt. For example, the timestamp indicates the time after the authentication successfully completed or failed.
User ID / Alias / Email: The identity of the user who made the access attempt can include the user ID, alias, and email.
Result / Reason: The result can be Success, Failure, or Denied. The reason for failed or denied requests is indicated.
The access type is also identified. The type can be SAML, OIDC, Agent, or an agent type for an auth node. The following are the possible agent types:
Outlook Web Access
Citrix Web Interface
Remote Desktop Gateway
Remote Management API
Oracle Access Manager
Remote Web Workplace
The application icon is displayed for SAML, OIDC, and agents that are configured on the Applications tab. A generic icon is used for RADIUS and auth nodes.
Credentials: The credentials that were required or used can include OTP, Password, Kerberos, Certificate, and so on. If the credential requirements are met by an existing SSO session, rather than by the user entering their credentials, this is indicated by (Session). For example, OTP (Session) or Password (Session).
IP Address: The public IP address from which the user initiated the access attempt is identified.
You can also view the access logs for an individual user on the Users tab. These logs are presented in the same format and include the same information as the access logs on the home page.
Reasons for failed or denied access attempts
The following are the possible reasons for failed or denied access attempts:
Reasons for failed access attempts
The following reason values are possible when the state is Failed:
|CA revocation check failed
|The certificate authority revocation-check failed.
|Certificate attribute not found
|The user ID could not be extracted from the user certificate using the configured certificate attribute.
|Chain verification check failed
|The chain verification check failed.
|Issuing CA expired
|Issuing CA not in trust store
|The certificate is valid, but is not directly issued by any of the configured issuing certificate authorities (CA).
|The user certificate was not found.
|TLS authentication failed
|The authentication of the certificate failed. This may be because the certificate was invalid, the user entered an incorrect PIN, or the authentication timed-out.
|User certificate expired
|The date when the user certificate is no longer valid was reached.
|User certificate on hold
|The user certificate was on hold.
|User certificate revoked
|The user certificate was revoked.
|User mapping failed
|The certificate attribute and user attribute do not match.
|User revocation check failed
|Unable to perform revocation checks for user certificates. This authentication may also succeed depending on revocation check settings.
|User revocation check timed out
|The process to perform the revocation check for user certificates timed out. This authentication may also succeed depending on revocation check settings.
|Failed to collect context data
|STA was unable to collect the client information that it needs to determine which scenario to apply. Examples of context data include the IP address and browser information.
|Claims provided at external idp setting mismtach
|There is a mismatch at the external IDP.
|No response from external identity provider
|No activity has occurred at the external IDP login page for a period of time.
|The FIDO authentication timed out or was canceled by the user. This error can also occur when the user doesn't have a FIDO token and self-provisioning is not enabled.
|FIDO service down
|The FIDO server is not responding and STA is unable to communicate with it.
|FIDO service error
|There is an unknown FIDO server issue.
|FIDO verification failed
|The FIDO server returned an error during authentication, which can occur when the user provides an invalid challenge response or invalid keys.
|Password and OTP token
|All authentication-node access attempts that failed, such as invalid OTPs.
|The date when the password is no longer valid was reached.
|The user provided an incorrect password or OTP.
|No active token
|The user did not have an active token for authentication.
|The STA service is not active for the virtual server.
|STA experienced an unusual situation.
|The user ID is invalid or unknown to the system.
|The user account is dormant or locked.
|The user provided an incorrect user name.
Reasons for denied access attempts
The following reason values are possible when the state is Denied:
|Denied per policy
|Access is blocked based on a policy or scenario condition.
|Not assigned to application
|The user is not assigned to the application and therefore not authorized to access the application.
|Outside allowed management IP ranges
|The access attempt originated from an IP address that is outside the allowed IP ranges.
Access log filters
You can search the logs for specific outcomes or applications.
By default, the logs include all users and a 90-day date range, and can display a maximum of 20 pages.
You can filter the logs by user, date range, application, or result and reason:
User filters the logs for a specific user. Search the logs by user ID, alias, or email address.
Date filters the logs for a date range.
Applications include the following filters:
User Apps are configured through auth nodes or on the Applications tab. The list includes only applications for which there are logs after any other selected filters are applied (user, date, or results and reasons).
Console includes the STA Token Management console and STA Access Management console.
Management APIs include the APIs in the REST API for STA and the Remote Management APIs, such as BSIDCA.
Results and Reasons include the Success, Failed, and Denied results, and the reasons for Failed and Denied access attempts, such as invalid credentials. The list includes only reasons for which there are logs after any other selected filters are applied (user, date, or applications).
Applying multiple filters
You can combine the different types of filters (user, dates, applications, or results and reasons), and apply multiple applications or results and reasons filters.
When you combine different types of filters (user ID, date range, application, or results and reasons), STA applies the different types of filters using AND logic, which means that it displays only the logs with all of the selected filter types.
When you apply multiple filters of the same type (applications, or results and reasons), STA applies the filters of the same type using OR logic, which means that it displays the logs for access attempts with any of the selected results and reasons.
View the access logs
On the STA Access Management console, select the Home tab, and then select the Access Logs tab.
All the logs are displayed. You can filter the logs by user and date.
To filter the logs by user ID, type one or more of the starting characters in the search box. You can include letters or numbers.
STA displays the logs only for user IDs that start with those characters.
To filter the logs by date, enter the Start Date or End Date.
The date filters use only dates (such as 2019-04-25) and exclude the time of day. The date filters use your local time zone, based on the time zone setting in your browser. The default is a 90-day period.
The default start date is 90 days before the current date. The start date can be any time up to and including the current date.
The default end date is the current date. The end date can be the same as or later than the start date.
To switch the Timestamp column between Local Time and UTC Time, use the view selector:
Local Time is based on the time zone setting in your browser. This view selector affects only the timestamps and does not affect the Start Date and End Date filters, which always use your local time zone.
To add a Results and Reasons or an Applications filter, select the Add Filter icon, and then select a filter.
The list of Results and Reasons or Applications includes only reasons or applications for which there are logs after any other selected filters are applied (user, date, results and reasons, or applications).
Add more filters as needed.
To update the list of logs without resetting the filters, select Refresh the logs:
Review the access log fields
Authentication events in access logs
If an access attempt was followed by authentication events, then the logs include each associated authentication event as a child of the access attempt.
When you filter the access logs, the filtered results include any associated authentication logs that meet the filter criteria.
To view an associated authentication event, expand the access attempt entry. You can expand multiple access event entries at the same time.
You can also view the authentication events in the Authentication Activity module in the STA Token Management console.
To view all the authentication events for the user, in the Extended Features menu, select Snapshot > Authentication Activity.
Export the access logs
You can export the logs to a CSV file. The scope of the exported logs is constrained by the filters that are set when you export the logs.
The exported CSV log file includes both the access log entries and their associated authentication logs entries. In the exported file, the authentication logs entries are grouped with their parent access log entries. An access event identifier is included in the exported file, but is not displayed on the STA Access Management console. The access event identifier relates an authentication log entry with its parent access log entry.
From the STA Access Management console, you can export a maximum of 10,000 access logs, including all of the associated authentication events. This means that, although the number of top-level records is limited to 10,000, the number of rows can vary. To export a larger number of logs, use the logs API.
Filter the logs as required.
The Export Access Logs to CSV dialog box displays a default file name and a list of the data that is included in the log.