Here you can find some of the events, HTTP response codes, and errors that users encounter when they access or use applications. These can also be seen in the access log fetched via SEIM or ULS integration.

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 stored 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 Enterprise Center.

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 Enterprise Center. 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 Enterprise Center. 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.

464

HTTP response: 464 Request - The load balancer received an incoming request protocol that is incompatible with the version config of the target group protocol.

Description: You get this message from the AWS load balancer, when you you configure a Web App (HTTPS) with an AWS Load balancer using HTTP/2 as the protocol.

Possible solution: EAA does not support HTTP/2 protocol. You must use HTTP/1 as the protocol version in AWS load balancer when used with EAA Web Application.

492

HTTP response: 492 User Access Forbidden

Description: The user is not authorized to access the application. For a TCP-type or Tunnel-type client-access application, this can happen if the configuration changes have been deployed to the application but EAA Client has not received the updated configuration.

Possible solution:

1. Check user group assignment for your application. See Troubleshoot application access denied.

2. The TCP-type or Tunnel-type client-access application denied issue should rectify after EAA Client receives the updated configuration changes. If you see any platform performance issues due to many requests to EAA Client, with alerts, contact support for further assistance.

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 Miscellaneous section of Advanced tab 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.

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.

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 to increase Application Server Read Timeout in the Advanced tab for 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.

3. If connectivity between the connector and data POP is fine, try increasing the number of dial-outs on the application that encountered the issue.

542

HTTP response: 542 Internal Database Error

Description: Data POP cannot reach the authentication database. This can also happen when users are trying to perform authentication that is not configured on the identity provider, such as requests from Open ID Connect to an IdP.

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.

   a. 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.

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

   a. For Kerberos authentication, check KBSD supervisor logs.

   a. 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 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 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.

558

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

Description: A user has established more than 50 WebSocket connections. This also happens when you have a large volume of requests that have rate limiting applied to the connecting IP, provided the user is authenticated.

Possible solution:

1. 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.

2. It might also be possible that the traffic is not genuine and therefore we have this protection in place. Contact support to perform any checks.

559

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

Description: A user has established more than 50 WebSocket connections. This also happens when you have a large volume of requests that have rate limiting applied to the connecting IP, provided the user is authenticated.

Possible solution:

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

2. It might also be possible that the traffic is not genuine and therefore we have this protection in place. Contact support to perform any checks.

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 Access report. The following table describes some of the login events that you can find in the report.

When you download your application access report, you will also see these status updates in the Error column, as indicated below: