Here you can find some of the events, HTTP responses codes, and errors that users encounter when they access or use applications.

HTTP 400 - 4XX ERRORS

400

HTTP response: 400 Bad Request

Description: The application server is unable to process the request. For example, this error may occur if the end user provides an incorrect URL for the application.

Possible solution: Create an application activity report and check the application server logs.

HTTP response: 400 Bad Request - Request Header or Cookie Too Large

Description: HTTP request header or browser cookie exceeds the configured buffer value. This error can occur if the cookies are corrupted and need to be cleared from the end user's browser

Possible solution:

1. Clear the browser history, cache, and storied cookies, then try again.

2. Contact support and review together the backend NGINX configuration. The NGINX configuration can be modified to support large request headers and cookies.

401

HTTP response: 401 Authorization Required

Description: The end user has not properly authenticated to the application.

Possible solution: Make sure single sign-on (SSO) authentication is configured for the application in the EAA in EAA Management Portal.

403

HTTP response: 403 Forbidden

Description: The end user is not allowed to access the application.

Possible solution: Make sure the user access information matches the configured access rule in the EAA in EAA Management Portal. To learn more see Troubleshoot application access denied.

404

HTTP response: 404 Not Found

Description: The URL in the request cannot be found or does not exist.

Possible solution: Check if request URL is available in origin server.

405

HTTP response: 405 Action failed - HTTP method not allowed

Description: The action is not supported.

Possible solution: If you try to update an SSL certificate and receive this message, upload a new certificate to ​Akamai​. Update of existing certificate is not currently supported. To learn more see Certificate-based authentication in the IdP.

413

HTTP response: 413 Request Entity Too Large

Description: The request is too large and the application server cannot process it.

Possible solution: Contact support to increase the buffer for the application from the EAA in EAA Management Portal. See Proxy Buffer Size in Miscellaneous section of Advanced tab for the application.

414

HTTP response: 414 Request - URI Too Large

Description: The Uniform Request Identifier (URI) in the request is too large.

Possible solution: Create an application activity report and examine the logs.

492

HTTP response: 492 User Access Forbidden

Description: The user is not authorized to access the application.

Possible solution: Check user group assignment for your application. See Troubleshoot application access denied.

493

HTTP response: 493 Unsupported Browser

Description: The HTTP request does not contain Server Name Identification (SNI).

Possible solution: The browser did not send the Server Name Indication (SNI) extension as part of the TLS negotiation. Check if the browser version supports SNI, or try a different browser.

494

HTTP response: 494 Request Header Or Cookie Too Large (400)

Description: HTTP Request Header is bigger than configured buffer value. The default is 4K.

Possible solution: Create an application activity report to check the logs. Also, increase the Proxy buffer size in Settings > ADVANCED SETTINGS for the application.

HTTP 500 - 5XX ERRORS

500

HTTP response: 500 Internal Server Error

Description: There was an unexpected issue with the server.

Possible solution:

1. Create an application activity report to check the logs.

2. Use X-Ray-ID to check if the error comes from an application or from EAA . If the request went to the application, the access log contains a field that tracks the origin server IP.

3. Contact support for further assistance.

502

HTTP response: 502 Bad Gateway

Description: If the hostname of the HTTPS application does not match the origin server certificate, you get generic error.

Possible solution:

1. Check the hostname you provided for the HTTPS application matches the certificate from the EAA Management Portal in Applications > Your application name > Settings > GENERAL > Application Server IP/FQDN.

2. Confirm that the Server IP/FQDN in the Settings tab of the application matches the value in the certificate.

3. If the origin server takes more than the configured read-timeout to respond, contact support to increase Application Server Read Timeout in the Advanced tab for the application.

4. Check together access and error logs for the Cloud proxy and connector, and if there are any timeout errors.

503

HTTP response: 503 Service Temporarily Unavailable

Description: There was an unexpected issue with the server.

