ldap check fails

[stebbo]

Hi All,

I have a very weird problem with the check_ldap command. A while ago we migrated our main Active Directory Domain Controller to a new machine and made it the primary domain controller. Since then, my check_ldap command fails whenever the old domain controller is not available. Yes, I have changed the IP address I'm using to check.

Here's my check command which I'm running from the command line.

Code: Select all

./check_ldap -H 10.174.64.31 -b "DC=curric,DC=lilydale-hs,DC=wan" -D "CN=ldapbind,DC=curric,DC=lilydale-hs,DC=wan" -P "xxxxxx"

If the old domain controller is offline, the above command fails with the error CRITICAL - Socket timeout after 10 seconds.
If the old domain controller is running, the above check works, even though the .31 ip address is the ip address of the new controller.

Added to the strangeness, I downloaded the LDAPExplorerTool2 from sourceforge, and that works quite ok with the above details when the original domain controller is offline.

Any ideas?

Cheers,
Chris.

[sreinhardt]

Is ldapbind or curric one of your server names? Have you tried with the -v flag to see if your pdc is redirecting you to the alternative server?

[stebbo]

Hi sreinhardt,

thanks for the response. I tried -v but the check_ldap command doesn't seem to recognise it - it's not in it's argument list and it doesn't do anything.

Our forrest is curric.lilydale-hs.wan and the ldapbind is a user we have authorised to respond to ldap requests. The strangest thing about all this is that this is the same command which worked fine before we moved our pdc, and still works as long as the OLD pdc (no longer the primary either) is running. It must be that the new pdc is handing it off, but I'm not sure why or how.

Cheers,
Chris.

[sreinhardt]

Thats interesting, if you run check_ldap -h it definitely specifies it as an option.

Code: Select all

./check_ldap -h                                                                                              
check_ldap v1991 (nagios-plugins 1.4.13)
Copyright (c) 1999 Didi Rieder ([email protected])
Copyright (c) 2000-2008 Nagios Plugin Development Team
        <[email protected]>



Usage: check_ldap -H <host> -b <base_dn> [-p <port>] [-a <attr>] [-D <binddn>]
       [-P <password>] [-w <warn_time>] [-c <crit_time>] [-t timeout]
       [-2|-3] [-4|-6]

Options:
 -h, --help
    Print detailed help screen
 -V, --version
    Print version information
 -H, --hostname=ADDRESS
    Host name, IP Address, or unix socket (must be an absolute path)
 -p, --port=INTEGER
    Port number (default: 389)
 -4, --use-ipv4
    Use IPv4 connection
 -6, --use-ipv6
    Use IPv6 connection
 -a [--attr]
    ldap attribute to search (default: "(objectclass=*)"
 -b [--base]
    ldap base (eg. ou=my unit, o=my org, c=at
 -D [--bind]
    ldap bind DN (if required)
 -P [--pass]
    ldap password (if required)
 -T [--starttls]
    use starttls mechanism introduced in protocol version 3
 -S [--ssl]
    use ldaps (ldap v2 ssl method). this also sets the default port to 636
 -2 [--ver2]
    use ldap protocol version 2
 -3 [--ver3]
    use ldap protocol version 3
    (default protocol version: 2)
 -w, --warning=DOUBLE
    Response time to result in warning status (seconds)
 -c, --critical=DOUBLE
    Response time to result in critical status (seconds)
 -t, --timeout=INTEGER
    Seconds before connection times out (default: 10)
 -v, --verbose
    Show details for command-line debugging (Nagios may truncate output)

Notes:
 If this plugin is called via 'check_ldaps', method 'STARTTLS' will be
 implied (using default port 389) unless --port=636 is specified. In that case
 'SSL on connect' will be used no matter how the plugin was called.
 This detection is deprecated, please use 'check_ldap' with the '--starttls' or '--ssl' flags
 to define the behaviour explicitly instead.

I would agree that either the pdc is handing it off or nagios has a static ip set in /etc/hosts for the domain. Could you verify that is not the case? Also maybe do an "nslookup curric.lilydale-hs.wan" and verify it returns with the IP of your new server.

[stebbo]

Hi sreinhardt,

thanks for the response. Interestingly, nslookup curric.lilydale-hs.wan returns the IP address of the OLD server. I shall look into getting this sorted as I suppose it should point to the new server.

However, I thought the -H option (which points to the IP address of the new server) directed the ldap query to that particular host but I gather that's not the case?

Cheers,
Chris.

[sreinhardt]

I would agree that this should be expected behavior, however I can definitely say there are a handful of plugins that ignore it if other settings are used. I can only guess at this point that that is the case, per your finding of the name resolution issue.

[stebbo]

Hi All,

I thought I should respond and let you know that the problem has been resolved. It seems the error was a bit more basic than all that - a typo in the /etc/resolv.conf file meant that the system was never looking at the new server for DNS and so the DNS check was timing out.

I'm not sure why the check_ldap command should need to check DNS entries when the host was given as an ip address, but there you go. Once I fixed the typo, everything appears to be working fine.

Thanks sreinhardt for your assistance.

Cheers,
Chris.