SASL: encoded packet size too big
Hello!
Dovecot uses it's own SASL implementation, doesn't it?
Aug 14 23:45:23 example.com auth[10428]: GSSAPI client step 1
Aug 14 23:45:23 example.com auth[10428]: encoded packet size too big (813804546 > 65536)
Aug 14 23:45:23 example.com dovecot[10085]: auth-worker(10428): Error: LDAP: Can't connect to server: ldap://ipa2.example.com
Aug 14 23:45:23 example.com dovecot[10085]: auth: Error: auth worker: Aborted USER request for eugene: Lookup timed out
Aug 14 23:45:23 example.com dovecot[10085]: imap: Error: auth-master: login: request [3847225345]: Login auth request failed: Internal auth failure (auth connected 60000 msecs ago, request took 60000 msecs, client-pid=10362 client-id=1)Looks like cyrus-sasl encountered same problem earlier. https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2017-March/003001.html
I never have such an issue with ldapsearch. So, I assume there is a similar problem in Dovecot SASL implementation.
-- Eugene Bright IT engineer Tel: + 79257289622
The next combination of parameters makes 100% LDAP connections unsuccessful (the log snippet form the previous mail). sasl_bind = yes sasl_mech = gssapi tls = yes
Looks like this combination is utterly incorrect and should be prohibited (tls must not be used when mech is gssapi). https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
With tls = no errors encoded packet size too big becomes sporadic, but still heart auth orepations performance.
May be there are two different problems.
Has someone encountered this problem before? How can I help to facilitate the issue debugging?
[I] net-mail/dovecot Installed versions: 2.3.7.1(01:58:12 08/14/19)(bzip2 caps ipv6 kerberos ldap libressl lua lz4 lzma pam postgres sieve sqlite tcpd zlib -argon2 -doc -lucene -managesieve -mysql -selinux -solr -static-libs -suid -textcat -vpopmail)
On 8/15/19 12:01 AM, Eugene wrote:
Hello!
Dovecot uses it's own SASL implementation, doesn't it?
Aug 14 23:45:23 example.com auth[10428]: GSSAPI client step 1 Aug 14 23:45:23 example.com auth[10428]: encoded packet size too big (813804546 > 65536) Aug 14 23:45:23 example.com dovecot[10085]: auth-worker(10428): Error: LDAP: Can't connect to server: ldap://ipa2.example.com Aug 14 23:45:23 example.com dovecot[10085]: auth: Error: auth worker: Aborted USER request for eugene: Lookup timed out Aug 14 23:45:23 example.com dovecot[10085]: imap: Error: auth-master: login: request [3847225345]: Login auth request failed: Internal auth failure (auth connected 60000 msecs ago, request took 60000 msecs, client-pid=10362 client-id=1)
Looks like cyrus-sasl encountered same problem earlier. https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2017-March/003001.html
I never have such an issue with ldapsearch. So, I assume there is a similar problem in Dovecot SASL implementation.
-- Eugene Bright IT engineer Tel: + 79257289622
On 15/08/2019 00:34 Eugene via dovecot <dovecot@dovecot.org> wrote:
The next combination of parameters makes 100% LDAP connections unsuccessful (the log snippet form the previous mail). sasl_bind = yes sasl_mech = gssapi tls = yes
Looks like this combination is utterly incorrect and should be prohibited (tls must not be used when mech is gssapi). https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
With
tls = noerrorsencoded packet size too bigbecomes sporadic, but still heart auth orepations performance. May be there are two different problems.
Does the "encoded packet size too big" coincide with LDAP server connection failure?
Aki
Has someone encountered this problem before? How can I help to facilitate the issue debugging?
[I] net-mail/dovecot Installed versions: 2.3.7.1(01:58:12 08/14/19)(bzip2 caps ipv6 kerberos ldap libressl lua lz4 lzma pam postgres sieve sqlite tcpd zlib -argon2 -doc -lucene -managesieve -mysql -selinux -solr -static-libs -suid -textcat -vpopmail)
On 8/15/19 12:01 AM, Eugene wrote:
Hello!
Dovecot uses it's own SASL implementation, doesn't it?
Aug 14 23:45:23 example.com auth[10428]: GSSAPI client step 1 Aug 14 23:45:23 example.com auth[10428]: encoded packet size too big (813804546 > 65536) Aug 14 23:45:23 example.com dovecot[10085]: auth-worker(10428): Error: LDAP: Can't connect to server: ldap://ipa2.example.com Aug 14 23:45:23 example.com dovecot[10085]: auth: Error: auth worker: Aborted USER request for eugene: Lookup timed out Aug 14 23:45:23 example.com dovecot[10085]: imap: Error: auth-master: login: request [3847225345]: Login auth request failed: Internal auth failure (auth connected 60000 msecs ago, request took 60000 msecs, client-pid=10362 client-id=1)
Looks like cyrus-sasl encountered same problem earlier. https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2017-March/003001.html
I never have such an issue with ldapsearch. So, I assume there is a similar problem in Dovecot SASL implementation.
-- Eugene Bright IT engineer Tel: + 79257289622
That's right. GSS-API is not used anywhere else. Do you like to inspect my full configuration? I can dump connection session and send pcap file here.
On August 15, 2019 7:27:20 AM GMT+03:00, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 15/08/2019 00:34 Eugene via dovecot <dovecot@dovecot.org> wrote:
The next combination of parameters makes 100% LDAP connections unsuccessful (the log snippet form the previous mail). sasl_bind = yes sasl_mech = gssapi tls = yes
Looks like this combination is utterly incorrect and should be prohibited (tls must not be used when mech is gssapi).
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
With
tls = noerrorsencoded packet size too bigbecomessporadic, but still heart auth orepations performance.
May be there are two different problems.
Does the "encoded packet size too big" coincide with LDAP server connection failure?
Aki
Has someone encountered this problem before? How can I help to facilitate the issue debugging?
[I] net-mail/dovecot Installed versions: 2.3.7.1(01:58:12 08/14/19)(bzip2 caps ipv6 kerberos ldap libressl lua lz4 lzma pam postgres sieve sqlite tcpd zlib -argon2 -doc -lucene -managesieve -mysql -selinux -solr -static-libs -suid -textcat -vpopmail)
On 8/15/19 12:01 AM, Eugene wrote:
Hello!
Dovecot uses it's own SASL implementation, doesn't it?
Aug 14 23:45:23 example.com auth[10428]: GSSAPI client step 1 Aug 14 23:45:23 example.com auth[10428]: encoded packet size too big (813804546 > 65536) Aug 14 23:45:23 example.com dovecot[10085]: auth-worker(10428): Error: LDAP: Can't connect to server: ldap://ipa2.example.com Aug 14 23:45:23 example.com dovecot[10085]: auth: Error: auth worker: Aborted USER request for eugene: Lookup timed out Aug 14 23:45:23 example.com dovecot[10085]: imap: Error: auth-master: login: request [3847225345]: Login auth request failed: Internal auth failure (auth connected 60000 msecs ago, request took 60000 msecs, client-pid=10362 client-id=1)
Looks like cyrus-sasl encountered same problem earlier.
https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2017-March/003001.html
I never have such an issue with ldapsearch. So, I assume there is a
similar problem in Dovecot SASL implementation.
-- Eugene Bright IT engineer Tel: + 79257289622
Eugene Bright IT-engineer Tel.: +7 925 728 96 22
I suspect the problem is that dovecot tries to report LDAP error over GSSAPI. So the best fix is to make sure your LDAP server does not return error. =)
Aki
On 15.8.2019 14.56, Eugene Bright wrote:
That's right. GSS-API is not used anywhere else. Do you like to inspect my full configuration? I can dump connection session and send pcap file here.
On August 15, 2019 7:27:20 AM GMT+03:00, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 15/08/2019 00:34 Eugene via dovecot <dovecot@dovecot.org> wrote: The next combination of parameters makes 100% LDAP connections unsuccessful (the log snippet form the previous mail). sasl_bind = yes sasl_mech = gssapi tls = yes Looks like this combination is utterly incorrect and should be prohibited (tls must not be used when mech is gssapi). https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/G7S2TOFDCM62ZUHIBWYVZIEVYXO3KYAI/ With `tls = no` errors `encoded packet size too big` becomes sporadic, but still heart auth orepations performance. May be there are two different problems. Does the "encoded packet size too big" coincide with LDAP server connection failure? Aki Has someone encountered this problem before? How can I help to facilitate the issue debugging? [I] net-mail/dovecot Installed versions: 2.3.7.1(01:58:12 08/14/19)(bzip2 caps ipv6 kerberos ldap libressl lua lz4 lzma pam postgres sieve sqlite tcpd zlib -argon2 -doc -lucene -managesieve -mysql -selinux -solr -static-libs -suid -textcat -vpopmail) On 8/15/19 12:01 AM, Eugene wrote: Hello! Dovecot uses it's own SASL implementation, doesn't it? Aug 14 23:45:23 example.com auth[10428]: GSSAPI client step 1 Aug 14 23:45:23 example.com auth[10428]: encoded packet size too big (813804546 > 65536) Aug 14 23:45:23 example.com dovecot[10085]: auth-worker(10428): Error: LDAP: Can't connect to server: ldap://ipa2.example.com Aug 14 23:45:23 example.com dovecot[10085]: auth: Error: auth worker: Aborted USER request for eugene: Lookup timed out Aug 14 23:45:23 example.com dovecot[10085]: imap: Error: auth-master: login: request [3847225345]: Login auth request failed: Internal auth failure (auth connected 60000 msecs ago, request took 60000 msecs, client-pid=10362 client-id=1) Looks like cyrus-sasl encountered same problem earlier. https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2017-March/003001.html I never have such an issue with ldapsearch. So, I assume there is a similar problem in Dovecot SASL implementation. -- Eugene Bright IT engineer Tel: + 79257289622
Eugene Bright IT-engineer Tel.: +7 925 728 96 22
I see nothing suspicious in FreeIPA slapd logs because connection drops before SASL negotiation completion.
Network analysis shows client sending RST after receiving bindResponse(7) saslBindInProgress.
On 8/15/19 3:07 PM, Aki Tuomi via dovecot wrote:
I suspect the problem is that dovecot tries to report LDAP error over GSSAPI. So the best fix is to make sure your LDAP server does not return error. =)
Aki
On 15.8.2019 14.56, Eugene Bright wrote:
That's right. GSS-API is not used anywhere else. Do you like to inspect my full configuration? I can dump connection session and send pcap file here.
On August 15, 2019 7:27:20 AM GMT+03:00, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 15/08/2019 00:34 Eugene via dovecot <dovecot@dovecot.org> wrote: The next combination of parameters makes 100% LDAP connections unsuccessful (the log snippet form the previous mail). sasl_bind = yes sasl_mech = gssapi tls = yes Looks like this combination is utterly incorrect and should be prohibited (tls must not be used when mech is gssapi). https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/G7S2TOFDCM62ZUHIBWYVZIEVYXO3KYAI/ With `tls = no` errors `encoded packet size too big` becomes sporadic, but still heart auth orepations performance. May be there are two different problems. Does the "encoded packet size too big" coincide with LDAP server connection failure? Aki Has someone encountered this problem before? How can I help to facilitate the issue debugging? [I] net-mail/dovecot Installed versions: 2.3.7.1(01:58:12 08/14/19)(bzip2 caps ipv6 kerberos ldap libressl lua lz4 lzma pam postgres sieve sqlite tcpd zlib -argon2 -doc -lucene -managesieve -mysql -selinux -solr -static-libs -suid -textcat -vpopmail) On 8/15/19 12:01 AM, Eugene wrote: Hello! Dovecot uses it's own SASL implementation, doesn't it? Aug 14 23:45:23 example.com auth[10428]: GSSAPI client step 1 Aug 14 23:45:23 example.com auth[10428]: encoded packet size too big (813804546 > 65536) Aug 14 23:45:23 example.com dovecot[10085]: auth-worker(10428): Error: LDAP: Can't connect to server: ldap://ipa2.example.com Aug 14 23:45:23 example.com dovecot[10085]: auth: Error: auth worker: Aborted USER request for eugene: Lookup timed out Aug 14 23:45:23 example.com dovecot[10085]: imap: Error: auth-master: login: request [3847225345]: Login auth request failed: Internal auth failure (auth connected 60000 msecs ago, request took 60000 msecs, client-pid=10362 client-id=1) Looks like cyrus-sasl encountered same problem earlier. https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2017-March/003001.html I never have such an issue with ldapsearch. So, I assume there is a similar problem in Dovecot SASL implementation. -- Eugene Bright IT engineer Tel: + 79257289622
Eugene Bright IT-engineer Tel.: +7 925 728 96 22
-- Eugene Bright IT engineer Tel: + 79257289622
The error message origins from cyrus-sasl sources. https://github.com/cyrusimap/cyrus-sasl/blob/352b3e66c3712fddc622ee850c35374...
The strange thing is that dovecot is the only sufferer.
Filter tcp.payload contains "\x30\x81\xac\x02" shows that part of the AP-REP is interpreted as packet length.
I will ask cyrus-sasl project for further help.
Sorry for the hassles.
On 8/15/19 4:14 PM, Eugene via dovecot wrote:
I see nothing suspicious in FreeIPA slapd logs because connection drops before SASL negotiation completion. Network analysis shows client sending RST after receiving
bindResponse(7) saslBindInProgress.On 8/15/19 3:07 PM, Aki Tuomi via dovecot wrote:
I suspect the problem is that dovecot tries to report LDAP error over GSSAPI. So the best fix is to make sure your LDAP server does not return error. =)
Aki
On 15.8.2019 14.56, Eugene Bright wrote:
That's right. GSS-API is not used anywhere else. Do you like to inspect my full configuration? I can dump connection session and send pcap file here.
On August 15, 2019 7:27:20 AM GMT+03:00, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 15/08/2019 00:34 Eugene via dovecot <dovecot@dovecot.org> wrote: The next combination of parameters makes 100% LDAP connections unsuccessful (the log snippet form the previous mail). sasl_bind = yes sasl_mech = gssapi tls = yes Looks like this combination is utterly incorrect and should be prohibited (tls must not be used when mech is gssapi). https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/G7S2TOFDCM62ZUHIBWYVZIEVYXO3KYAI/ With `tls = no` errors `encoded packet size too big` becomes sporadic, but still heart auth orepations performance. May be there are two different problems. Does the "encoded packet size too big" coincide with LDAP server connection failure? Aki Has someone encountered this problem before? How can I help to facilitate the issue debugging? [I] net-mail/dovecot Installed versions: 2.3.7.1(01:58:12 08/14/19)(bzip2 caps ipv6 kerberos ldap libressl lua lz4 lzma pam postgres sieve sqlite tcpd zlib -argon2 -doc -lucene -managesieve -mysql -selinux -solr -static-libs -suid -textcat -vpopmail) On 8/15/19 12:01 AM, Eugene wrote: Hello! Dovecot uses it's own SASL implementation, doesn't it? Aug 14 23:45:23 example.com auth[10428]: GSSAPI client step 1 Aug 14 23:45:23 example.com auth[10428]: encoded packet size too big (813804546 > 65536) Aug 14 23:45:23 example.com dovecot[10085]: auth-worker(10428): Error: LDAP: Can't connect to server: ldap://ipa2.example.com Aug 14 23:45:23 example.com dovecot[10085]: auth: Error: auth worker: Aborted USER request for eugene: Lookup timed out Aug 14 23:45:23 example.com dovecot[10085]: imap: Error: auth-master: login: request [3847225345]: Login auth request failed: Internal auth failure (auth connected 60000 msecs ago, request took 60000 msecs, client-pid=10362 client-id=1) Looks like cyrus-sasl encountered same problem earlier. https://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2017-March/003001.html I never have such an issue with ldapsearch. So, I assume there is a similar problem in Dovecot SASL implementation. -- Eugene Bright IT engineer Tel: + 79257289622
Eugene Bright IT-engineer Tel.: +7 925 728 96 22
-- Eugene Bright IT engineer Tel: + 79257289622
participants (3)
-
Aki Tuomi
-
Eugene
-
Eugene Bright