Possible solution: Contact support to check the error logs for the Data POP and connector.

504

HTTP response: 504 Gateway Timeout

Description: Timeout issue that occurs with the server. Some EAA applications may fail to load and result in an error when you try to load them. These applications may need more time to load. By default, Enterprise Application Access timeouts the application if it does not load in 60 seconds.

Possible solution:

1. Contact support to check the access and error logs for the Cloud proxy and connector. Check together if there's any timeout errors.

2. If the origin server takes more than the configured read-timeout to respond, contact support and increase Application Server Read Timeout in the ADVANCED SETTINGS tab for the application.

3. Click Show additional attributes.

4. Scroll to the Enterprise connectivity parameters section and go to the Application server read timeout field.

5. Change the field's value from the default 60 seconds to 300.

🚧

Only update this value with the guidance of support you contacted with. This value governs the maximum time that an application server may need to fulfill a request. The maximum value is 300 seconds (5 minutes).

1. Click Save and go to Deployment.

2. Deploy the application.

540

HTTP response: 540 Connectivity Disrupted

Description: The connector does not have dial-out connections to either the data POP for the application or access to the directory.

Possible solution:

1. Check the connector connectivity in the connector console.

2. See Troubleshoot application deployment. If the error is observed at login, it is possible that the directory configuration is missing on the connector.

542

HTTP response: 542 Internal Database Error

Description: Data POP cannot reach the authentication database.

Possible solution: Contact support for checking the authentication database.

543

HTTP response: 543 IdP Communication Error

Description: Data POP cannot reach IdP or directory service.

Possible solution: Contact support to check:

• Error logs in Data POP and connector.

• If there is a connectivity issue in the login or IdP POP.

In the case of private POP deployments behind DMZ, confirm if the on-prem DNS servers can resolve the login service or IdP.

544

HTTP response: 544 Management Communication Error

Description: Login/Authentication POP cannot reach mgmt login manager.

Possible solution: Contact support to check:

• Error logs in Data POP and connector.

• If there is a connectivity issue between the log-in or IdP POP and management log-in manager.

• If the management log-in manager service is running.

545

HTTP response: 545 Authentication Internal Error

Description: Data POP cannot resolve/reach the authentication database.

Possible solution: Contact support to check the error logs in the data POP and connector, and the authentication database.

546

HTTP response: 546 Unknown Application

Description: Login/Authentication POP does not have the application configuration.

Possible solution: Contact support to check the log-in or IdP POP to see if the application is deployed in the POP.

548

HTTP response: 548 Invalid Response

Description: Response received from the login server could not be validated via back-channel request from the Cloud proxy to the login server.

Possible solution:

1. Create a report of the error and access logs for the proxy and login servers.

2. Search the logs for the X-Ray-ID, a unique identifier for every HTTP request that flows through EAA .

3. Make sure that the response generated from the login server was not corrupted by a forward proxy between the client and EAA cloud.

4. Contact support.

549

HTTP response: 549 Authentication Gateway Error

Description: Login service cannot reach directories to complete the authentication process.

If you receive the error code 549 Authentication Gateway Error, then login service cannot reach a directory to complete the authentication process. To troubleshoot, contact support and share this procedure with them.

The path from the login server to directory begins from the directory end-point in the EAA Cloud, transports over directory dial-outs into the connector, and then uses a broker service on the connector using either LDAP or Kerberos protocols to complete the authentication with the enterprise directory.

If the user is a cloud user, then the login server contacts the Management POP (Mgmt POP) to validate the user credentials. Remember, the Cloud proxy is made up of the Data POP and Management POP.

Authentication gateway errors are observed when there is a problem with reaching directory endpoint from login service, reaching management pop from login service or reaching the broker service within the connector.

When third party identity providers are used, Authentication gateway errors also indicate problems with preparing protocol request for the third party or parsing protocol responses from the third party within the microservice instances on the login server specifically tasked for handling third party authentication.

