Application deployment, connectivity, authentication, or advanced settings issues may limit or block access to applications. Troubleshoot your applications deployment, check if they are connected, and accessible.

See Applications to learn more about the application services supported by Enterprise Application Access.

Make sure that your application settings are configured correctly. See Set up advanced settings for an application.

Troubleshoot application deployment

Make sure your application is associated with a connector and directory. The application card displays status information about your application. If the application status on the card appears as Deployment failed, then the application configuration in Enterprise Application Access needs to be examined. To troubleshoot:

1. Make sure that the application has a connector. See Associate a connector with an application.

2. Make sure that the application has a directory. See Assign a directory to an application.
   It may also be the case that your applications deploy but do not work when users try to access them. It's an application connectivity issue.

Troubleshoot application connectivity

Get your application back up and running. The application card displays status information about your application. If the application status on the card appears as App is down, then the application's server is not reachable by EAA connector. Note that the health status does not update automatically. It may also be the case that your application is deployed but do not work when users try to access them. To troubleshoot:

1. Check that the application origin server is running. Try to access the application without using EAA. If the application can be accessed without EAA continue to troubleshoot.

2. Make sure the application is deployed. See Deploy the application.

3. Test connector connectivity to applications with troubleshooting tools.

4. Review the application's access parameters in EAA and make changes as needed. To learn more about the access parameter fields see Configure access parameters for an application, Configure and deploy a SSH application, or Configure and deploy a remote desktop (RDP) application. Issues are commonly found with the information entered into these fields:

   • Application IP/FQDN protocol. Verify the protocol, such as SSH, HTTP, or HTTPS, is correct based on the application profile.

   • Application IP/FQDN first field. Verify the IP address or URL to access the application within your network is correct as it appears in the field and that the fully qualified domain name (FQDN) resolves to that IP.

   • Application IP/FQDN second field. Verify the IP port number is correct.

5. For SSH application check these fields:

   • SSH Username: If you identify an SSH username for the application, the application asks for a password at login. If you do not identify an SSH username for the application, the applications asks for both a username and password at login.
   • SSH Private Key and SSH Passphrase: If your SSH server is set up with SSH keys, you can enter your private key and optionally your SSH passphrase. If your server requires an SSH passphrase and you did not choose to enter it here, you have to enter it every time you access SSH server through Enterprise Application Access.

6. Make sure that the CNAME is configured correctly on the DNS server.

   • To learn more about configuring a CNAME redirect see Set up a CNAME redirect for an application.

   • To test whether a DNS server resolves to an IP address, Run a connector troubleshooting utility using the dig tool.

7. Make sure the directory can be reached by the connector. Test connectivity between the directory and connector.

8. Make sure the EAA health check is configured correctly. You configure health check information as part of the following:

   • Internet Content Adaptation Protocol (ICAP) services

   • URL path-based services

9. For remote desktop protocol applications (RDP), make sure the server Network Level Authentication field is unchecked. See Connect a Microsoft Windows server to an RDP application.

Troubleshoot application access and authentication

Application links not working

Make sure links to an application work. To check if links to an application do not work:

1. Make sure the application is deployed. See Deploy the application.

2. Make sure that the CNAME is configured correctly on the DNS server.

   1. To learn more about configuring a CNAME redirect see Set up a CNAME redirect for an application.

   2. To test whether a DNS server resolves to an IP address, Run a connector troubleshooting utility using the dig tool.

3. Verify the application's URL rewrite rules resolve correctly. See URL rewrite services.

Password prompt for every application

If your users are prompted to enter their password every time they click an application link, investigate your native Active Directory (AD) setup. To check if the native AD is set up properly make sure that the Microsoft network LAN manager (NTLM) is not configured for your application.

Application access denied

Make sure user's have access to applications. To check if a user's access to an application is denied:

1. Make sure the user's directory group is assigned to the application. See Assign a directory to an application.

2. Make sure the application access control rules are not blocking application access. See Access control rules.

Kerberized application access denied

Make sure your Kerberized applications are accessible.

Blocked access to the Kerberized application is usually caused by an incorrect service principal name (SPN) configuration. SPN is the name by which a Kerberos client uniquely identifies an instance of a service for a given Kerberos target computer.

