User Diagnostics portal

Trouble-shoot user application access issues, ACL and authorization violation issues, network connectivity issues using diagnostics console.

In EAA, we have a diagnostics console which helps the EAA admin troubleshoot user reported issues quickly. The User Diagnostics page can be accessed by navigating to System > User Diagnostics.

The user diagnostics is available for access-applications (web, VNC, RDP, and SSH), and client-access (TCP-type, tunnel-type, tunnel 2.0) applications. It is not available for SaaS and bookmark applications. This feature is not available on Internet Explorer (IE) version 11 browser but works in IE Edge, Chrome, Firefox, and Safari browsers.

When the end user has a problem with EAA, he opens a support ticket with the IT helpdesk. Normally, the username, device ID, URL of the login portal (identity provider URL), date, time and problem description is added to the support ticket. The problem description may include the name of the application, the last time the application was accessed when it worked, and the time and date when it stopped working. The admin can upload relevant information into the user diagnostics page and narrow down the causes for the problem for accessing the application using these sections:

  • ACCESS. View application requests, application volume (bytes in/out) , errors, and application configuration events.
  • POLICY. Review any access, authorization policy violations and take actions to fix them.
  • NETWORK. Check the connectivity and the status of each network segment, and troubleshoot mis-configuration issues.

The admin enters the User ID or Device ID, selects the identity provider URL, and the time range (up to a maximum of 7 days) when the problem occurred. All of the client-access applications that were accessed on the different EAA Client device IDs are shown on the different tiles, and all of the access applications (web, VNC, RDP, SSH applications) are shown in one tile. During the time range selected, if there was no activity for any access-application, then this tile may not appear. He can select the tile based on the information in the support ticket, if it is a client-access application (Tunnel or TCP) or an access application (web, VNC, RDP, SSH) that had the problem and the device that was used.

The admin can go to the access section, policy section, and network section to investigate the problem further.

Here are details about the different sections:

ACCESS section

This section shows all applications accessed by the user in the time period, including access applications (web, SSH, RDP, and VNC) and client-access applications. All access applications are shown as and client-access applications are shown as . By default, the applications list is sorted by Requests in the descending order. You can also select to view the applications sorted by Volume or Errors in the descending order. Requests are the total number of times the user tried accessing the application in the selected time period using the selected devices. Volume is the total MBytes over the time period. Errors are the total number of errors encountered by the user while accessing the application in the selected time period using the selected devices.

The name of the application that appears in the Applications list can be related to the application configuration as follows:

For a wildcard tunnel client-access application (), all of the applications within the domain are shown in the Applications list. And when you hover over it, you will see the endpoint host name. For example:

For an access application (web) and tcp-type client-access application, the external host name appears in the Applications list. For example:

You can click on the application you want to troubleshoot and examine more data in the chart. Alternatively, you can also filter for the name of the application from the support ticket in the right of the access section.

The admin can view a chart for the problem application. The X axis is the date and time range. The Y axis shows the different data like volume (in MB), requests, denies (4xx HTTP messages), and errors (5xx HTTP messages) distribution over the time period. The volume is represented as a bar graph with the scale on the left. The requests, errors, denies are represented as line graphs with the scale on the right. The chart also shows the application deployment events on the timeline as a green diamond. This chart helps the admin correlate any changes in the traffic, requests, denies, errors against the deployment events. The admin can click the link next to the application hostname to directly go to the application configuration and make any changes. Also, the admin can hover over to the green diamond, see the deployed version, admin name and see any comments about the deployment changes. Further, the admin can click the View deployment history. This takes the admin to the deployment history section of the deployment tab within the application configuration. The admin can quickly revert to older deployments, fix any application mis-configurations, and re-deploy the applications to address any access issues.

Over the selected time-range, if the user has not accessed the application during off-peak hours, like night-time, you may not see any data.

POLICY section

This section shows all access control list (ACL) violations, authorization violations for all the applications in the selected tiles and identity provider in the time range by the end user. If the admin knows the Application Fully Qualified Domain Name (FQDN) or identity provider name from the support ticket, he can also filter by that name. Multiple violations for one application are shown in separate rows. Authorization violations for the identity provider like accounts locked after too many incorrect logins, MFA errors, invalid credentials are also shown here.

To fix an ACL violation, the admin can click the “Edit Rules” under Actions. It takes the admin to the ACL rules page for the application. The admin can update the ACL and redeploy the application.

To fix the IdP authorization violation, the admin can click the “Edit Directories for IdP”, assign the correct directory to the IdP and deploy the IdP.

If there are no violations, then no data is displayed for the time range.

NETWORK section

The admin selects and/or searches for an application he needs to troubleshoot. A time slider appears with traffic data for the application. You can use the forward and backward button to navigate through each data point to see the status/errors, latency, bytes in/out in each of the network segments at that time instant. The different network segments are the user and cloud zone, and cloud zone and the connector. If there is an accelerated service like IP Application Accelerator (IPA), then it’s included in the user to cloud zone network segment.

Note: If you have multiple connectors for high-availability, they will also be shown as separate network segments between the cloud-to-connector, and connector-to-origin app server for each connector.

After you select an application, a graph with a time slider appears for the application. You can use the forward and backward buttons to navigate through the data, failed requests indicated by status/errors, latency and bytes in/out at each time instant.

Data can be present or absent at a time instant. The square on the time-slider summarizes the net status of all the network segments. It is interpreted as follows:

Time-slider description table
Square on time slider Status in network segments Interpretation
Not applicable No data. Cannot see the network segments.
Green dot everywhere. Data present. All network segments less than 50% failed requests.
Multiple status in different network segments. Data present. Different network segments have different % failed requests. See network segment status description table.

Generally the user accesses the application more during weekdays, less during evenings and maybe zero access during weekends. So, you might not see any data (a small black square) on weekends.

EAA aggregates the failed requests and it is expressed as a percentage to show a colored dot for each network segment. If there is no activity then the network segment is not shown.

Network segment status description table
Network segment status Interpretation
Red dot Alert (more than 75% requests have failed)
Yellow dot Warning (50% to 75% requests have failed)
Green dot Normal (less than 50% requests have failed). Service is healthy.

The admin can examine this information to check the health of the different network segments over different timelines before and after the problem occurred. If any recognizable patterns are seen, then provide the information to support for troubleshooting.