Creating feature request, on behalf of customer.
Customer would like to request new feature, currently they apply this patch to the ui/ directory:

 

ui/include/classes/api/services/CUser.php.orig   2021-10-06 10:53:10.000000000 +0200

ui/include/classes/api/services/CUser.php  2021-10-07 10:07:58.000000000 +0200

***************

****1533,1539 ****

                              break;

  

                        case ZBX_AUTH_INTERNAL:

!                             if (!self::verifyPassword($user['password'], $db_user)) {

                                   self::exception(ZBX_API_ERROR_PERMISSIONS,

                                         _('Incorrect user name or password or account is temporarily blocked.')

                                   );

— 1533,1540 ----

                              break;

  

                        case ZBX_AUTH_INTERNAL:

! /* nlarod 20210930 Also allowing empty password if REMOTE_USER is set */

!                             if (!self::verifyPassword($user['password'], $db_user) && $_SERVER["REMOTE_USER"] != $user['username'] ) {

                                   self::exception(ZBX_API_ERROR_PERMISSIONS,

                                         _('Incorrect user name or password or account is temporarily blocked.')

                                   );

 

 

How to reproduce Kerberos server and how to set up it.

 

We are running Red Hat Identity Management (IdM). Currently on RHEL 8 servers.

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/installing_identity_management/index

This is equivalent to FreeIPA in related distributions like for example rockylinux.org

 

So, both our Zabbix server and our client machines are joined to our FreeIPA domain. It is very similar to Active Directory

In that sense.

 

On our linux machines we run:

ipa-client-install

to join to the existing FreeIPA (or IdM) servers.

 

The important thing this gives us is that we can then get a Kerberos ticket from the server like this:

kinit [email protected]

 

And with a valid ticket we can then talk to the regular Zabbix web interface via Kerberos authentication already.

In something like Microsoft Edge this works out of the box, and in firefox we have to change a setting in about:config

network.negotiate-auth.trusted-uris zabbixserver.vws.shell.com

 

We tell Zabbix to

[v] Enable HTTP authentication

under Authentication / HTTP settings and create users like [email protected]

 

On the Zabbix web server we use apache functionality to support Kerberos.

This works with a configuration block like this:

<Directory /var/www/zabbixserver/https>

  SSLRequireSSL

  AuthType GSSAPI

  AuthName "Kerberos Login"

  GssapiCredStore keytab:/etc/httpd/auth/zabbixserver.http.keytab

 

  Require valid-user

</Directory>

 

Now if I use curl to access something I get with:

curl https://zabbixserver.vws.shell.com/test
the apache log line:
client - - [15/Nov/2024:13:52:56 +0100] "GET /test HTTP/1.1" 401 381 "-" "curl/7.61.1"

 

Basically, permission denied because I don’t match “Require valid-user”

but if I tell curl to use Kerberos authentication I get with:

curl --negotiate -u : https://zabbixserver.vws.shell.com/test

the apache log line:

client - [email protected] [15/Nov/2024:13:53:14 +0100] "GET /test HTTP/1.1" 404 196 "-" "curl/7.61.1"

 

So, by using Kerberos, we hand over authentication to Apache. Apache will tell us who the authenticated user is.

 

For our API calls to Zabbix, we would also like to make use of any authenticated Apache users. Because then we can keep using Kerberos authentication for our API calls also.

Additional comments: 

Microsoft Active Directory is very similar to FreeIPA and Red Hat Identity Management. They are basically all Kerberos and LDAP.

So, the Apache configuration listed above also works for web servers joined to Active Directory, if you happen to have that.