All debugging however requires support. For cloud users experiencing this error, check if there is an issue reaching the login API service from the login service in the Data POP.

Possible solution:

1. Check the error logs in the login service to get the problem point. You can use the X-Ray-ID in the error message to search error logs and access logs specific to the request that failed.

2. Check connectivity issues between login server and users directory endpoint in the cloud.

3. Is the problem intermittent or consistent? Intermittent problems may indicate problems with specific instance of directory end-points or the connector. For example, a directory's configuration or binary version difference or a connector without connectors providing access to the directory, with one connector having a bad configuration or incompatible connector version.

   1. Check the agent logs to see if the agent with directory configuration is receiving the authentication request. You can search by X-Ray-ID again to see if API calls from the cloud are coming to the connector.

   2. For LDAP based authentication, check agent client logs.

   3. For Kerberos authentication, check KBSD supervisor logs.

   4. Check if supervisor on the agent indicates that LDAP broker or Kerberos Broker have restarted after crashes.

552

HTTP response: 552 Application Unreachable

Description: Application service is not reachable from connector.

Possible solution:

1. Contact support to check if the origin server IP/FQDN and port are correctly configured.

2. Troubleshoot application connectivity.

3. Set Health check configuration: Type to Disable and see if it fixes the issue.

553

HTTP response: 553 Directory Service Error

Description: Directory service errors commonly occur during Kerberos authentication steps such as fetch TGT, perform constrained delegation, and fetch service ticket. Additional information is typically displayed along with this error.

Possible solution:

1. Contact support to check if the service principal name (SPN) is configured correctly. This problem is mostly seen when deployed application is not configured properly. For example, the application may be setup as NTLM internally but the EAA administrator configured the application as a Kerberos application with incorrect SPN. With Kerberos-constrained delegation, this can indicate problems with the keytab file or permissions to delegate to a service for the service account associated with keytab file.

2. Create an admin event report and check the error logs and access logs associated with request that failed for more details.

3. Troubleshoot access to a Kerberized application.

554

HTTP response: 554 Authentication Token Error

Description: Kerberos token is not accepted by application.

Possible solution:

1. Check if Kerberos is selected as Application-facing Authentication method in the ADVANCED SETTINGS tab of your application.

2. Contact support to check if the service principal name (SPN) is configured correctly.

3. Troubleshoot access to a Kerberized application.

555

HTTP response: 555 Application does not support Kerberos

Description: No negotiate option found in 401 challenge.

Possible solution: Check if Kerberos authentication is enabled in the application server. If not, either enable Kerberos on the application server or change the Application-facing Authentication method in the ADVANCED SETTINGS tab of your application. To learn more see Troubleshoot access to a Kerberized application.

556

HTTP response: 556 Unexpected Authentication Challenge

Description: 401 challenge on URI not configured as login URI.

557

HTTP response: 557 KDC Unreachable

Description: 557 KDC Unreachable

Possible solution: Make sure at least one KDC is reachable in the customer data center. See Troubleshoot access to a Kerberized application.

559

HTTP response: 559 Connection Limit Stop: Service Concurrent Connections Exceeded

Description: A user has established more than 50 WebSocket connections.

Possible solution: The number of WebSockets per users is limited to 50 to avoid attacks on the system. Contact support and ask to perform back-end changes on the application.

561

HTTP response: 561 Invalid NTLM Challenge

Description: Connector received invalid NTLM challenge from server.

Possible solution: Troubleshoot receiving a password prompt for every application link.

562

HTTP response: 562 Credential Error

Description: Unable to encrypt or decrypt NTLM credentials.

Possible solution: Check if the credentials are correct and if so, contact support.

User may encounter standard HTTP status responses when attempting to access or use an application. This table describes some of these responses.

Login events

Login event information is included in the Application report. The following table describes some of the login events that you can find in the report.