--- title: Troubleshoot description: Ping Identity provides support services, professional services, training, and partner services to help you set up and maintain your deployments. Learn more in Getting support. component: web-agents version: 2025.11 page_id: web-agents:maintenance-guide:troubleshooting canonical_url: https://docs.pingidentity.com/web-agents/2025.11/maintenance-guide/troubleshooting.html page_aliases: ["user-guide:troubleshooting.adoc"] section_ids: get-info-about-problem: Get information about the problem websocket-issues: WebSocket issues validate-agent: Validate the agent check-websocket-jars-are-loading: Check the WebSocket jars are loading test-websocket-connection: Test the WebSocket connection tls-key-logging: TLS key logging apache_web_agent_example: Apache Web Agent example common-issues-solutions: Common issues and solutions installation-upgrade: Installation and upgrade start-up: Start up logs: Logs other-issues: Other issues --- # Troubleshoot Ping Identity provides support services, professional services, training, and partner services to help you set up and maintain your deployments. Learn more in [Getting support](https://docs.pingidentity.com/web-agents/release-notes/support.html). ## Get information about the problem When you are trying to solve a problem, save time by asking the following questions: * How do you reproduce the problem? * What behavior do you expect, and what behavior do you see? * When did the problem start occurring? * Are there circumstances in which the problem does not occur? * Is the problem permanent, intermittent, getting better, getting worse, or staying the same? If you contact us for help, include the following information with your request: * Description of the problem, including when the problem occurs and its impact on your operation. * The product version and build information. * Steps you took to reproduce the problem. * Relevant access and error logs, stack traces, and core dumps. * Description of the environment, including the following information: * Machine type * Operating system and version * Web server and version * Java version * Patches or other software that might affect the problem ## WebSocket issues If you're experiencing issues with WebSocket connections, perform the following troubleshooting steps: * [Validate the agent](#validate-agent) * [Check the WebSocket jars are loading](#check-websocket-jars-are-loading) * [Test the WebSocket connection](#test-websocket-connection) ### Validate the agent The `agentadmin --V` command performs a number of checks, including WebSocket tests. Learn more in [agentadmin --V](../installation-guide/agentadmin.html#vi). The results of the tests are output to the command line and show tests as `ok` or `not ok` depending on whether they passed, for example: ```none ... validate_system_resources: ok validate_session_profile: skipped Agent websocket open error: error (6) validate_websocket_connection: not ok ... ``` You can find further information about the tests and detailed results in the Validator log (`validate_nn.log` located in the agent `/log` directory). ### Check the WebSocket jars are loading You can check the jars are being loaded on the AM Tomcat as follows: 1. Run the noisy command from the Tomcat `bin` directory, for example: ```none $ cd /path/to/tomcat/bin $ lsof | grep websocket ``` * If the WebSocket jars are loading, you'll see responses similar to the following: ```none java 1014 root mem REG 8,1 225632 2097375 /usr/local/tomcat/lib/tomcat-websocket.jar java 1014 root mem REG 8,1 36905 2097376 /usr/local/tomcat/lib/websocket-api.jar java 1014 root 38r REG 8,1 36905 2097376 /usr/local/tomcat/lib/websocket-api.jar ... ``` * If the WebSocket jars aren't loading, you won't see them listed. 2. Add the following option to the Tomcat startup script (`setenv.sh`) to view further details about the Java WebSocket API loading: ```none JAVA_OPTS=-verbose:class ``` The Java WebSocket API is bundled with Tomcat. 3. Restart the web container. 4. Review the `catalina.out` log file for WebSocket details. For example, you'll see entries similar to the following if the WebSocket API is available: ```none $ cat ../logs/catalina.out | grep websocket [Loaded org.forgerock.openam.notifications.websocket.JsonValueDecoder from file:/path/to/tomcat/webapps/am/WEB-INF/lib/openam-notifications-websocket-7.5.0.jar] [Loaded org.forgerock.openam.notifications.websocket.NotificationsWebSocketConfigurator from file:/path/to/tomcat/webapps/am/WEB-INF/lib/openam-notifications-websocket-7.5.0.jar] [Loaded javax.websocket.EncodeException from file:/path/to/tomcat/lib/websocket-api.jar] ... ``` | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The `openam-notifications-websocket-x.x.x.jar` is required for WebSockets to work. If it's missing, you'll see `404` responses. To resolve this, verify your Tomcat configuration or contact your System Administrator for further assistance. | ### Test the WebSocket connection You can test the WebSocket connection by sending the agent's token to the notifications endpoint using curl. This test generates a response similar to what is output in the Validator log. 1. Authenticate as the agent to return the agent's token: ```none $ curl \ --request POST \ --header "X-OpenAM-Username: agent-id" \ (1) --header "X-OpenAM-Password: password" \ (2) --header "Content-Type: application/json" \ --header "Accept-API-Version: resource=2.1" \ 'https://am.example.com:8443/am/json/realms/root/realms/alpha/authenticate?auth-service' (3) ``` | | | | ----- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | Replace *agent-id* with the ID of the agent profile you created. | | **2** | Replace *password* with the agent password. | | **3** | Replace *auth-service* with either `authIndexType=module&authIndexValue=Application` or `authIndexType=service&authIndexValue=Agent` depending on whether you [authenticate](../installation-guide/pre-installation.html#authenticate-agent-idc) using the default non-configurable authentication module or a journey called `Agent`. | If authentication is successful, the response includes the `tokenId` that corresponds to the agent session and the URL to which the agent would normally be redirected. For example: ```json { "tokenId":"AQIC5wM...​TU3OQ*", "successUrl":"/am/console", "realm":"/alpha" } ``` 2. Send the agent's token to the notifications endpoint, for example: ```none $ curl \ --verbose \ --show-headers \ --no-buffer \ --header "Connection: Upgrade" \ --header "Upgrade: websocket" \ --header "Host: agent.example.com:443" \ --header "Origin: https://notagent.example.com:8443" \ --header "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" \ --header "Sec-WebSocket-Version: 13" \ --header "iPlanetDirectoryPro: AQIC5wM…​​TU3OQ*" 'https://am.example.com:8443/am/notifications' ``` The notifications endpoint applies some login processing logic using a servlet filter and returns one of the following responses: * 101 response A `101` response indicates everything is ok. It confirms the request is valid, it has been upgraded successfully, and the WebSockets connection is working correctly. > **Collapse: Example 101 response** > > ```none > * Trying 198.51.100.0... > * TCP_NODELAY set > * Connected to am.example.com (198.51.100.0) port 8443 (#0) > > GET /am/notifications HTTP/1.1 > > Host: agent.example.com:443 > > User-Agent: curl/8.71.0 > > Accept: */* > > Connection: Upgrade > > Upgrade: websocket > > Origin: https://notagent.example.com:8443 > > Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ== > > Sec-WebSocket-Version: 13 > > iPlanetDirectoryPro: AQIC5wM…​​TU3OQ* > > > > > < HTTP/1.1 101 > HTTP/1.1 101 > < X-Frame-Options: SAMEORIGIN > X-Frame-Options: SAMEORIGIN > < Upgrade: websocket > Upgrade: websocket > < Connection: upgrade > Connection: upgrade > < Sec-WebSocket-Accept: qGEgH3En71di5rrssAZTmtRTyFk= > Sec-WebSocket-Accept: qGEgH3En71di5rrssAZTmtRTyFk= > < Date: Mon, 21 Oct 2024 17:38:15 GMT > Date: Mon, 21 Oct 2024 17:38:15 GMT > ``` * 403 response A `403 Access Forbidden` response means the agent has failed to establish a WebSocket connection with AM. You'll see `401` responses for this issue in the logs. A common reason for a `403` or `401` response is a mismatch between the agent cookie name and the cookie name in AM. The [agent cookie name](../properties-reference/com.sun.identity.agents.config.cookie.name.html) is used to construct the request sent to the notifications endpoint and must match what AM is expecting. Learn more in [Cookies](../user-guide/cookie-reset.html). * 404 response A `404` response typically means the WebSocket request has not been upgraded but the request sent to the notifications endpoint is valid. Possible causes for a `404` response are: * A network issue such as incorrectly configured load balancers or reverse proxies. * A Tomcat issue such as a missing `openam-notifications-websocket-x.x.x.jar`. ## TLS key logging You can log TLS keys to help troubleshoot and diagnose TLS issues between the agent and AM. To log TLS keys, you must: 1. Set the [Enable TLS key logging](../properties-reference/org.forgerock.agents.config.tls.keylog.enable.html) property to `true`. 2. Specify the name of the SSL key log file in the [AM\_SSL\_KEYLOG\_FILE](../user-guide/configure-envvars.html#am-ssl-keylog-file) environment variable. | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Only enable TLS key logging when advised by Support. After troubleshooting, disable key logging and remove the SSL key log file.The SSL key log file contains potentially sensitive TLS transaction data and should be protected from unauthorized access. | ### Apache Web Agent example 1. Set the `org.forgerock.agents.config.tls.keylog.enable` property to `true` in the `agent.conf` file. 2. Set the `AM_SSL_KEYLOG_FILE` environment variable to a suitable file in the `setenv.sh` file. The agent must have write access to this file. 3. Restart the web server. 4. Start a packet capture using [tcpdump](https://www.tcpdump.org) on the agent. For example, where AM is listening on port 4443: `tcpdump -i enp0s8 -s 0 -w /tmp/apache-agent-am.pcap 'port 4443'` 5. Make requests to the agent to initiate traffic from the agent to AM. 6. Stop the packet capture. 7. Unset the `AM_SSL_KEYLOG_FILE` environment variable in the `setenv.sh` file. 8. Set the `org.forgerock.agents.config.tls.keylog.enable` property to `false` in the `agent.conf` file. 9. Restart the web server. 10. Send the SSL key log file and packet capture to Support for troubleshooting. 11. Remove the SSL key log file from your system. ## Common issues and solutions | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The `agentadmin` command offers a validation mode for the agent that can help you troubleshoot issues in your environment; for example, after an agent upgrade or a network change. Learn more in [agentadmin --V](../installation-guide/agentadmin.html#vi). | ### Installation and upgrade > **Collapse: Shared memory errors during upgrade or installation** > > * Question > > During upgrade or installation, what should I do if I get shared memory errors? > > * Answer > > 1. Stop the web server where the agent is installed. > > 2. Delete the following shared memory files: > > * `/dev/shm/am_cache_0` > > * `/dev/shm/am_log_data_0` > > Depending on your configuration, the files could be named differently. > > 3. Start the agent. > **Collapse: Error installing agents with SELinux** > > * Question > > I am trying to install Web Agent on a server with SELinux enabled in `enforcing` mode, and I am getting error messages after installation or the web server does not start up. What happened? > > * Answer > > When installing Web Agent on Linux or Unix servers, you must ensure that the user that runs the web server process has read and write permissions for the agent installation directory and files. > > If SELinux is enabled in `enforcing` mode, you must also ensure that SELinux is configured to allow the web server process to perform read and write operations to the agent installation directory and files. By default, SELinux only allows the web server process to read files in well-known authorized locations, such as the `/var/www/html` directory. > > For environments where security can be more relaxed, consider setting SELinux or the `httpd_t` context in `permissive` mode for troubleshooting purposes. > > You can find details about configuring SELinux in the Linux documentation. > **Collapse: Failure after installation** > > * Question > > After starting a web agent installation, I see a failure in the logs: > > ```none > [../resources/troubleshooting/troubleshooting.bash:#web-agent-install] > ``` > > * Answer > > Web Agent installation, can fail if AM's validation of the agent configuration exceeds the default timeout of 4 seconds. > > You can set the `AM_NET_TIMEOUT` environment variable to change the default timeout, and then rerun the installation. > **Collapse: Errors after upgrade** > > * Question > > I have upgraded my agent and, in the logs, I can see errors similar to the following: > > ```none > redirect_uri_mismatch. The redirection URI provided does not match a pre-registered value. > com.iplanet.sso.SSOException: Invalid Agent Root URL > com.iplanet.sso.SSOException: Goto URL not valid for the agent Provider ID > ``` > > What should I do? > > * Answer > > Web Agent accepts only requests sent to the URL specified by the Agent Root URL for CDSSO property. For example, `https://agent.example.com:443`. > > As a security measure, Web Agent prevents you from accessing the agent on URLs not defined in the Agent Root URL for CDSSO property. Add entries to this property when: > > * Accessing the agent through different protocols. For example, `http://agent.example.com/` and `https://agent.example.com/`. > > * Accessing the agent through different virtual host names. For example, `https://agent.example.com/` and `https://internal.example.com/`. > > * Accessing the agent through different ports. For example, `https://agent.example.com/` and `https://agent.example.com:8443/`. > **Collapse: Configuration not updated after upgrade** > > * Question > > I have upgraded my Unix Apache or IBM HTTP Server Web Agent, and even though notifications are enabled, the agent does not update its configuration. What is happening? > > * Answer > > Set the web agent logging level to the maximum by performing the following steps: > > 1. Set the environment variable `AM_SYSTEM_LOG_LEVEL` to `ALL` in your command line session. For example: > > ``` > $ export AM_SYSTEM_LOG_LEVEL=ALL > ``` > > 2. Restart the Apache or IBM HTTP server. > > 3. Check the logs generated in the `/path/to/web_agents/agent_type/log/system_n.log` file. > > Sometimes stopping or upgrading an agent does not clean the pipe file the agent uses to communicate with AM. If the newly started agent cannot create the pipe to communicate with AM because it already exists, the agent would log messages like the following: > > ```none > ... UTC DEBUG [1:10551398][source/monitor.c:503]monitor startup > ... UTC ERROR [102:10551398]monitor unable to get semaphore > ... UTC DEBUG [304:10551398][source/config.c:295]config_initialise(): agent configuration read from cache, agent: / wpa-aix7-Httpd7-32bit > ``` > > If you see similar error messages, perform the following steps to delete the pipe file: > > 1. Stop the Apache or IBM HTTP server. > > 2. Change directories to the `/tmp` directory. > > 3. Delete the `monitor.pipe` file. > > 4. Restart the Apache or IBM HTTP server. ### Start up > **Collapse: Apache agent start up** > > * Question > > I have installed the Unix Apache Web Agent, and neither Apache HTTP Server nor the agent start up or log any message. If I remove the agent, the Apache HTTP Server starts again. What can be the problem? > > * Answer > > To troubleshoot Web Agent or a web server that does not start, set the agent logging level to the maximum by performing the following steps: > > 1. Set the environment variable `AM_SYSTEM_LOG_LEVEL` to `All` in your command line session. For example: > > ``` > $ export AM_SYSTEM_LOG_LEVEL=ALL > ``` > > 2. Restart the Apache HTTP Server. > > 3. Check the logs generated in the `/path/to/web_agents/agent_type/log/system_n.log`. > > Web Agent reserves memory for the policy and session cache based on the `AM_MAX_SESSION_CACHE_SIZE` environment variable. If the server where the agent is installed does not have enough shared memory available, the web agent may log messages like the following: > > ```none > 017-11-10 12:06:00.492 +0000 DEBUG [1:7521][source/shared.c:1451]am_shm_create2() about to create block-clusters_0, size 1074008064 > 2017-11-10 12:06:00.492 +0000 ERROR [1:7521]am_shm_create2(): ftruncate failed, error: 28 > ``` > > The error message means the web agent tries to reserve 1074008064 bytes of memory, but there is not enough shared memory available. Several reasons may explain why the shared memory is running low, such as: > > * A new application or additional workload may be stretching the server resources to the limit. > > In this case, ensure that the server has enough shared memory available to satisfy the need of all the applications. > > * A web agent may not have been able to release its shared memory after stopping. Therefore, even if the shared memory is technically not in use, it is still reserved and cannot be reassigned unless freed. > > Different operating systems manage the shared memory in different ways. Refer to your operating system documentation for information about checking shared memory usage. > > You can reduce the amount of memory the web agent reserves for the session and policy cache by setting the `AM_MAX_SESSION_CACHE_SIZE` environment variable to a value between 1048576 (1 MB) and 1074008064 bytes (1 GB). Learn more in [Environment variables](../user-guide/configure-envvars.html). > > Troubleshooting a component that does not start and does not generate logs may be difficult to diagnose. Contact Support for more help and information. ### Logs > **Collapse: Logs not written** > > * Question > > Why are logs not being written to `/log/system_0.log` and `/log/monitor_0.pipe` files? I am seeing this error: > > ```none > unable to open event channel > ``` > > * Answer > > It is likely that the agent does not have permission to be able to write to the `/log/system_0.log` and `/log/monitor_0.pipe` log files. > > This can occur if you used the `agentadmin --V[i]` validator command using a user account that is different to the account used to run your web server. > > Run the validator command as the same user that runs the web server, for example, by using the `sudo` command. > > To fix the issue, change the ownership of these files to match the user or group that is running your web server. > **Collapse: Cannot rotate logs** > > * Question > > My web server and Web Agent are installed as root, and the agent cannot rotate logs. I am seeing this error: > > ```none > Could not rotate log file ... (error: 13) > ``` > > What should I do? > > * Answer > > If the web server is running with a non-root user, for example, the `daemon` user, you must ensure that user has the following permissions: > > * Read Permission: > > * `/web_agents/agent_name/lib` > > * Read and Write Permission: > > * `/web_agents/agent_name/instances/agent_nnn` > > * `/web_agents/agent_name/log` > > Apply execute permissions on the folders listed above, recursively, for the user that runs the web server. > > For IIS or ISAPI agents, change the ownership of the files using the `agentadmin --o` command. Learn more in [agentadmin command](../installation-guide/agentadmin.html). > > | | | > | - | ---------------------------------------------------------------------------------------------------------------------------------------- | > | | You may also see similar issues if SELinux is enabled in `enforcing` mode, and it isn't configured to allow access to agent directories. | ### Other issues > **Collapse: HTTP headers are ignored** > > * Question > > When I map a response or attribute to an HTTP header, using the following properties, why is the header ignored: > > * [Session Attribute Map](../properties-reference/com.sun.identity.agents.config.session.attribute.mapping.html) > > * [Response Attribute Map](../properties-reference/com.sun.identity.agents.config.response.attribute.mapping.html) > > * [Profile Attribute Map](../properties-reference/com.sun.identity.agents.config.profile.attribute.mapping.html) > > * Answer > > When injecting information into HTTP headers, do not use underscores (`_`) in the header name. Underscores are incompatible with systems that run CGI scripts, and the header can be silently dropped. > **Collapse: Port 80 used as default** > > * Question > > My Apache HTTP server is not using port 80. When I install Web Agent it defaults to port 80. How do I fix this? > > * Answer > > You probably set `ServerName` in the Apache HTTP Server configuration to the host name, but did not specify the port number. > > Instead, set both the host name and port number for `ServerName` in the configuration. For example, if you have Apache HTTP Server configured to listen on port 8080, then set `ServerName` appropriately as in the following excerpt: > > ```none > > ServerName www.localhost.example:8080 > ``` > **Collapse: Protection against phishing attacks** > > * Question > > How do I increase security against possible phishing attacks through open redirect? > > * Answer > > You can specify a list of valid URL resources against which AM validates the `goto` and `gotoOnFail` URL using the Valid `goto` URL Resource service. > > AM only redirects a user if the `goto` and `gotoOnFail` URL matches any of the resources specified in this setting. If no setting is present, it is assumed that the `goto` and `gotoOnFail` URL is valid. > > To set the Valid `goto` URL Resources, use the AM admin UI, and go to Realms > *Realm Name* > Services > Add > Validation Service, and then add one or more valid `goto` URLs. > > You can use the "\*" wildcard to define resources, where "\*" matches all characters except "?". For example, you can use the wildcards, such as `https://website.example.com/*` or `https://website.example.com/*?*`. For more specific patterns, use resource names with wildcards as described in [Configuring success and failure redirection URLs](https://docs.pingidentity.com/pingam/8/am-authentication/redirection-url-precedence.html). > **Collapse: Infinite redirection loops** > > * Question > > I have client-based (stateless) sessions configured in AM, and I am getting infinite redirection loops. In the `debug.log` file I can see messages similar to the following: > > ```none > ... +0000 ERROR [c5319caa-beeb-5a44-a098-d5575e768348]state identifier not present in authentication state > ... +0000 WARNING [c5319caa-beeb-5a44-a098-d5575e768348]unable to verify pre-authentication cookie > ... +0000 WARNING [c5319caa-beeb-5a44-a098-d5575e768348]convert_request_after_authn_post(): unable to retrieve pre-authentication request data > ... +0000 DEBUG [c5319caa-beeb-5a44-a098-d5575e768348] exit status: forbidden (3), HTTP status: 403, subrequest 0 > ``` > > What is happening? > > * Answer > > The redirection loop happens because the client-based (stateless) session cookie is surpassing the maximum supported browser header size. Since the cookie is incomplete, AM cannot validate it. > > To ensure the session cookie does not surpass the browser supported size, configure either signing and compression or encryption and compression. > > Learn more in AM's [Security guide](https://docs.pingidentity.com/pingam/8/security/session-state-configure-cookie-security.html#policy_agent5_client-based). > **Collapse: Custom pages aren't displayed** > > * Question > > After upgrade, the default Apache welcome page appears instead of my custom error pages. What should I do? > > * Answer > > Check your Apache `ErrorDocument` configuration. If the custom error pages are not in the document root of the Apache HTTP Server, enclose the `ErrorDocument` directives in `Directory` elements. For example: > > ```none > > ErrorDocument 403 myCustom403Page.html > > ``` > > You can find details about `ErrorDocument` in the [Apache](https://httpd.apache.org) documentation. > **Collapse: Agent not protecting a website** > > * Question > > My Web Agent is not protecting my website. In the logs, I can see errors similar to the following: > > ```none > ... -0500 ERROR [86169084-5648-6f4d-a706-30f5343d9220]config_fetch(): failed to load configuration for agent: myagent myagent, error -24 > ... -0500 ERROR [86169084-5648-6f4d-a706-30f5343d9220]amagent_auth_handler(): failed to get agent configuration instance, error: invalid agent session* > ``` > > What is happening? > > * Answer > > The Web Agent is unable to log in to AM. Possible causes are: > > * Network connection between the agent and AM is unavailable. > > * The [AM Connection URL](../properties-reference/com.sun.identity.agents.config.naming.url.html) property, which specifies the AM URL may be misconfigured. > **Collapse: Agent not protecting a website** > > * Question > > My Web Agent is not protecting my website. In the `debug.log` file I can see messages similar to the following: > > ```none > ... GMT DEBUG [162ba6eb-cf88-3d7f-f92c-ee8b21971b4c]: (source/oidc.c:265) agent_realm does not have the expected value: JWT > { > "sub":"bjensen", > "auditTrackingId":"267d1f56-0b97-4830-ae91-6be4b8b7099f-5840", > "iss":"https://am.example.com:8443/am/oauth2/alpha", > "tokenName":"id_token", > "nonce":"D3AE96656D6D634489AF325D90C435A2", > "aud":"webagent", > "s_hash":"rxwxIoqDFiwt4MxSwiBa-w", > "azp":"webagent", > "auth_time":1561600459, > "forgerock":{ > "ssotoken":"wi8tHql...MQAA*", > "suid":"267d1f56-0b97-4830-ae91-6be4b8b7099f-5647" > }, > "realm":"/alpha", > "exp":1561607661, > "tokenType":"JWTToken", > "iat":1561600461, > "agent_realm":"/alpha" > } > ... GMT WARNING [162ba6eb-cf88-3d7f-f92c-ee8b21971b4c]: redirect_after_authn(): unable to validate JWT > ``` > > What is happening? > > * Answer > > If you configured the agent profile in a realm other than AM's top-level realm (`/`), you must configure the agent `com.sun.identity.agents.config.organization.name` bootstrap property with the realm where the agent profile is located. For example, `/alpha`. > > Realm names are case-sensitive. Failure to set the realm name exactly as configured in AM causes the agent to fail to recognize the realm. > **Collapse: Can't access protected resources** > > * Question > > I am getting HTTP 403 Forbidden messages when accessing protected resources, and I can see errors similar to the following in the `debug.log` file: > > ```none > ... GMT WARNING [69d4632c-82af-b853-0f340vb7b754]: too many pending authentications > ... GMT ERROR [69d4632c-82af-76da-b853-0f340vb7b754]: save_pre_authn_state(): unable to save state for request > ``` > > What is happening? > > * Answer > > Agents store the progress of authentication with AM in the pre-authentication cookie, `agent-authn-tx`. This cookie has a maximum size of 4096 bytes, and can fill up if the agent receives many parallel unauthenticated requests to access protected resources. > > Learn more in [Enable Multivalue for Pre-Authn Cookie](../properties-reference/org.forgerock.openam.agents.config.multivalue.pre.authn.cookies.html). > **Collapse: Can't access protected resources** > > * Question > > I am getting HTTP 403 Forbidden messages when accessing the Web Agent. > > * Answer > > Make sure the Web Agent is executable: > > 1. In the terminal where the Web Agent is running, go to `/opt/web_agents`. > > 2. Review and, if necessary, change the permissions for the directory: > **Collapse: WebSocket connections** > > * Question > > I am seeing errors such as the following: > > ```none > WARNING: Failed to create new WebSocket connection, backing off > org.forgerock.openam.agents.notifications.websocket.WebSocketConnectionException: Failed to create connection > ``` > > * Answer > > Make sure any load balancers or reverse proxies configured in your environment support WebSocket protocols.