1. Make sure the Kerberos Key Distribution Center (KDC) is reachable from the EAA connector. The EAA connector uses the DNS service record to resolve the KDC for the obtaining tickets. The DNS server used by the connector must be able to resolve the KDC service records such as, __kerberos.tcp.<domain-name>, for both the user's and the service's Kerberos domains.

2. Make sure the firewall rules allow reachability to ports 88 and the LDAP/LDAPS ports from the connector.

3. Make sure the clock for the EAA connector and the KDC are synchronized. Connectors rely on Ubuntu time servers to sync clocks. If the KDC runs on a different clock internally, you need to manually change the network time protocol (NTP) source on the agent to an NTP service that is used by the KDC.

4. Make sure the service principal name (SPN) is discoverable by the KDC. Review the application's advanced settings fields for accuracy and make changes as needed. For more information about the domain fields see Forward Kerberos ticket-granting ticket to application. Issues are commonly found with the information entered into these fields:

   1. Application-facing Authentication Mechanism. Verify that Kerberos is selected.

   2. Forward Kerberos Ticket-Granting Ticket to App. Verify that the checkbox is selected.

   3. Application authentication domain. Verify that the internal hostname is correct.

   4. Service Principal Name. Make sure that the SPN in this field is same as the SPN configured in the Active Directory (AD) account.

5. Make sure the SPN of the internal application uses the following schema for generating the SPN for the application: <service-protocol>/<service-fqdn>:<service-port>@<service-domain>.

   1. If the service protocol is HTTP or HTTPS, use HTTP.

   2. If service port is a standard port, then omit the port.
      Example of SPN format: setspn -s serviceClass/Host:Port AccountName.

Next, verify the KDC is not experiencing policy errors. The KDC may reject requests due to policy restrictions.

1. Determine the root cause. Examine the KDC logs.

2. Expand the scope of the policy to allow authentication requests from the EAA connector.

Delete an ​Control Center​ IdP or group from an application

You may encounter errors if you try to delete an identity provider (IdP) or group from an Enterprise Application Access (EAA) application.

For example:

• If you want to delete a group associated with the deleted application, go to the group section for a cloud directory and click Delete for the group. You may get the error message:

Action not allowed - This group is presently assigned to an application.

• If you try to delete the IdP you may get the error message:

Delete action not allowed - This IDP is presently associated with an application.

• If you try to remove the assignment the cloud directory in the IdP settings you may get the error message:

Unassign action not allowed - This directory is presently associated with an application.

You cannot delete a group or IdP that is associated with other applications, connectors, IdPs, or groups.

To fix the issue, check to see if other existing applications are using the IdP or group that you are trying to delete.

Troubleshoot MFA

Confirm users can receive multi-factor authentication (MFA) notifications. MFA notifications are sent to users by email, text message, or as pop-up. If a user has trouble with MFA, they should:

1. Look in their email spam folder. The authentication email may have been sent to spam.

2. Make sure their mobile phone or device is not set to Do Not Disturb mode. This may prevent authentication texts messages or pop-up notifications from going through.

3. If the issue persists reset the MFA password for a user.

Reset the onetime MFA password for a user

If you troubleshoot issues with a user's MFA, reset the one-time password (OTP) for the user. To do this, the user must be assigned to a directory with MFA enabled.

1. Log in to Enterprise Center.

2. In the Enterprise Center navigation menu, select Application Access > Identity & Users > Directories.

3. Select the directory that includes the user you are resetting the OTP for.

4. Click Users.

5. Select the user you are resetting the OTP for and click Reset OTP.

6. Click Sync Directory.

Troubleshoot page not working issues

If you access an EAA application from your external domain you may get This page isn't working message. If you see this pop up, check to determine what user is trying to access. This is usually because the external URL is not pointing to the correct EAA CNAME. For example, this CNAME is pointing to an A record instead of the CNAME:

$dig customer.abccustomer.com
;; ANSWER SECTION:

customer.abccustomer.com 429 IN     A    195.11.112.32

To fix the issue, create a CNAME entry in the external DNS that points to the EAA CNAME.

1. Log in to Enterprise Center.

2. In the Enterprise Center navigation menu, select Application Access > Applications > Applications.

3. Select the application to open it.

4. In the Settings > External host name see the correct CNAME information for your domain.

5. Deploy the application.