Closed Bug 426337 Opened 16 years ago Closed 16 years ago

LDAP replication failed talking to exchange server

Categories

(Thunderbird :: Address Book, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 316170

People

(Reporter: mos33fr, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: 2.0.0.12 (20080213)

I set up my TB to get addresses from my company exchange server.
Retrieving email from the contact pane or the address book is ok (though slow), but I can't download the book for offline use

Following http://wiki.mozilla.org/MailNews:LDAP_Address_Books#LDAP_Logging I logged the requests, but does not tell me much:

0[274918]: nsLDAPOperation::SimpleBind(): called; bindName = ''; 
3376[2fdd8a8]: nsLDAPConnection::Run() entered
0[274918]: pending operation added; total pending operations now = 1
0[274918]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=xxxx,dc=xxxxx,dc=com'; aFilter = '(objectclass=*)', aAttrCounts = 0, aSizeLimit = 0
0[274918]: pending operation added; total pending operations now = 2
3376[2fdd8a8]: pending operation removed; total pending operations now = 1
3376[2fdd8a8]: pending operation removed; total pending operations now = 0
3376[2fdd8a8]: unbinding
3376[2fdd8a8]: unbound



Reproducible: Always

Steps to Reproduce:
1.Click download button from the "off line" tab of the server property window
2.Failure message is nearly immediate
Version: unspecified → 2.0
Confirmed on 2.0.0.12 (gentoo linux)!

The problem seems to be that bindDN is empty ('') when running "Download now"
----------------------------------------------------------------------------
-1386075248[8f8a1e0]: nsLDAPConnection::Run() entered
-1222007088[805c548]: nsLDAPOperation::SimpleBind(): called; bindName = ''; 
-1222007088[805c548]: pending operation added; total pending operations now = 1
-1222007088[805c548]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=domain,dc=net'; aFilter = '(objectclass=*)', aAttrCounts = 0, aSizeLimit = 0
-1222007088[805c548]: pending operation added; total pending operations now = 2
-1386075248[8f8a1e0]: pending operation removed; total pending operations now = 1
-1386075248[8f8a1e0]: pending operation removed; total pending operations now = 0
-1386075248[8f8a1e0]: unbinding
-1386075248[8f8a1e0]: unbound
----------------------------------------------------------------------------

It works when searching the LDAP address book and when auto-completing
addresses in To:, CC:, ... fields, because in this case bindDN is passed
as specified for the ldap server.
Axel, your problem is definitely bug 316170, this is already fixed for the next major release of Thunderbird (3.x).

mos, I think your problem is also the same as bug 316170 from your description. Therefore I'll mark this bug as a duplicate of that one. If you feel it isn't (like you aren't using a bind dn) please feel free to reopen, but please provide some more details as to your settings.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Well, I'm not the reporter. I've just confirmed mos' bug report.
So -- of course -- I think that mos and I are experiencing the same bug.

Regarding the DN field. Yes it's set to "domain\user" and it is
correctly passed when searching from address book, i. e. TB
asks for a password.

Actually -- after reading through bug 31670 -- I neither think
that it's the same bug nor do I understand why it can't be fixed
in TB 2.X.

The LDAP debug output almost looks identical (same functions used)
with the only difference that the "Bind DN" field contents are simply
ignored when doing "Download now".

Though I have to admit that I haven't read the code and therefore
do not know, if it is as easy to fix as it looks.  
(In reply to comment #3)
> Regarding the DN field. Yes it's set to "domain\user" and it is
> correctly passed when searching from address book, i. e. TB
> asks for a password.
> 
> Actually -- after reading through bug 31670 -- I neither think
> that it's the same bug nor do I understand why it can't be fixed
> in TB 2.X.

See bug 316170 comment 0: "we're passing null as our bind dn.". This is your problem here - the dn is obviously empty (which is the equivalent of null).

> Though I have to admit that I haven't read the code and therefore
> do not know, if it is as easy to fix as it looks.  

The problem with the 2.x code is that it doesn't have the bind dn in the right place at the right time, and it isn't easy to get it there without too many changes. The changes required to do this would probably require interface changes which we don't do on branch (branch = 2.x) because we would break extensions) and branch is restricted to security or crash fixes.
Uhu, this is some deeply nested code ...
I see what you mean and I'm beginning to wonder how it's possible
to tame/maintain this "beast" at all.

... the curse of object oriented programming aka code re-use!
Can't simply rewrite it from scratch. :-)  
You need to log in before you can comment on or make changes to this bug.