Closed Bug 332483 Opened 18 years ago Closed 18 years ago

LDAP userCertificate requests fail for ldap servers that require auth

Categories

(Thunderbird :: Address Book, defect)

Product:
Thunderbird
Component:
Address Book
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird2.0

People

(Reporter: pld, Assigned: mscott)

References

Details

(Keywords: fixed1.8.1)

Attachments

(2 files, 1 obsolete file)

support login and password for cert certificate ldap searching
3.40 KB, patch
KaiE
: review+
Bienvenu
: superreview+
Details | Diff | Splinter Review
screenshot showing success
19.00 KB, image/png
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705)
Build Identifier: Thunderbird version 1.5 (20051201)

Previously (versions 1.0.x) when the address book was configured to interface to an external LDAP directory, userCertificate was fetched (and used by TB) as well as other attributes. Unfortunately this isn't the case in TB 1.5. I've examined the LDAP request both locally and on the server side and userCertificate is simply not a part of the request.

I've noticed that inserting the line
  pref("ldap_2.servers.default.attrmap.x", "usercertificate");
in "mailnews.js" does effect the requests to include the userCertificate, but of course it doesn't show up in the Thunderbird application while x does not map to anything internally.

I assume that this should be rather simple to fix for people with insight in the code?




Reproducible: Always
Summary: Thunderbird LDAP requests does not include userCertificate anymore → Thunderbird LDAP requests do not include userCertificate anymore
LDAP email certificate fetching is implemented in file
mozilla/mailnews/extensions/smime/resources/content/certFetchingStatus.js

In the past this was hooked into some mailnews init code, maybe something broke that?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.0.3?
Looks like this is missing 1.8.0.3, try 1.8.0.4
Flags: blocking1.8.0.4?
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.3-
Keywords: regression
Target Milestone: --- → Thunderbird2.0
It looks like the cert fetcher gets an error code back from the call to:
gLdapOperation.simpleBind(null);

which translates to: anonymous bind disallowed.

At least for me, my problem is that the cert fetching ldap search doesn't pass in the login credentials nor the stored password for the ldap server. Just for grins, I manually passed in auth.dn text into the ldap connectio init call:

http://lxr.mozilla.org/mozilla/source/mailnews/extensions/smime/resources/content/certFetchingStatus.js#90

and then in the call to SimpleBind, I hard coded my password:

http://lxr.mozilla.org/mozilla/source/mailnews/extensions/smime/resources/content/certFetchingStatus.js#146

