Page 1 of 2

check_ldap fails from inside Nagios

Posted: Fri Jul 01, 2016 12:22 pm
by highness
Here is an interesting one...

I can run check_ldap or check_ldaps from the command line and the check works without a hitch:

Code: Select all

[email protected] (Linux) $ /usr/local/nagios/libexec/check_ldaps -H ldap0001.example.com -p 636 -b "dc=example,dc=com" -D "uid=nagios_monitor,ou=privls,dc=example,dc=com" -P "supersecretpasswordgoeshere" -3
LDAP OK - 0.027 seconds response time|time=0.026954s;;;0.000000
I can run that same check from CCM under that particular service (Test Check Command) and it runs fine as well.

When I have Nagios run it (as a normally scheduled check), it fails with "Cannot bind to server"

Any ideas where to start to fix this?

Re: check_ldap fails from inside Nagios

Posted: Sun Jul 03, 2016 11:53 pm
by Box293
What happens when you execute the command as the nagios user:

Code: Select all

su nagios
/usr/local/nagios/libexec/check_ldaps -H ldap0001.example.com -p 636 -b "dc=example,dc=com" -D "uid=nagios_monitor,ou=privls,dc=example,dc=com" -P "supersecretpasswordgoeshere" -3
You may need to define some environment variables:
https://support.nagios.com/kb/article.php?id=489

Re: check_ldap fails from inside Nagios

Posted: Tue Jul 05, 2016 10:52 am
by highness
When I su over to nags and run that command, it returns fine:

Code: Select all

/usr/local/nagios/libexec/check_ldaps -H ldap0001.example.com -p 636 -b "dc=example,dc=com" -D "uid=nagios_monitor,ou=privls,dc=example,dc=com" -P "supersecretpasswordgoeshere" -3
LDAP OK - 0.039 seconds response time|time=0.039407s;;;0.000000

Re: check_ldap fails from inside Nagios

Posted: Tue Jul 05, 2016 2:07 pm
by ssax
99.9% of the time it's because of special characters in the password, do you have special characters in your password?

If so, try setting up a user variable and see if that resolves the issue:
- Note: You can't use the test check button in the CCM, apply config and force a check to test.

Code: Select all

https://assets.nagios.com/downloads/nagiosxi/docs/Understanding-User-Macros.pdf
I don't see anything else that would cause issues unless Box293 is right about some envar/path missing when running as the nagios user with no TTY.

Re: check_ldap fails from inside Nagios

Posted: Tue Jul 05, 2016 2:10 pm
by bwallace
By any chance is the remote system a Solaris box?
https://docs.oracle.com/cd/E18752_01/ht ... ems-3.html

Re: check_ldap fails from inside Nagios

Posted: Tue Jul 05, 2016 3:01 pm
by highness
ssax wrote:99.9% of the time it's because of special characters in the password, do you have special characters in your password?

If so, try setting up a user variable and see if that resolves the issue:
- Note: You can't use the test check button in the CCM, apply config and force a check to test.

Code: Select all

https://assets.nagios.com/downloads/nagiosxi/docs/Understanding-User-Macros.pdf
I don't see anything else that would cause issues unless Box293 is right about some envar/path missing when running as the nagios user with no TTY.
The password has no special characters at all. Strictly upper-case and numbers.

Re: check_ldap fails from inside Nagios

Posted: Tue Jul 05, 2016 3:03 pm
by highness
bwallace wrote:By any chance is the remote system a Solaris box?
https://docs.oracle.com/cd/E18752_01/ht ... ems-3.html
Nope - it's RHEL 7

Re: check_ldap fails from inside Nagios

Posted: Tue Jul 05, 2016 4:05 pm
by ssax
Hmm, this is a head scratcher, add the -v option on the end of it for verbose and see if it gives any additional information after applying config.

Re: check_ldap fails from inside Nagios

Posted: Wed Jul 06, 2016 10:41 am
by highness
ssax wrote:Hmm, this is a head scratcher, add the -v option on the end of it for verbose and see if it gives any additional information after applying config.
Added the -v to the check, but no discernible information was returned. It still returns "Could not bind to the LDAP server".

Re: check_ldap fails from inside Nagios

Posted: Wed Jul 06, 2016 1:02 pm
by rkennedy
Can you show us the service definition and check_command you're using in conjunction with it as well? There might be something in the configs we've over looked at this point.