328214 - LDAP search fails though replication sort-of works

Status: RESOLVED INVALID

(Thunderbird :: Address Book, defect)

Description

[Kyle Sluder]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Thunderbird 1.5 (20051201)

I have tried for days to add my university's LDAP server to the address book, but while it gets added and configured as Thunderbird's global LDAP server, searching  for any name always returns 0 results.  I have confirmed that my connection settings are correct as they work in two independent LDAP browsers and KMail/KAddressBook, but fail on both WinXP and Linux.  What's strange is that if I perform a "replicate", it seems to actually process all of the entries on the LDAP server (it takes a few seconds and gets into the thousands) but nothing actually results from this operation.  This leads me to believe that Thunderbird is actually connecting successfully, and the problem lies elsewhere in the LDAP integration.

Reproducible: Always

Steps to Reproduce:
1. Add new LDAP server to address book.
2. Search for my own name.

Actual Results:  
No results found.

Expected Results:  
My entry to appear.

Connection properties:

Name: Loyola LDAP
Hostname: XXXXXXXXX.loyola.edu
Base DN: o=LOYOLA
Port Number: 389
Bind DN: (blank)

Comment 1

[Mark Banner (:standard8)]

Reporter, we now have the facility for logging how Thunderbird is communicating with the ldap server and what transactions are taking place - see the link below.

Once you have done that, please report back here either way so that we can close the bug or try and resolve your problem.

Many Thanks

http://wiki.mozilla.org/MailNews:LDAP_Address_Books#LDAP_Logging

Comment 2

[Kyle Sluder]

Fixed in 2.0 Alpha.  Could not get console output from Thunderbird to post LDAP transaction, but successfully searched for my name.

However, having trouble searching for faculty members, but I think I might be specifying the wrong Base DN.  If I confirm it to be a problem in TB, I will reopen (hopefully with an attached log of the LDAP transaction(s) from Linux).

Comment 3

[Mark Banner (:standard8)]

Changing Resolution to Works for Me as we don't actually know which bug/patch fixed the problem.

Comment 4

[Kyle Sluder]

Did the schema change?  I remember reading a bug about the Mozilla schema not meshing with Novell eDirectory (which is what we use).  I can't seem to find the bug now, but I would check there first.

Comment 5

[Mark Banner (:standard8)]

(In reply to comment #4)
> Did the schema change?  I remember reading a bug about the Mozilla schema not
> meshing with Novell eDirectory (which is what we use).  I can't seem to find
> the bug now, but I would check there first.
> 

Yes it did between 1.0 and 1.5. Since the first 1.5 release there has been one minor change for displayName, but apart from that it hasn't changed since 1.5.

The current schema is at:

http://wiki.mozilla.org/MailNews:LDAP_Address_Books#LDAP_Address_Book_Schema_-_Alpha_Version

If the schema isn't compatible, you can re-map the preferences starting with "ldap_2.servers.default.attrmap." to set the values you require. However, please also comment on http://wiki.mozilla.org/MailNews_Talk:LDAP_Address_Books so we know about the differences (it can always be migrated to a bug later).

Thanks

Comment 6

[Kyle Sluder]

Alright, turns out it was functional in the 1.5 address book.  Here's what's up:

- Installed 2.0 alpha.  LDAP lookup functional in Address Book.  Can't remember for sure if it worked in autocomplete but I think it did.
- Uninstalled 2.0 alpha and 1.5.0.2, reinstalled 1.5.0.2.  Created new, blank profile, configured IMAP and LDAP information.  Turned LDAP lookup on for autcomplete.  LDAP lookup functional in Address Book, not in autocomplete.

So autocomplete is broken.  I think that makes this a dup.

Also, our eDirectory is screwed up.  The CN is single-valued and only contains the user's login name (for example, my CN is kmsluder instead of kmsluder, Kyle Sluder).  There is no displayname in our directory.  Grr.

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> Alright, turns out it was functional in the 1.5 address book.  Here's what's
> up:
> - Installed 2.0 alpha.  LDAP lookup functional in Address Book.  Can't remember
> for sure if it worked in autocomplete but I think it did.
> - Uninstalled 2.0 alpha and 1.5.0.2, reinstalled 1.5.0.2.  Created new, blank
> profile, configured IMAP and LDAP information.  Turned LDAP lookup on for
> autcomplete.  LDAP lookup functional in Address Book, not in autocomplete.
> So autocomplete is broken.  I think that makes this a dup.

If its the problem I think it is causing it, then that was fixed by bug 317566.

> Also, our eDirectory is screwed up.  The CN is single-valued and only contains
> the user's login name (for example, my CN is kmsluder instead of kmsluder, Kyle
> Sluder).  There is no displayname in our directory.  Grr.

It should still work without a displayname, though obviously that field will be blank. You can customise what is displayed in the list under the view menu.

I'm not sure I understand the problem with CN being single valued, as I though Thunderbird just needed a value, but I'm probably wrong. If you think its a bug, could you file a bug under the "Core" Product and the "MailNews: LDAP Integration" Component so that we can discuss if a fix is needed. Thanks.

Comment 8

[Kyle Sluder]

Well, I've found the reason I filed this bug.  Nobody's full name is contained in the LDAP directory.  They're split up into givenname and sn, so searching for "Kyle Sluder" returns no results!  Searching for either my first or last name brings up my entry.

Couple that with Bug #124078 (no indication Thunderbird is actually performing a search) and a painfully slow, obviously broken LAN connection prior to my moving across campus last week, and you have me thinking Thunderbird is not obtaining any results.

So this "bug" is really a combination of three bugs:
Bug #317566 - Autosearch is broken
Bug #124078 - No idea Thunderbird is doing what I told it to
Bug #000000 - PEBKAC :)

Thanks a lot for the guidance, hopefully TB 2.0 gives a less frustrating LDAP experience.

Comment 9

[Kyle Sluder]

Marking bug as invalid.