Univention Bugzilla – Bug 34787
libnss-ldap connection problems
Last modified: 2020-07-03 20:53:56 CEST
libnss-ldap.conf is not readable by normal users. But nss-ldap could be triggered by normal users. It this case the config option nssldap/nss_srv is not readable by the user. We should change the code that the srv record usage must be explicit enabled. +++ This bug was initially created as a clone of Bug #33292 +++ Seen at ticket #2013011421000766: Sometimes the customer sees error messages in the auth.log at memberservers: " nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server Nov 6 16:17:40 servername ls: nss_ldap: failed to bind to LDAP server ldap://servername:389: Can't contact LDAP server " This is repeated for every ldap server registered in ldap-srv record. The only case in which this record is used is located at "ldap-nss.c" if the ldap config could not be parsed - we've tested that and there is no obvious explanation for that. The config is readable and okay. With strace and wireshark I saw that the connections are only hitting one server - the first in the ldap config. I also saw that this system uses an ip adress from an external range (duplicated) - perhaps thats the point if sometimes the name resolution is done externally? In wireshark you can see a tcp rst when this phenomenon starts. Afterwards even if auth.log sais that connection against all other ldap servers fails I cannot see connection tries in wireshark...perhaps wrong debugging. After all systems from the srv record are "tried" everything works again like expected. strace, logs and tcpdump can be obtained from otrs - not attaching them here due to customer related information.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
There is a Customer ID set so I set the flag "Enterprise Customer affected".
Still a problem in 4.2, but as long as nscd runs everything is fine. apache basic auth (used by nagios) breaks for example if nscd is stopped. Because nscd is only a cache, I would expect everything working the same if it is stopped. Since nscd is probably running on most installation, I set the "Who is affected" flag to 1.
(In reply to Jürn Brodersen from comment #3) > Still a problem in 4.2, but as long as nscd runs everything is fine. > > apache basic auth (used by nagios) breaks for example if nscd is stopped. > > Because nscd is only a cache, I would expect everything working the same if > it is stopped. FYI: Things work when `nscd` runs as it rungs as user 'root', has permissions to read '/etc/libnss-ldap.secret' and can thus query the LDAP server, which required authentication. When `nscd` does *not* run, any process not run by 'root' will fail to get the same information from LDAP.
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.