I thought I would post this just in case somebody else runs into this problem...
My setup: Debian (Squeeze/Main) / Zabbix 1.6.4 / Apache2
My Zabbix server lives in a huge AD forest. Due to IT Security Policies, using the built-in LDAP authentication is not an option. For anybody asking why, just do one of the following in index.php (before the footer) and you'll see why IT might have a problem:
or
Long story short, I decided to go with HTTP Auth. Apache2 is configured to use Apache2::AuthenNTLM::Cookie (you can find it on CPAN - it can be tricky to install).
Zabbix is expecting the username to be stored in
. The problem is that AuthenNTLM stores it as REMOTE_USER
. So every time the page would load, it listed me as Guest in the footer, and said I didn't have permissions.
To fix this, I simply added this to index.php just under the opening PHP tag:
It might be nice to have this documented for future users. And add a config option for user name mapping. You never know what some Perl programmer is going to store the user name as 
I think it would also be good to add some information/warnings/recommendations regarding LDAP (and internal) authentication: Recommend https, point out that the server is exposing the password...clear text...to the application (and anybody who has access to modify it), etc.
My setup: Debian (Squeeze/Main) / Zabbix 1.6.4 / Apache2
My Zabbix server lives in a huge AD forest. Due to IT Security Policies, using the built-in LDAP authentication is not an option. For anybody asking why, just do one of the following in index.php (before the footer) and you'll see why IT might have a problem:
PHP Code:
echo $_SERVER['PHP_AUTH_PW'];
PHP Code:
echo $_REQUEST['password'];
Zabbix is expecting the username to be stored in
PHP Code:
$_SERVER['PHP_AUTH_USER']
PHP Code:
$_SERVER['REMOTE_USER']
To fix this, I simply added this to index.php just under the opening PHP tag:
PHP Code:
$_SERVER['PHP_AUTH_USER'] = $_SERVER['REMOTE_USER'];
I think it would also be good to add some information/warnings/recommendations regarding LDAP (and internal) authentication: Recommend https, point out that the server is exposing the password...clear text...to the application (and anybody who has access to modify it), etc.