1010297 - LDAP to Active Directory only works from addressbook not from compose autocomplete

Status: RESOLVED DUPLICATE of bug 668087

(MailNews Core :: LDAP Integration, defect)

Description

[Ian Neal]

In recent versions of TB the LDAP to Active Directory from compose autocomplete has stopped working. It still works if searching via the addressbook.
STR
1/ Setup TB with an LDAP directory entry to an Active Directory server, binding using an account that requires a password
2/ Go into the addressbook and search for a known user in the LDAP addressbook.
3/ Check it finds the known user.
4/ Open a compose window and type in the start of a name of a known user into the autocomplete.

Expected result
1/ Email address for known user is autocompleted.

Actual result
1/ Autocomplete fails to return with the email address for the known user.

Last version that works was TB23.
Current TB30 beta works to an LDAP server (Netscape Directory server), which allows anonymous bind, just not to an Active Directory LDAP server.

Comment 1

[stvdo]

When migrating from TB 24.x ESR to TB 31.(1|2|3) ESR I observe the described regression. Here, an Active Directory server is involved, too. Same steps as above to reproduce. Platform is GNU Linux x86_64. Authentication method is GSSAPI (changing that does not effect the bug).

Interestingly, the compose window address auto completion is working again, if the base DN is changed from "DC=my,DC=own,DC=domain" to a base DN with a OU component like "OU=top,DC=my,DC=own,DC=domain". Unfortunately, that restricts auto completion to a specific OU and does not search all of the AD as it did in TB 24.

With debug logging enabled (NSPR_LOG_MODULES=ldap:5), the log shows the actual LDAP search results being the same regardless of the "OU=" component being present or absent. In both cases the search completes and returns valid addresses. But then, why does auto completion work for one case, only?

Comment 2

[Wayne Mery (:wsmwk)]

can we get a better idea of which nightly build or bug caused the regression?

Comment 3

[stvdo]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> can we get a better idea of which nightly build or bug caused the regression?

OK, now I've tested releases 24.7.0, 24.8.0, 24.8.1, 25.0b1, 31.3.0. Things worked up to version 24.8.1 and stopped working at 25.0b1.

Comment 4

[stvdo]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> can we get a better idea of which nightly build or bug caused the regression?

I hope the following will help, too. A table of which configuration worked when:

build						OU=someou,DC=my,DC=own,DC=domain	DC=my,...
-------------------------------------------------------------------------------------------------
24.8.1						OK					OK
25.0a1 (2013-08-01-03-02-25-comm-central)	--					--
25.0a2 (2013-08-06-00-40-00-comm-aurora)	--					--
25.0a2 (2013-09-17-00-40-04-comm-aurora)	OK					--
25.0b1 						OK					--
31.3.0						OK					--

So, things broke completely in 25.0a1 and started working partially in 25.0a2 somewhere between 2013-08-06 and 2013-09-17 nightly builds.

Comment 5

[Magnus Melin [:mkmelin]]

http://hg.mozilla.org/comm-central/pushloghtml?startdate=2013-08-06&enddate=2013-09-17

So possibly from bug 899822 but it doesn't look that likely to me

Comment 6

[Merome]

TB 38.0.1 under Windows 7,  Active Directory 2008.

I can reproduce the problem : autocomplete works on address book and in the contacts pane, but not in compose window.
I enable ldap logging and it seems the ldap search is performed and returns same results in all cases, but they are simply not displayed in the autocomplete form of the compose window.

There is only one difference in the ldap log between the two cases, but I don't konw if it's relevant : 

From contacts pane and address book (when it works):

aAttributes=mozillaCustom2,custom2,cn,commonname,title,sn,surname,mozillaHomeLocalityName,givenName,mozillaHomeState,mail,mozillaHomeUrl,homeurl,mozillaWorkUrl,workurl,labeledURI,mozillaWorkStreet2,o,company,mozillaNickname,xmozillanickname,mobile,cellphone,carphone,modifytimestamp,nsAIMid,nscpaimscreenname,telephoneNumber,birthyear,c,countryname,mozillaHomeStreet,postalCode,zip,mozillaCustom1,custom1,mozillaHomeCountryName,st,region,mozillaHomePostalCode,mozillaSecondEmail,xmozillasecondemail,facsimiletelephonenumber,fax,description,notes,mozillaCustom3,custom3,homePhone,mozillaUseHtmlMail,xmozillausehtmlmail,mozillaHomeStreet2,birthday,street,streetaddress,postOfficeBox,mozillaCustom4,custom4,l,locality,pager,pagerphone,ou,department,departmentnumber,orgunit,birthmonth,objectClass; aSizeLimit = 100

Form compose window (when it doesn't work) :

aAttributes = cn,commonname,mail,objectClass; aSizeLimit = 100

I hope this will help you to find the bug.

Comment 7

[Wayne Mery (:wsmwk)]

Merome, thanks for the info.

The range Ian identified, while helpful, is quite large. Can you narrow it further please from 2013-08-06 to 2013-09-17 nightly builds?

Comment 8

[Jeremy Nix]

Please see bug #668087.  I submitted a patch to nsLDAPConnection.cpp that disabled LDAP referrals.  When I compile from trunk with this patch, I am able to successfully get autocomplete to work in my compose windows.  I do not know if this fix will work for all use-cases, but for my environment it was successful.  I've been building from trunk ever since :)

Comment 10

[Wayne Mery (:wsmwk)]

(Merome seems to be gone)

Comment 11

[Wayne Mery (:wsmwk)]

https://mozilla.github.io/mozregression/ can be used to help find the regression range

Comment 12

[elvegaa]

Attachment: SUMMARY_BUGTEST.txt

Comment 13

[elvegaa]

I've attached a summary  with a research I did. 

I'm having the same scenario described by Merome since TB 25.0.1b to 45.3.0

I've used the same environment and profile for every test. My Base DN was dc=somedomain,dc=com and filter was (objectclass=person)(mail=*) in order to work with my configuration. The test was to open a new compose window, and type "alice" in the "To:" field. It should show up 6 different names. 

* 2013-08-05-00-40-03-comm-aurora : It worked fine. Debugging lvl5 shows an entry like: nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=somedomain,dc=com'; aFilter = '(&(objectclass=person)(mail=*)(|(cn=alice**)(mail=alice**)(sn=alice**)))'; aAttributes = cn,mail; aSizeLimit = 100

* 2013-08-06-00-40-00-comm-aurora : Doesn't works. Debugging lvl5 shows nothing. Same behavior in the next updates.

* 2013-09-11-00-40-07-comm-aurora : Doesn't works. But debugging lvl5 shows an entry like: nsLDAPOperation::SearchExt(): called with aBaseDn = 'dc=somedomain,dc=com'; aFilter = '(&(objectclass=person)(mail=*)(|(cn=alice**)(mail=alice**)(sn=alice**)))'; aAttributes = cn,commonname,mail,objectClass; aSizeLimit = 100
Also, 6 nsLDAPMessage::GetDn(): messages are shown, one for each name coincidence in the LDAP server, but nothing shows up in the application.


It seems something ws wrong between 2013-08-05-00-40-03-comm-aurora and 2013-08-06-00-40-00-comm-aurora.

Regards.

Comment 14

[Magnus Melin [:mkmelin]]

https://hg.mozilla.org/releases/comm-aurora/pushloghtml?startdate=2013-08-05+00%3A40%3A03&enddate=2013-08-06+00%3A40%3A00

Quite likely from bug 452232

Comment 15

[elvegaa]

I've tested Jeremy Nix patch solution in my own build from 2016-09-21 daily source and it worked perfectly.

Comment 16

[Wayne Mery (:wsmwk)]

Sounds like we should get that patch dusted and finished in bug 668087