AM Web Agent Install – How To Verify

This topic has 6 replies, 2 voices, and was last updated 1 week, 6 days ago by jdbell.

  • Author
  • #28111

    Running Apache and Tomcat in a Win 10 environment.

    Have AM up and running and performed a policy config per QuickStart guide. Created the agent profile and installed the agent (at least I didn’t get an error when confirming config).

    Not working in blocking access to my Apache home page, so now I’m troubleshooting.

    1) Is there any way I can validate the agent install worked? I see nothing in the Apache logs.
    2) I’m using port 8080 in my AM and agent config server URLs. Would this be an issue, as I thought SSL was not required to support this simple use case?


     Andy Cory

    In the bin folder of the agent install location, look for the agentadmin utility. If you run this with agentadmin --Vi agent_1 (where ‘agent_1’ is the instance of the agent – probably you will only have one, but it’s possible to have more) you should get some useful output with regard to checking the installation.E.g.:

    Saving output to /opt/openam/agent/web_agents/apache24_agent/bin//../log/validate_20200226184019.log

    Running configuration validation for agent_1:

    Agent instance is configured with 1 naming.url value(s):
    1. is valid
    selected as naming.url value
    validate_bootstrap_configuration: ok
    validate_ssl_libraries: ok
    validate_agent_login: ok
    validate_system_resources: ok
    validate_session_profile: skipped
    validate_websocket_connection: ok
    validate_worker_init_shutdown: ok

    Result: 6 out of 7 tests passed, 1 skipped.

    The log file mentioned in the output will give a lot of more verbose info.

    You should be fine with port 8080 non-SSL. THe agent logs are separate to the Apache logs, and should be fond in something like instances/agent_1/logs/debug/debug.log. The verbosity of these logs is controlled in the agent profile in AM.


    Thanks for this. I found an agent specific install log and see the following:

    2020-07-27 20:16:31 OpenAM Web Agent for Apache Server interactive installation
    2020-07-27 20:16:31 license was accepted earlier
    2020-07-27 20:17:03 server configuration file c:\xampp\Apache\conf\httpd.conf
    2020-07-27 20:17:03 OpenSSL library status: trying ssleay32… found libssl-1_1-x64.dll, failed to load SSL_library_init, failed to load SSLv23_client_method, failed to load SSL_state, failed to load SSL_load_error_strings, trying libeay32… found libcrypto-1_1-x64.dll, failed to load CRYPTO_num_locks, failed to load CRYPTO_set_locking_callback, failed to load CRYPTO_set_id_callback, failed to load OPENSSL_add_all_algorithms_noconf, failed to load ERR_free_strings, failed to load ENGINE_cleanup, failed to load EVP_cleanup, failed to load CRYPTO_cleanup_all_ex_data, OpenSSL v1.1.x library support is available
    2020-07-27 20:17:44 OpenAM URL
    2020-07-27 20:18:35 Agent URL
    2020-07-27 20:18:41 Agent Profile name WebAgent
    2020-07-27 20:18:46 Agent realm/organization name /openam
    2020-07-27 20:18:58 Agent password file c:\pwd.txt
    2020-07-27 20:18:58 agent password file c:\pwd.txt opened successfully
    2020-07-27 20:19:02 validating configuration parameters…
    2020-07-27 20:19:02 error validating OpenAM agent configuration
    2020-07-27 20:19:02 installation error
    agent login to fails

    2020-07-27 20:19:02 installation exit

    It appears the installer’s attempt to log into the AM instance is failing. The OpenAm URL in the log is correct. The WebAgent profile is set with ‘password’ as the password. And the file at ‘c:\pwd.txt’ (which I presume is being used to credential the login) has one line with the word ‘password’ in it. So, I would assume a match.

    What could I be missing here? Is that in fact the validation path the installer is trying to use? What else might the installer login process be looking for?


     Andy Cory

    Forgive the obvious question – was AM running at the time of the install?

    Assuming it was, there’s nothing in the log file that suggests a cause – if the password file had incorrect content or couldn’t be opened by the agent install this would happen, but you’ve checked that, and the log says the file could be opened. The agent authenticates (pretty much) as an end user does, it needs the correct username and password. The username is the agent profile name, which looks like WebAgent in your case. This matches the actual profile name in AM? And the agent profile is defined in a realm called openam that is a sub-realm of the top level realm?

    Could you try the agentadmin check I indicated earlier? That might give a bit more info. The log is verbose, as I said, but even the command line output gives a clear indication of the ‘validate_agent_login’ step results.


    Just to clarify, per the QuickStart guide I am using the Top Level realm. It shows an alias of ‘openam’, thus why I’m using that as the realm id in the installer. Thanks


    However, what is curious is that even though the Top realm shows active with an alias of ‘openam’, it appears I should be able to access it via ‘’. But the link isn’t working. But ‘’ works fine.

    All other defaults when selecting the Top Realm were left the same per the QS guide. Am I missing something? Thanks


    OK –

    Now I’m confused. I’m trying to install the 5.6.3 version of the web agent. In digging into the Agents Guide , it staes a few things:

    – 5.6.3 agents require the WebSocket protocol (hassle to get working with Apache)
    – 5.6.3 agents rely on SSL to communicate with AM via WebSocket

    If true, the QuickStart steps just got alot more complex

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

©2020 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?