And then I saw us go through and ask for the cert attribute (there was none so I couldn't actually verify that we add the cert correctly), and the ldap query looked good and we got a response to the search.
Peter, does your LDAP server require a username and a password to connect with?
This patch makes the cert fetching code work when using ldap servers that require username / password credentials. You will get the password prompt on top of the cert fetching dialog if we don't have a stored password for the ldap server.

I don't know if this was Peter's problem. It would be good to hear back if his ldap server requires a username / password. 

Our in house ldap server doesn't support certificates, but I was able to verify that we now correctly search for the cert attribute.

If we can get some feedback from Peter, I would like to fast track this for 1.8.0.3 again.
Attachment #219789 - Flags: superreview?(dmose)
Attachment #219789 - Flags: review?
This patch makes the cert fetching code work when using ldap servers that require username / password credentials. You will get the password prompt on top of the cert fetching dialog if we don't have a stored password for the ldap server.

I don't know if this was Peter's problem. It would be good to hear back if his ldap server requires a username / password. 

Our in house ldap server doesn't support certificates, but I was able to verify that we now correctly search for the cert attribute.

If we can get some feedback from Peter, I would like to fast track this for 1.8.0.3 again.
Attachment #219790 - Flags: superreview?(dmose)
Attachment #219790 - Flags: review?
Comment on attachment 219789 [details] [diff] [review]
support login and password for cert certificate ldap searching

bugzilla's being grouchy. sorry for the duplicate request
Attachment #219789 - Attachment is obsolete: true
Attachment #219789 - Flags: superreview?(dmose)
Attachment #219789 - Flags: review?
Attachment #219790 - Flags: review? → review?(kengert)
Attachment #219790 - Flags: review?(kengert) → review+
(In reply to comment #5)
> Peter, does your LDAP server require a username and a password to connect with?

Nope, you can try it out at:
- host: dir.certifikat.dk
- port: 389
- searchbase: c=DK

Note that we discard wildcards to avoid simple harvesting, but you can request my certificate by filtering on my exact email (pld@tdc.dk)

Best regards
Peter Lind Damkjaer
(In reply to comment #9)
> (In reply to comment #5)
> > Peter, does your LDAP server require a username and a password to connect with?
> 
> Nope, you can try it out at:
> - host: dir.certifikat.dk
> - port: 389
> - searchbase: c=DK
> 
> Note that we discard wildcards to avoid simple harvesting, but you can request
> my certificate by filtering on my exact email (pld@tdc.dk)
> 
> Best regards
> Peter Lind Damkjaer
> 

Heh. When I tried to connect to dir.certifikat.dk to search for your e-mail address, I got a username/password prompt :). Maybe I didn't configure the directory properly...
(In reply to comment #10)
> Heh. When I tried to connect to dir.certifikat.dk to search for your e-mail
> address, I got a username/password prompt :). Maybe I didn't configure the
> directory properly...

Weird, the server does allow anonymous LDAP request. You can verify this by sending a request from a RFC2255-enabled browser (e.g. MSIE):

ldap://dir.certifikat.dk/c=DK??sub?(mail=pld%40tdc.dk)

or by making a request from a commandline-lapdsearch (not sure how this is exactly done).

Regards
Peter
I've added your LDAP directory Peter and good news (at least for me), a freshly downloaded 1.5.0.2 build is correctly finding your certificate. 

I'll attach a screen shot of what I see with a 1.5.0.2 build. 
screen shot showing that we found the certificate from the ldap directory. Taken from 1.5.0.2
(In reply to comment #12)
> I've added your LDAP directory Peter and good news (at least for me), a freshly
> downloaded 1.5.0.2 build is correctly finding your certificate. 
> I'll attach a screen shot of what I see with a 1.5.0.2 build. 

I can confirm that my problem seems solved in 1.5.0.2 build. It also works for me now.
clearing the regression flag. 

I'd still like to add the support for login/pwd information for this on the trunk and 1.8.1 branch.
Keywords: regression
I think what's left for this issue can wait for thunderbird 2.
Flags: blocking1.8.0.5?
clarifying the summary.
Summary: Thunderbird LDAP requests do not include userCertificate anymore → LDAP userCertificate requests fail for ldap servers that require auth
(In reply to comment #12)
> I've added your LDAP directory Peter and good news (at least for me), a freshly
> downloaded 1.5.0.2 build is correctly finding your certificate. 
> 
> I'll attach a screen shot of what I see with a 1.5.0.2 build. 
> 

Not sure how you did this, but a freshly downloaded and installed Thunderbird 1.5.0.2 (20060308) build DOES NOT request the userCertificate attribute.  Per an ethereal capture, the attributes requested are:

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

-JSP

I think we optionally fetch certs from ldap when doing s/mime...
(In reply to comment #18)
> 
> Not sure how you did this, but a freshly downloaded and installed Thunderbird
> 1.5.0.2 (20060308) build DOES NOT request the userCertificate attribute.  

Compose a mail message, use menu "options / security / encrypt this message", and either use "view security info" or try to send the message, and you should see an ldap request to fetch the cert.

> Compose a mail message, use menu "options / security / encrypt this message",
> and either use "view security info" or try to send the message, and you should
> see an ldap request to fetch the cert.
> 

1) Opened a new 'compose' 

2) Set options->security->encrypt this message

3) Typed the name of the user I want to send to in the address book search.  
    * LDAP query made here, *no userCertificate attribute requested*.

4) Selected matching address from the query repsonse screen, it is now in the To: field

5) Add some text and hit send.
   * "Sending of Messge Failed\nYou specified encryption for this message, but the application failed to find an encryption certificate for [name in To:]"
   * No additional LDAP query made

6) Chose view->Message Security Info
   * I see the recipient listed with status of "Not Found"
   * No additional LDAP query made.

If I use only the address book to do the lookup, still no userCertificate attribute being requested.

-JSP




Hey Dan, any chance you'll have some time to review this ldap cert patch?
(In reply to comment #22)
> Hey Dan, any chance you'll have some time to review this ldap cert patch?
> 

We are having the same issue (bug post 354525) when trying to fetch certificates using anonymous bind. Will there be a patch for this bug anytime soon?
Comment on attachment 219790 [details] [diff] [review]
support login and password for cert certificate ldap searching

trying david.
Attachment #219790 - Flags: superreview?(dmose) → superreview?(bienvenu)
Attachment #219790 - Flags: superreview?(bienvenu) → superreview+
fixed branch and trunk.
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
*** Bug 294457 has been marked as a duplicate of this bug. ***
*** Bug 149013 has been marked as a duplicate of this bug. ***
BUG still exists in some other way now - using 2.0.0.12 (20080213)

The LDAP Search will only be used as long as no @ is encountered while typing into the TO Field

I.e. i type : john.doe

In the LDAP Request logs i see 

(|(cn=jo*)(mail=jo*)(sn=jo*))
(|(cn=joh*)(mail=joh*)(sn=joh*))
(|(cn=john*)(mail=john*)(sn=john*))
(|(cn=john.*)(mail=john.*)(sn=john.*))
(|(cn=john.d*)(mail=john.d*)(sn=john.d*))
(|(cn=john.do*)(mail=john.do*)(sn=john.do*))
(|(cn=john.doe*)(mail=john.doe*)(sn=john.doe*))

so for every char i typ a lookup is down (type ahead) which is correct - but as soon as i start with the @ - no lookup is being performed!

john.doe@somewhere.com

In other words - when LDAP is only indexed by email (default) this will never work!

Please fix it that way - that LDAP lookup does NOT stop at "@"
please somebody reopen this bug again
(In reply to comment #29)
> please somebody reopen this bug again
> 
Please can you file a different bug for your issue after search for other possible duplicates. Your bug does not appear to be related to issues of authentication.
as requested i open up a new bug

https://bugzilla.mozilla.org/show_bug.cgi?id=454563
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: