Nagios Support Forum

Hi folks,

I encounter a really strange problem since a cuple of days on my Nagios XI server regarding LDAP and LDAPS authentication. Everything was running pretty smooth since months and all of a sudden, LDAP and LDAPS authentication stopped working correctly. After investigating about the issue, we found out with a tcpdump that our Nagios XI server is trying to reach an old Microsoft AD server which is decomissioned before trying to contact the right one. That AD server was disconnected way before that issue started. All of the configured users are using the right configuration.

I tried different things like updating or deleting then re-creating the Admin > LDAP / Active Directory Integration entry but none as well as recreating the users and none of them are working. It is like Nagios XI was not getting the new LDAP config for an obscure reason. Has anyone ever experienced that kind of behaviour? Is there any cache that could retain the old configuration? I really don't get it as everything was working fine before and nobody in the small group of admins in my organization has changed something.

FYI, our Nagios XI setup is the following

Nagios XI 2024R1
Running on Azure
Operating System: Oracle Linux Server 8.9
Kernel: Linux 5.4.17-2136.326.6.el8uek.x86_64
Architecture: x86-64

Regards,

Philippe

I also tried to disable LDAP authentification in one of the account's settings page and instead use the local authentication and still can see with tcpdump that Nagios is trying to reach the old LDAP server for about 2 minutes before contacting the right one.

I also rebooted the httpd, nagios and php-fpm services but without luck... Is there any script that could repair my Nagios installation? I would really like not to have to restore an old backup.

Regards,

Philippe

Hi Philippe, thanks for reaching out.

Looking through the related code, I don't think there are any caches in the application that could be stale - for any given user that logs in, if LDAP/AD authentication is enabled, the code will check for an ID into an array of servers and connect based on whatever information is in that array. Neither the user lookup nor the server lookup use a cache, and the list of servers is using the same function that is used in Admin->Users->AD/LDAP Integration.

Normally, I would have listed out a few of the troubleshooting steps and then asked you to start a case if that didn't get anywhere. In the interest of helping you eliminate some possibilities, here's a code snippet that will list out your servers directly from the database: If you do see your old AD server in that list, then it just wasn't deleted properly.

If you don't see it, here are some other possibilities:
1. Is there an out-of-application cache that could be invalid? For instance, if your new AD server had the same hostname as the old one, I'd be checking /etc/hosts as well as your DNS server. You've probably tried it already, but I would also try to make a TCP connection manually from your XI server's terminal to the new AD host.
2. Was your XI server ever monitoring the old AD server? If it was or is, your tcpdump output could be from the monitoring engine trying to connect through a service check. I would double-check that the tcpdump messages correspond to the times that the affected users are trying to log in. That could explain the consistent two-minute delay you're seeing and would imply that we're looking in the wrong place for a solution.

Hopefully that helps you at least a little bit - if you're still having issues, I think your best bet is to open a case on Answer Hub, so that our Support team can help you troubleshoot in more depth.

Regards,
Sebastian

Hello Sebastian,

Thanks for your reply, I greatly appreciate your help!

I ran the mysql command and the two entries in the returned array correspond exactly to what we see in the Admin > Users > LDAP/AD Integration page.

For the other possibilities, new AD server doesn't have the same name as the old one. As you guessed, I already checked DNS and it is resolving without any problem. I also tried to bypass DNS with /etc/hosts file and even try to trick the system by mapping the IP of the new AD server with the name of the old AD and it doesn't change anything at all. And for my tcpdump, I filtered it with only LDAP and LDAPS ports and the timestamps matches the different times I tried to log in.

Now, the only thing left to do is to open a ticket on answer hub.

Regards,

Philippe

For the benefit of all, there was an LDAP extension under Admin > System Extension > Management Components that was enabled for some unkown reason. After disabling it, LDAP and LDAPS authentication work again.