Zabbix Postgres Admin password bad

[mdiorio]

Hi everyone!

I'm just jumping back into an older Zabbix instance I have been testing with after some time off. Zabbix runs in Kubernetes, postgres/timescale run on a VM. I upgraded postgres to 13 without a problem. Not that I go to log into the Zabbix UI, my Admin user won't work - bad password.

I've tried to reset the user password in the database using: update users set passwd=md5('zabbix') where username='Admin';

Still doesn't work when I attempt to log in. Any ideas?

Thanks!

Max

[mdiorio]

So quick update - I was able to manually add LDAP via the database and set a user and can log in with that user without an issue. While in the UI, I attempted to update the password, which went fine (btw, password must be more than 8 characters, so resetting it to the default of zabbix is no good). Attempted to log in with the Admin account with new password - STILL fails.

One thing I don't like is that the LDAP password is plain text in the database - WHY!!!

It appears that IF LDAP is enabled, THEN local login is disabled - period. Not even the Admin user can log in.

NO GOOD!

[Markku]

How are you saving users' LDAP passwords in Zabbix?

Regarding local admin authentication, I recommend reading the documentation: https://www.zabbix.com/documentation...oups/usergroup

Markku

[mdiorio]

Not saving the User's LDAP Password. I guess I didn't make it clear. The password used for the LDAP Authentication Method is stored plain text.

I'm not sure how User Group documentation helps in this situation.

[Markku]

Right, do you have a suggestion how the password should be stored instead? If encrypted, how should the password decryption key be stored?

You should make a dedicated group for the local admin, and set the group to authenticate locally, not using LDAP.

Markku

[mdiorio]

The LDAP account password should be encrypted in the same way user passwords are encrypted. Who on earth does plain text passwords!

The default admin with the super admin role should probably ALWAYS be able to log in unless explicitly denied the login right. This whole user/alternate authentication setup seems a bit backwards.

In pretty much every other system that enables external authentication, you add your new auth method (LDAP in this case).
You then either sync, or create a user assigned to an authentication method. (In Zabbix you simply don't assign a password, which doesn't define which auth server is used)
You CAN create groups that define which auth mechanism is used. Which means I now need to duplicate groups if there are different auth methods, which doesn't make sense. Groups should define permissions, not the method of authentication.
And what happens with the default built in groups when enabling external auth? For example, Zabbix administrators? You can't change that group at all. So it goes by the "default" auth mechanism defined (Internal vs LDAP).

There should also be a method to import users and groups based on defined DN's.

[Markku]

The LDAP account password should be encrypted in the same way user passwords are encrypted. Who on earth does plain text passwords!

Verifying users' passwords is totally different case: there is no need to do decryption because the user supplies the clear-text password, and the system then hashes it and compares the hash to the stored hashed password. That is a one-way operation, there is (shoudn't be!) no way to find out the clear-text password from the hashed password.

In the LDAP case Zabbix server needs a way to find out the clear-text password so that it can supply it to the LDAP server when authenticating itself. Therefore a decryption mechanism is needed if the password is to be stored encrypted. And, the decryption mechanism needs some kind of key that needs to be accessible.

Markku

[vladimir_lv]

create Docker container from official Zabbix Docker images and find password there:

select passwd from users where username='Admin';