The Quickr Blog

This one caused some head-scratching last week, so I thought others might benefit from the solution.

I had a Lotus Quickr 8.0 install on Domino 7.0.2 at a customer site that was giving some unusual symptoms when adding users as place members from LDAP.  Although the lookup of the users in the address book was working well, and the user name was displayed correctly on the confirmation screen, when the updated list of place members was shown any new members were displayed as "FIELDTITLE_UNTITLED", e.g.



[The screenshot shows a customised place, but the same issue was occurring for any place type, including the default Quickr ones.]

I checked the LDAP settings, Directory Assistance and qpconfig.xml, but none seemed to suggest a major misconfiguration.  To cut a long story short, the issue was to do with the Quickr server using Anonymous lookups against a Domino 7.0.2 LDAP server (a different system to the Quickr server).  

Although using an authenticated LDAP bind is optional in Quickr 8.x, you need to ensure that all the required LDAP attributes are available if you use an anonymous bind.  In this customer's case, the attributes that were being supplied via the anonymous bind differed for the two directories being exported via the Domino LDAP using Directory Assistance.  Whilst adding users from the External.NSF directory seemed to be working fine, adding them from the Names.NSF directory caused the FIELDTITLE_UNTITLED error.  Looking more closely using Softerra LDAP Administrator (see below) I could see that whilst entries from Names.NSF were correctly called, say "cn=Stuart McIntyre,ou=IT,o=MyCompany" (the DN attribute), there wasn't actually an LDAP attribute called CN being supplied.  That meant that when Quickr tried to populate the member table as shown above it didn't have the user's common name to display.

Changing the Quickr LDAP configuration to use authenticated bind and restarting the server has resolved the issue just fine.  Alternatively I could have edited the attributes being supplied by the LDAP service to anonymous users, but I believe that using authenticated bind is the better practice.

---

As an aside, I would really struggle to diagnose such issues without using Softerra's LDAP Adminstrator or LDAP Browser tools - they are fabulous LDAP editor and lookup utilities.  Whilst Domino/Notes have the built-in command line LDAPSEARCH tool, it just doesn't come close in resolving tricky issues.  However, I have a couple of major issues with the Softerra applications:

1. They are Windows only, and as yet I haven't found a good substitute for the Mac.  I've tried LDAPper (too simplistic) and LDAP Manager (too unstable) - any suggestions?
2. Whilst LDAP Browser is free (yay!), LDAP Administrator (needed for edits to the LDAP directory - e.g. uploading images to jpegPhoto attributes) is just too darned expensive ($250 for a single user license).  Whilst I value the utility very highly, I simply cannot justify spending such a large amount for an admin tool.  A figure of $40-50 would make it a no-brainer for me.

Comments