User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

1. Created new "LDAP Directory" item in the Address Book window
2. Entered hostname, base DN, and search filter to suit our Samba AD DC
3. Enabled "Kerberos (GSSAPI)" login method
4. Attempted to search for a known user in the directory

We have tried this procedure on Linux and Windows 8 & 10, with TB 91.0.1 (Windows) and 91.0.2 (Linux and Windows).

Actual results:

No search results are shown in the address book window.

No output is logged (empty log files after closing TB) when using MOZ_LOG=LDAP:5,timestamp and MOZ_LOG_FILE=ldap.log environment variables as described here:

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

A packet capture shows an LDAP bindRequest(1) "<ROOT>" sasl being sent, and the server responding with bindResponse(1) invalidCredentials.

The klist command shows a valid ticket for the LDAP service, and ldapsearch and "LDAP Admin" tools both work when authenticating using GSS-API.

The GSS-API payload in the bindRequest packet appears to be Base64-encoded, and Wireshark has trouble dissecting it:

Lightweight Directory Access Protocol
LDAPMessage bindRequest(1) "<ROOT>" sasl
messageID: 1
protocolOp: bindRequest (0)
bindRequest
version: 3
name:
authentication: sasl (3)
sasl
mechanism: GSSAPI
credentials: [redacted]
GSS-API Generic Security Service Application Program Interface
Unknown header (class=1, pc=0, tag=25)
[Expert Info (Warning/Protocol): Unknown header (class=1, pc=0, tag=25)]
[Unknown header (class=1, pc=0, tag=25)]
[Severity level: Warning]
[Group: Protocol]

Changing the login method to "Simple" (and setting a bind DN) allows the address book lookup to work, but a password is required.

Expected results:

A contact entry matching the search terms is shown. This is the case in TB 78 on Linux and Windows with the same LDAP Directory configuration.

In this case, a packet capture shows a series of three LDAP bindRequest(n) "<ROOT>" sasl being sent, and the server responding with bindResponse(n) saslBindInProgress followed by bindResponse(n) success.

The GSS-API payload in the bindRequest packets is not Base64-encoded, and Wireshark can dissect it:

Lightweight Directory Access Protocol
LDAPMessage bindRequest(1) "<ROOT>" sasl
messageID: 1
protocolOp: bindRequest (0)
bindRequest
version: 3
name:
authentication: sasl (3)
sasl
mechanism: GSSAPI
credentials: [redacted]
GSS-API Generic Security Service Application Program Interface
OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
krb5_blob: [redacted]
krb5_tok_id: KRB5_AP_REQ (0x0001)
Kerberos
ap-req
pvno: 5
msg-type: krb-ap-req (14)
Padding: 0
ap-options: 20000000 (mutual-required)
0... .... = reserved: False
.0.. .... = use-session-key: False
..1. .... = mutual-required: True
ticket
tkt-vno: 5
realm: [redacted]
sname
enc-part
authenticator
etype: [redacted]
cipher: [redacted]

Thanks for reporting and pointing out the base64 encoding problem. I mistakenly reused the code used for SMTP GSSAPI auth. Will make a fix soon.

Excellent, thank you for your work on this.

nsIMailAuthModule was made for SMTP and other mail protocols, as a result getNextToken was made to return a base64 string. But LDAP is a binary protocol, LDAP servers expect raw binary of GSSAPI token.

Can you help me test by downloading https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/d95QnhTMSqark7NnW88-QA/runs/0/artifacts/public/build/target.tar.bz2? It's an artifact build that can be found on https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=f149e0bfc17e215cc3aeff6dec81145a73e0b60d

Thanks for the fast response. The new build is now sending a valid bindRequest, which Wireshark can dissect, and the server is responding with saslBindInProgress rather than invalidCredentials. Sadly, there are no further LDAP packets after that.

The TB console shows:

mailnews.ldap: Connecting to ldap://kdc.example.com:389 LDAPClient.jsm:43:18
mailnews.ldap: Connected LDAPClient.jsm:140:18
mailnews.ldap: Binding ldap@kdc.example.com using GSSAPI LDAPClient.jsm:81:18
mailnews.ldap: C: [1] BindRequest LDAPClient.jsm:250:18
mailnews.ldap: S: [1] BindResponse resultCode=14 message="" LDAPClient.jsm:187:20
mailnews.ldap: Binding ldap@kdc.example.com using GSSAPI LDAPClient.jsm:81:18
TypeError: buffer is not iterable utils.js:226:43

I did some digging in omni.ja and found that the exception is being raised within arrayBufferToByteString() of modules/services-common/utils.js.

Creating a Uint8Array from the serverCredentials ArrayBuffer in LDAPClient's saslBind() seems to fix that. For example:

    var c = new Uint8Array(serverCredentials);
    // getNextToken expects a base64 string.
    let token = this._authModule.getNextToken(
      serverCredentials
        ? btoa(CommonUtils.arrayBufferToByteString(c))
        : ""
    );

I then get results back from the server.

Great, I have updated the patch. Thanks a lot.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/215f2c7d25ff
Fix GSSAPI auth for LDAP. r=darktrojan DONTBUILD

Comment on attachment 9237924 [details]
Bug 1727478 - Fix GSSAPI auth for LDAP. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): bug 1696625
User impact if declined: GSSAPI auth doesn't work for LDAP
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): low, doesn't work anyway

Comment on attachment 9237924 [details]
Bug 1727478 - Fix GSSAPI auth for LDAP. r=darktrojan

[Triage Comment]
Approved for beta

Thunderbird 92.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/2821aa689177

92.0b5 is working nicely here. Thanks all.

Comment on attachment 9237924 [details]
Bug 1727478 - Fix GSSAPI auth for LDAP. r=darktrojan

[Triage Comment]
Approved for esr91

Thunderbird 91.1.1:
https://hg.mozilla.org/releases/comm-esr91/rev/e7e7f8ec40ae