Problem with LDAPS

Hello,

I have spent a day trying to figure out what is going on with icinga - ldaps connection, but no luck.
icingaweb2 - 2.7.3
Centos 7.5

resoruces.ini
[ldap]
type = “ldap”
hostname = “dc.example.com
port = “636”
root_dn = “OU=xxx,DC=xxx,DC=com”
bind_dn = “CN=Icinga Service User,OU=Service Accounts,OU=xxx,DC=xxx,DC=com”
bind_pw = “xxx”
timeout = “15”
encryption = “ldaps”

The thing is that it works sometimes and sometimes not. When I click on “validate configuration” on a ldap resource screen for example, sometimes it binds on ldaps and in most of the cases it doesn’t.

The error message isn’t very descriptive (one found in icingaweb2.log configured to “DEBUG”).

2020-02-03T20:40:28+01:00 - DEBUG - Connect using LDAPS
2020-02-03T20:40:28+01:00 - DEBUG - NOTE: There might be an issue with the chosen encryption. Ensure that the LDAP-Server supports LDAPS and that the LDAP-Client is configured to accept its certificate.
2020-02-03T20:40:28+01:00 - ERROR - LDAP bind (CN=Icinga Service User,OU=Service Accounts,OU=xxx,DC=xxx,DC=com / ***) to ldaps://dc.xxx.com:636 failed: Can’t contact LDAP server

I even tried to capture network activity during both events (I used wireshark). When the event fails, it complains about “untrusted CA”. It is true, however, I have TLS_REQCERT never in openldap.conf, and it seems that icinga completely ignores that file. Permissions should be ok on /etc/openldap folder, they centos vanila.

It almost look like the it looks at two different configuration files at a time. There was a “ldapsearch” syntax that was generated during successful ldaps bind (in icingaweb2.log file), and when if I repeat the same one multiple times from cli, it works without problem.

My LDAPS server is a Domain Controller which is completely functional. I even tried to use different/test DC to verify ldaps bind, and it behave the same. Maybe I’m overlooking something, I don’t know.

Please, can someone give me a hint?

Thanks!

1 Like

Hi,

It figured out, I deleted entries from here:
/var/opt/rh/rh-php71/lib/php/session/

And I restarted php service:
systemctl restart rh-php71-php-fpm

Works now.

1 Like

Hi Bojan,
I just wanted to point out that I’ve had the same problem and your solution did the trick for me as well.
What also puzzled me was the fact that the validation of the resource worked every 2nd or 3rd try.
Thanks a lot for posting your solution!