A Lotus Admin Tale

First, because I know nothing about LDAP (let alone why AD is so different than a "real" LDAP directory), I had to get the LDIFDE app and extract a record (my own) from our AD.  There are directions on LDIFDE all over the Internet and it was relatively easy to figure out, even for LDAP-challenged admins like me.

Using the info from the resultant LDIF file, I got the DN (i.e., "CN=Firstname Lastname,OU=Users,OU=Department,OU=Location,DC=Company,DC=com&quot that I needed to use in order to pass credentials to the AD.  This is what LDAPSEARCH uses to validate with the AD before the AD is allowed to give up any info.  Note that the AD will not accept anonymous credentials.

ldapsearch -h server.domain -D "CN=Firstname Lastname,OU=Users,OU=Department,OU=Location,DC=Company,DC=com" -w password -b "DC=Company,DC=com" CN="full name"

(The full name at the end is actually the search criteria: this LDAPSEARCH will return all the record data for this person, computer, or group, if it exists.  This is a good test to see if LDAP communications are working OK with your AD.  This is all groundwork to getting the Quickr server working via a modified qpconfig.xml file.

Be careful with this because when I first searched for my own user record I got my computer name.  This means that if I try to log into Quickr using LDAP, I can't use my shortname because it actually finds my PC first.  I guess this is a good reason to name PC's and users differently.)

Anyway, here's the output you should see from the LDAPSEARCH:

CN=Full Name,OU=Users,OU=Dept.,OU=Loc,DC=Company,DC=com
objectClass=top
objectClass=person
objectClass=organizationalPerson

et cetera...

The important fields to pull out from this are:

• dn
• cn
• displayName
• givenName
• mail
• name
• sAMAccountName
• sn

The above list is what you'll need to reference in order to get your QPCONFIG.XML file tweaked for using LDAP to authenticate against your AD.

 So I'm trying to get Quickr going on our Domino 8 test server which is running on a directory managed by Microsoft's ActiveDirectory.

Since AD is not a "standard" LDAP incarnation, getting to it has been tricky.

Using the LDAPSEARCH command line tool bundled with Notes, as well as Softerra's nice LDAP Browser, I finally got it to work with a lot of help from a few different people, including someone from Lotus as well as our Microsoft consultant guy.

I will post the specifics later.  Right now, I want to go see if Quickr works.