You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Attempt 1:
I followed the steps at https://documentation.wazuh.com/current/deployment-options/docker/wazuh-container.html#setting-a-new-hash precisely:
1. I ran docker run --rm -ti wazuh/wazuh-indexer:4.9.1 bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh to generate a new hash for the kibanaserver based on a 12-character password containing a mix of characters (though I avoided using $ or &).
2. I downed the Wazuh stack.
3. Using the generated hash, I replaced the hash for “kibanaserver” in the “config/wazuh_indexer/internal_users.yml” file.
4. I changed the “DASHBOARD_PASSWORD” entry in my docker-compose.yml file to the plaintext version of the password.
5. I then attempted to bring the stack back up, but the indexer would fail to start. The following error would be repeatedly present in the logs:
1. [wazuh.indexer] Authentication finally failed for kibanaserver from [docker IP address:port]
Attempt 2:
Using a fresh default deployment of the Wazuh docker stack, I bash-shelled into the Indexer instance as root and attempted to run /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh --change-all. I was presented with the following error: ERROR: The sudo package is not installed and it is necessary for the installation.
Attempt 3:
This attempt was a bit of a Hail-Mary hack: In the “config/wazuh_indexer/internal_users.yml” file, I changed the "reserved" attribute to "false" for the kibanaserver account. I then logged into the kibanaserver account via the web interface and used the password reset functionality. This was unsuccessful, and almost immediately resulted in the same errors Attempt 2 got.
I would welcome any advice as to what I am doing wrong. I must say that It is quite ironic for a security platform to have such extreme complication in changing default credentials.
The text was updated successfully, but these errors were encountered:
What seems to be missing from the steps you've taken is an execution of securityadmin.sh script, as described in Applying the changes.
The password change process' complexity in Wazuh is due to use of the Opensearch project. You can read more about internal_users.yml, securityadmin.sh and their caveats in the Opensearch documentation, specifically here:
Additionally you can read about Opensearch security plugin tools (including securityadmin.sh) scheduled replacement in favor of more convenient API methods here.
Regarding the second attempt, the wazuh-passwords-tool.sh script does not work within containers and that is why we have this documentation to perform the password change.
Regarding the first attempt, as @t0x01 says in the previous message, you may not have executed the securityadmin.sh script, which applies the changes in Wazuh indexer. Please note that to change the password for the kibanaserver user you must change the user's password in Wazuh indexer (which involves changing the internal_users.yml file and running securityadmin.sh) and then change the keystore that Wazuh dashboard uses to connect (which you do by changing the DASHBOARD_PASSWORD environment variable).
I just ran a test and had no problems, sorry for the number of steps but as already mentioned these steps are largely inherited from the fact that Wazuh indexer is based on Opensearch.
Another thing you can check is if the hash you generated in step 2 is correct, since we have generated the hash and had a typing error or a strange character that we entered, which generated a hash that does not match the password we added to the DASHBOARD_PASSWORD variable, so I recommend that before adding the hash to the internal_users.yml file you verify it with a Bcrypt hash checker, it will not decrypt it but it will check if the hash and the password you are adding match.
If you have any other problems, do not hesitate to contact us.
Hi there --
I have been trying to change the default password for the kibanaserver account on Wazuh. After exhaustive, days-long efforts I have found it impossible to do without breaking the indexer. The documentation and instructions on how to do so have not yielded success.( https://documentation.wazuh.com/current/deployment-options/docker/wazuh-container.html#setting-a-new-hash)
Here is what I have tried:
Attempt 1:
I followed the steps at https://documentation.wazuh.com/current/deployment-options/docker/wazuh-container.html#setting-a-new-hash precisely:
1. I ran docker run --rm -ti wazuh/wazuh-indexer:4.9.1 bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh to generate a new hash for the kibanaserver based on a 12-character password containing a mix of characters (though I avoided using $ or &).
2. I downed the Wazuh stack.
3. Using the generated hash, I replaced the hash for “kibanaserver” in the “config/wazuh_indexer/internal_users.yml” file.
4. I changed the “DASHBOARD_PASSWORD” entry in my docker-compose.yml file to the plaintext version of the password.
5. I then attempted to bring the stack back up, but the indexer would fail to start. The following error would be repeatedly present in the logs:
1. [wazuh.indexer] Authentication finally failed for kibanaserver from [docker IP address:port]
Attempt 2:
Using a fresh default deployment of the Wazuh docker stack, I bash-shelled into the Indexer instance as root and attempted to run /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh --change-all. I was presented with the following error:
ERROR: The sudo package is not installed and it is necessary for the installation.
Attempt 3:
This attempt was a bit of a Hail-Mary hack: In the “config/wazuh_indexer/internal_users.yml” file, I changed the "reserved" attribute to "false" for the kibanaserver account. I then logged into the kibanaserver account via the web interface and used the password reset functionality. This was unsuccessful, and almost immediately resulted in the same errors Attempt 2 got.
I would welcome any advice as to what I am doing wrong. I must say that It is quite ironic for a security platform to have such extreme complication in changing default credentials.
The text was updated successfully, but these errors were encountered: