Could I provide more detail to assist working through this problem? On Wed, Apr 14, 2010 at 05:46:19PM -0700, Tony Hunter wrote: > 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 _______________________________________________ Opsview-users mailing list Opsview-users@lists.opsview.org http://lists.opsview.org/lists/listinfo/opsview-users
