Never ever use an administrators account for LDAP binding
Category Quickr
Bookmark :
Today I had a rather stressfull afternoon. One of my clients managers was travelling abroad to do a Quickr demo for a european audience. The demo would start a 6 PM. However, as of 1.30 PM users starting calling that they could not login to Quickr anymore. Users were sure that they entered the correct credentials but after the login were presented the same login window again and again. Administrators were also unable to login. After some initial troubleshooting we found out that the credentials were indeed correct, after the login we could change the url to f.i. names.nsf or log.nsf and it would open just fine.
In domlog.nsf we discovered that every try to open main.nsf in any place resulted in an error in domlog (not in log.nsf) 404 NOT FOUND (Server could not find the given resource). Unfortunately there was no indication of which resource....
So, we tried about everything, qptool refresh, repair, unregister, register, reboot, restore of backup. But nothing helped.
So, since the Quickr server was configured to use a Domino directory on a second server using LDAP we decided to also reboot that server. Again no luck. But fortunately I had a remote console open to the second server and there it was: LDAP bind errors due to invalid credentials....
It turned out that an administrator had set-up the Quickr LDAP configuration using his own account for LDAP binding. Today a new Notes policy was pushed to the administrator which also synchronized his Notes password with his HTTP password.
Since we could also not log in to the Quickr site administration we had to add a form to admin.nsf and add two fields to show the LDAP bind credentials. After changing them to a proper LDAP account everything ran smoothly again. Just an hour before the demo
Bookmark :
Today I had a rather stressfull afternoon. One of my clients managers was travelling abroad to do a Quickr demo for a european audience. The demo would start a 6 PM. However, as of 1.30 PM users starting calling that they could not login to Quickr anymore. Users were sure that they entered the correct credentials but after the login were presented the same login window again and again. Administrators were also unable to login. After some initial troubleshooting we found out that the credentials were indeed correct, after the login we could change the url to f.i. names.nsf or log.nsf and it would open just fine.
In domlog.nsf we discovered that every try to open main.nsf in any place resulted in an error in domlog (not in log.nsf) 404 NOT FOUND (Server could not find the given resource). Unfortunately there was no indication of which resource....
So, we tried about everything, qptool refresh, repair, unregister, register, reboot, restore of backup. But nothing helped.
So, since the Quickr server was configured to use a Domino directory on a second server using LDAP we decided to also reboot that server. Again no luck. But fortunately I had a remote console open to the second server and there it was: LDAP bind errors due to invalid credentials....
It turned out that an administrator had set-up the Quickr LDAP configuration using his own account for LDAP binding. Today a new Notes policy was pushed to the administrator which also synchronized his Notes password with his HTTP password.
Since we could also not log in to the Quickr site administration we had to add a form to admin.nsf and add two fields to show the LDAP bind credentials. After changing them to a proper LDAP account everything ran smoothly again. Just an hour before the demo

- 


Comments
{ Link }
Posted by Lars Berntrop-Bos At 14:03:17 On 26-03-2009 | - Website - |