Closed Bug 671827 Opened 13 years ago Closed 13 years ago

LDAP search is broken when using GSSAPI binding

Categories

(Thunderbird :: Address Book, defect)

All
Other
defect
Not set
normal

Tracking

(thunderbird6-, thunderbird7-, thunderbird8+ fixed, thunderbird9 fixed)

RESOLVED FIXED
Thunderbird 10.0
Tracking Status
thunderbird6 - ---
thunderbird7 - ---
thunderbird8 + fixed
thunderbird9 --- fixed

People

(Reporter: sasha78, Assigned: Bienvenu)

References

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122 Safari/534.30

Steps to reproduce:

After upgrading from TB 3.1 to TB 5 LDAP stopped working. 


Actual results:

After upgrade LDAP settings in TB 5 are identical to those in TB 3.1 still LDAP is not working. LDAP still works on TB 3.1 installed in another directory.
After generating log from LDAP query in TB 3.1 and TB 5 seems that there are major differences in filter which both use to query LDAP - see attachments.
Keywords: regression
Component: Message Compose Window → Address Book
QA Contact: message-compose → address-book
Are you using autocomplete or quick search within the address book view?
(In reply to comment #1)
> Are you using autocomplete or quick search within the address book view?

Both, neither works. Also tried Contacs Sidebar add-on and offline replication in LDAP settings.

INFO ADDENDUM:
LDAP server is Active Directory domain controller on Windows Server 2008.
Tried both 389 and 3268 ports. In TB 3.1 LDAP worked on standard 389 port.
LDAP also is not working with GSSAPI (kerberos) auth. In TB3.1 all work fine. In TB5.0, ldap address book work only with credentials and very restricted scope of search.
Another problem, that TB use several queries to ldap, and before every query, TB asks for ip of domain controller. We have PDC and BDC with balanced configuration, so first query return ip of PDC, TB create SSL connection (server certificate imported). Then TB generate second query, but before asks ip of DC. In our configuration, DNS return ip of BDC. But SSL connection use cert of PDC, so connection breaks, with error of incorrect certificate.
This works good in TB3.1.

So in TB5.0 ldap address book absolutely not working.
Confirming this on TB5. It workins just fine with simple binding. When you enable GSSAPI binding, binding itself work correctly but TB only perforom binding itself and doesn't issue LDAP search.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: LDAP working in TB 3.1, not working in TB 5 → LDAP search is broken when using GSSAPI binding
Trunk affected as well.
Version: 5.0 → Trunk
(In reply to comment #4)
> Confirming this on TB5. It workins just fine with simple binding. When you
> enable GSSAPI binding, binding itself work correctly but TB only perforom
> binding itself and doesn't issue LDAP search.

Confirmed using the most recent Fedora 15 build of Thunderbird (thunderbird-5.0-1.fc15.x86_64).
Maybe Simon has a clue - he did the initial gssapi work, iirc.
Happens to me to, on Fedora 15 with thunderbird-5.0-1.fc15.i686.  Also using LDAP with kerberos, also working on Thunderbird < 5.
Can someone get a log file of the failure, I suggest just starting with LDAP:5 to begin with:

https://wiki.mozilla.org/MailNews:Logging

I think its too late to do anything for 6, but we'll look at fixing it in 7.
Here is the log, from a session trying to get a name in the address book
How are you all getting a log?  I can't even get TB 3.1.11 do to that using the instructions at https://wiki.mozilla.org/MailNews:Logging.

i.e. the following produces absolutely nothing at all:

$ export NSPR_LOG_MODULES="ldap:5"
$ thunderbird

I have left the NSPR_LOG_FILE env. variable empty so that it logs to the tty.
(In reply to Brian Murrell from comment #11)
> I have left the NSPR_LOG_FILE env. variable empty so that it logs to the tty.

If you're on windows that probably won't work, and you need to specify the file itself.

Whilst you're at it, can you make NSPR_LOG_MODULES be "ldap:5,gssapi:5,ldapautocomplete:5" that might give us a bit more information.

Feel free to send the logs to me direct if there's sensitive info in there (or obscure it).
OK.  So I got logging to happen.

But even using TB 3.1.11 I can't get a GSSAPI authenticated search to work -- simple bind works of course.  But with GSSAPI, I get insufficient rights errors from the LDAP server.  I am able to get search results with:

$ ldapsearch -Y GSSAPI -h ldap -D uid=brian,ou=People,dc=example,dc=com -b ou=Contacts,uid=brian,ou=People,dc=example,dc=com "(cn=*)"

So my GSSAPI credentials are correct.

Additionally, using wireshark I can see that the GSSAPI credentials are correct using ldapsearch -- there is a subtree for the GSSAPI portion of the bind request that shows all of the GSSAPI parameters.  When TB tries to bind, wireshark sees that a GSSAPI bind is attempted but there are no details (i.e. GSSAPI parameters) in a subtree, leading me to believe the entire GSSAPI blob is malformed.
(In reply to Mark Banner (:standard8) from comment #12)
> 
> If you're on windows that probably won't work, and you need to specify the
> file itself.

But of course I am not on windows or I wouldn't be using bourne shell syntax such as "export ...".  :-)
 
> Whilst you're at it, can you make NSPR_LOG_MODULES be
> "ldap:5,gssapi:5,ldapautocomplete:5" that might give us a bit more
> information.

No need.  I got LDAP logging to work.  But per my other comment(s), clearly it's not working with GSSAPI, even in 3.1.11 (on Linux).

Thanks for the help though, much appreciated.
(In reply to Brian Murrell from comment #14)
> (In reply to Mark Banner (:standard8) from comment #12)
> > Whilst you're at it, can you make NSPR_LOG_MODULES be
> > "ldap:5,gssapi:5,ldapautocomplete:5" that might give us a bit more
> > information.
> 
> No need.  I got LDAP logging to work.  But per my other comment(s), clearly
> it's not working with GSSAPI, even in 3.1.11 (on Linux).

Unfortunately you're probably seeing a different issue to this bug (maybe your setup is incorrect somewhere) as other users have seen it working in 3.1.
(In reply to Mark Banner (:standard8) from comment #15)
> 
> Unfortunately you're probably seeing a different issue to this bug (maybe
> your setup is incorrect somewhere) as other users have seen it working in
> 3.1.

How could my setup be incorrect when everything works when I change the Login method from GSSAPI to Simple?
Brian,

What kerberos libs are you using, MIT?
(In reply to Nikolay Shopik from comment #17)
> 
> What kerberos libs are you using, MIT?

Yes.
on windows, we use the windows sspi by default, unless you toggle network.auth.use-sspi to false.
(In reply to David :Bienvenu from comment #19)
> on windows, we use the windows sspi by default, unless you toggle
> network.auth.use-sspi to false.

Was this meant to be in relation to the occurrence of this issue I am seeing on TB 3.1.11?
(In reply to Brian Murrell from comment #16)
> How could my setup be incorrect when everything works when I change the
> Login method from GSSAPI to Simple?

I suspect that your LDAP server is configured to require that GSSAPI is used to provide a security layer for the connection, rather than just initial authentication. From memory (it's a long time since I wrote it) we don't do LDAP SASL security layers - if you care about connection integrity, then use TLS to protect the connection, and GSSAPI to authenticate it.
I could confirm Simon words, we even have separate bug for connection security.
(In reply to Brian Murrell from comment #20)

> 
> Was this meant to be in relation to the occurrence of this issue I am seeing
> on TB 3.1.11?

Yes, just trying to distinguish between issues that are new to TB 5 and users having issues with 3.1.11. I couldn't tell if it had ever worked for you. But in any case, Simon is more likely to be on topic.
(In reply to Simon Wilkinson from comment #21)
> 
> I suspect that your LDAP server is configured to require that GSSAPI is used
> to provide a security layer for the connection, rather than just initial
> authentication.

I'm (very) far from expert in this area, but doesn't the following indicate that my LDAP server does not require a security layer?

$ ldapsearch  -O maxssf=0 -Y GSSAPI -h ldap -D uid=brian,ou=People,dc=example,dc=com -b ou=Contacts,uid=brian,ou=People,dc=example,dc=com "(sn=Bibby)"
SASL/GSSAPI authentication started
SASL username: brian@ILINX
SASL SSF: 0
[ search results follow ]
Whiteboard: [needs test server setting up]
Depends on: 693650
Thx to gozer, I was able to debug this a bit. When we try to do the search operation, we get this back from the operation:

LDAP_SASL_BIND_IN_PROGRESS 	14 (x'0E) 	The server is currently performing a SASL bind and the requested operation is invalid in this context. 

Which to me implies we're not waiting for the bind to complete before issuing the next command. But I've had a lot of missteps in getting this far, so I might be wrong.
this makes gssapi binding work again. Bug 343332 caused this regression. I don't know if doing the saslstep directly in the nsLDAPConnectionRunnable::Run is the right thing, though we are doing the ldap_set_option in the code right above...
Assignee: nobody → dbienvenu
Attachment #569846 - Flags: review?(mbanner)
Cc'ing jhorak to see if he has thoughts about a better way of fixing this...
Status: NEW → ASSIGNED
Blocks: 343332
Whiteboard: [needs test server setting up]
Comment on attachment 569846 [details] [diff] [review]
patch that fixes it.

Review of attachment 569846 [details] [diff] [review]:
-----------------------------------------------------------------

This was probably my fault due to the way I was working through that patch. However, this looks to be the right thing to do.

::: ldap/xpcom/src/nsLDAPConnection.cpp
@@ +760,5 @@
> +            NS_ENSURE_TRUE(operation, NS_ERROR_NULL_POINTER);
> +
> +            nsresult rv = operation->SaslStep(creds->bv_val, creds->bv_len);
> +            if (NS_SUCCEEDED(rv))
> +              return PR_TRUE;

nit: should be NS_OK.
Attachment #569846 - Flags: review?(mbanner) → review+
fixed on trunk with NS_OK replacing PR_TRUE; http://hg.mozilla.org/comm-central/rev/6afdec9daeeb
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 10.0
Comment on attachment 569846 [details] [diff] [review]
patch that fixes it.

we most likely want to land this on comm-aurora and I would argue that it's a safe-enough fix for beta, since it only affects sasl/gssapi binding, which can't be broken more :-)
Attachment #569846 - Flags: approval-comm-beta?
Attachment #569846 - Flags: approval-comm-aurora?
Attachment #569846 - Flags: approval-comm-beta?
Attachment #569846 - Flags: approval-comm-beta+
Attachment #569846 - Flags: approval-comm-aurora?
Attachment #569846 - Flags: approval-comm-aurora+
You need to log in before you can comment on or make changes to this bug.