We're running into a similar issue as discussed on this list, but never apparently resolved, as far as I can see. I refer to this thread: http://lists.opsview.org/lurker/message/20091011.234431.8232c3e8.en.html
We are using the 3.5.2 community edition rpms on a CentOS 5.4 box. We have no groups defined at /usr/local/nagios/etc/ldap We are able to authenticate to our ldap server successfully in testing from the command line: # /usr/local/nagios/bin/opsview_sync_ldap -t -u systest -p secretpass Able to connect to LDAP successfully Checking username systest Found user systest Checking password for systest Password successful While running the command above, I concurrently captured the request with tcpdump on the LDAP server. Here's a breakdown of the dialog btw. opsview and the ldap server during the successful command line test above. 1. opsview sends an ldap bindRequest using the binddn and bindpw values from /usr/local/opsview-web/opsview_web_local.yml. ldap server sends ACK and the bind response (success). 2. opsview sends another ldap bindRequest using the binddn and bindpw values from opsview_web_local.yml. ldap server sends ACK and the bind response (success). 3. opsview sends an ldap searchRequest for uid 'systest' against the whole subtree at user_basedn as defined in opsview_web_local.yml. ldap server sends an ldap searchResEntry with all the data it has on uid 'systest' and follows that with an ldap searchResDone (success). 4. opsview server sends an ldap unbindRequest. ldap server sends FIN, ACK. 5. opsview sends an ldap bindRequest comprised of uid=systest, the user_basedn as defined in opsview_web_local.yml and the password as supplied at the cli above. ldap server sends ACK and the bind response (success). Here's the breakdown of the unsuccessful login attempt for the same user (systest) at the web interface. By the way, we are using apache as a proxy for the performance improvement, if that makes a difference. 1. opsview sends an ldap bindRequest using the binddn and bindpw values from /usr/local/opsview-web/opsview_web_local.yml. ldap server sends ACK and the bind response (success). 2. opsview sends an ldap searchRequest for uid 'systest' against the whole subtree at user_basedn as defined in opsview_web_local.yml. ldap server sends an ldap searchResEntry with all the data it has on uid 'systest' and follows that with an ldap searchResDone (success). 3. opsview server sends an ldap unbindRequest. ldap server sends FIN, ACK. 4. opsview sends an ldap bindRequest comprised of uid=systest, the user_basedn and the bindpw (instead of the password supplied for the user systest to opsview at the login screen). ldap server sends ACK and the bind response (invalidCredentials). After testing some other ldap contacts, I find that when authenticating via the web interface, opsview sends the 'bindpw' as defined in /usr/local/opsview-web/opsview_web_local.yml as the password credential for every contact configured in the ldap realm. If anyone has an idea how we might go about correcting this, it would be much appreciated. -- Best regards, Tony Hunter Systems Admin. Uniserve Communications Corp. http://www.uniserve.com _______________________________________________ Opsview-users mailing list [email protected] http://lists.opsview.org/lists/listinfo/opsview-users
