[BUG] Wazuh dashboard throws internal server error (500) after password change and Passwords get NOT changed.

[APX-IT]

Describe the bug

Wazuh Dashboard serves a 500 error / internal server error on the web interface for a previously logged in admin user (browser cookies still present) after changing default passwords as described in https://documentation.wazuh.com/current/user-manual/user-administration/password-management.html#changing-the-passwords-in-a-distributed-environment Also Wazuh Indexer logs suggests Wazuh dashboard is trying to connect with kibanaserver user & the admin user with the wrong credentials (old/default credentials). This behaviour ends as soon as the Wazuh dashboard web interface gets opened from a incognito browser window. This is also true for the below errors appearing in the cluster log which suggests that Wazuh dashboard hits the Wazuh indexer cluster with old credentials until the front-end get successfully loaded once. After manually deleting cookies and reloading the login page comes back up.

Wazuh indexer log - /var/log/wazuh-indexer/wazuh-indexer-cluster.log:

...
[2023-10-19T14:54:01,798][WARN ][o.o.s.a.BackendRegistry  ] [wazuh-indexer-01.domain.tld] Authentication finally failed for 1.2.3.4:38790
...
[2023-10-19T15:01:47,129][WARN ][o.o.s.a.BackendRegistry  ] [wazuh-indexer-01.domain.tld] Authentication finally failed for admin from 1.2.3.4:54674

Wazuh dashboard IP redacted to 1.2.3.4 in above log

Wazuh dashboard log (manually configured via logging.dest in opensearch_dashboard.yml:

{"type":"log","@timestamp":"2023-10-19T15:20:03Z","tags":["error","http","server","OpenSearchDashboards"],"pid":1807,"message":"Error: Authentication Exception\n    at SecurityClient.authinfo (/usr/share/wazuh-dashboard/plugins/securityDashboards/server/backend/opensearch_security_client.ts:115:13)\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n    at /usr/share/wazuh-dashboard/plugins/securityDashboards/server/auth/types/authentication_type.ts:208:18\n    at Object.interceptAuth [as authenticate] (/usr/share/wazuh-dashboard/src/core/server/http/lifecycle/auth.js:112:22)\n    at exports.Manager.execute (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/toolkit.js:60:28)\n    at module.exports.internals.Auth._authenticate (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/auth.js:273:30)\n    at Request._lifecycle (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/request.js:371:32)\n    at Request._execute (/usr/share/wazuh-dashboard/node_modules/@hapi/hapi/lib/request.js:281:9)"}

Expected behavior

• Just invalidate the login and logout the user that still has old credentials in its browser data / cookies instead of throwing a 500 error and redirect to login page.
• I would have expected that the back-end would be immediately able to communicate with the Wazuh indexer cluster with the correct credentials after password change and restart of wazuh-dashboard service and not be dependent on a first successful load of the front-end.
• front-end action like hitting the server with invalid cookies should not throw a internal server error

OpenSearch Version 2.6.0

Dashboards Version vanilla installation of 4.5

Plugins vanilla installation

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: Ubuntu 22.04
• Browser and version: Firefox 118.0.1 - User-Agent string: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

[AlexRuiz7]

@APX-IT

After manually deleting cookies and reloading the login page comes back up.

I'd say this is the expected behavior. Once you log in, a JWT token is stored in the browser. This token is valid until one of the following conditions happen:

• The token expires.
• The user logs out.

If you change the passwords while being logged in, the app will use the token because none of these conditions have happened, although the token itself has been already revoked by the indexer's security plugin due to the permissions / credentials change.

This behaviour ends as soon as the Wazuh dashboard web interface gets opened from a incognito browser window.

Incognito mode sessions flush all cache, cookies and local storage, so again, that's a perfectly normal and expected situation, as a new token is generated for this session.

The only thing I'd expect is to have a 401 Unauthorized code instead of 500, but aside from that, I do not see any problem in your report.