sb_sasl_generic_pkt_length: received illegal packet length when using Active Directory and ldapsearch and sasl with ssl or tls

Bug #1015819 reported by Michael Heldebrant on 2012-06-20
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Fix Released
cyrus-sasl2 (Ubuntu)

Bug Description


Awaiting upstream fix.




Not sure if this is a problem with openldap or cyrus-sasl2 at this point.

Using sasl binding only works with ldapsearch when not using ssl or tls. If either ssl or tls is used I see this ouput from -d 1 from ldapsearch:

sb_sasl_generic_pkt_length: received illegal packet length of 813957120 bytes
sasl_generic_read: want=16, got=16
  0000: 00 7e 02 01 00 78 84 00 00 00 5d 0a 01 02 04 00 .~...x....].....
sb_sasl_cyrus_decode: failed to decode packet: generic failure
sb_sasl_generic_read: failed to decode packet
ldap_read: want=8 error=Input/output error

# numResponses: 0
ldap_result: Can't contact LDAP server (-1)
tls_write: want=165 error=Connection reset by peer
tls_write: want=165 error=Bad file descriptor

Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Please could you explain the impact of this bug? Are you saying that openldap cannot work with SSL or TLS at all, or is there a workaround? Can openldap be used with something other than cyrus-sasl2 for SSL/TLS support?

Changed in cyrus-sasl2 (Ubuntu):
status: New → Incomplete
Michael Heldebrant (mheldebr) wrote :

I can't use GSSAPI via sasl to receive data from the ldap server if SSL or TLS is used as I get illegal packet length errors as reported. Non encrypted ldap is working with no issues using GSSAPI authentication.

Robie Basak (racb) on 2012-06-22
Changed in cyrus-sasl2 (Ubuntu):
status: Incomplete → New
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cyrus-sasl2 (Ubuntu):
status: New → Confirmed
Con Harte (con-j-harte) wrote :

Is there any update on this bug?

I have done some testing, and it seems that I can successfuly use SSL/TLS connections to an LDAP server (both over port 636 for LDAPS and port 389 with STARTTLS) when I use the DIGEST-MD5 SASL mechanism.

This seems to indicate that it is specifically a problem with libsasl2-modules-gssapi-mit - I'm currently using version 2.1.25.dfsg1-3ubuntu0.1 in Ubuntu 12.04LTS.

This issue is causing us a lot of problems, if anyone knows of a workaround or better yet, a fix, please let me know.


Robie Basak (racb) on 2013-03-25
description: updated

This has to do with "Active Directory" not supporting nested security or privacy layers.
To make it work you need to set "sasl_secprops minssf=0,maxssf=0" in /etc/openldap/ldap.conf


Michael Osipov (michael-o) wrote :

I can confirm that this bug is still present in the most recent versions of OpenLDAP and SASL. Johnny Westerlund's statement is correct but the tip isn't.

Here is the deal:

Active Directory does not support GSS-API integrity/confidentiality over TLS encrypted sockets. Unfortumately, you cannot disable integrity in SASL. It is enabled by default. maxssf=0 does not work and gives you: ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: A required input parameter could not be read (Unknown error)

Here is the code in question:

FWIT: This fails on RHEL, FreeBSD and HP-UX, it fails everywhere with MIT Kerberos.

Michael Osipov (michael-o) wrote :

Here is a follow on the comment above:

I have changes the GSSAPI mech plugin source code:

diff --git a/plugins/gssapi.c b/plugins/gssapi.c
index 2fd1b3b..39302cd 100644
--- a/plugins/gssapi.c
+++ b/plugins/gssapi.c
@@ -1583,20 +1583,9 @@ static int gssapi_client_mech_step(void *conn_context,

        /* Setup req_flags properly */
- req_flags = GSS_C_INTEG_FLAG;
- if (params->props.max_ssf > params->external_ssf) {
- /* We are requesting a security layer */
- /* Any SSF bigger than 1 is confidentiality. */
- /* Let's check if the client of the API requires confidentiality,
- and it wasn't already provided by an external layer */
- if (params->props.max_ssf - params->external_ssf > 1) {
- /* We want to try for privacy */
- req_flags |= GSS_C_CONF_FLAG;
- }
- }
- if (params->props.security_flags & SASL_SEC_PASS_CREDENTIALS) {
+ req_flags = GSS_C_MUTUAL_FLAG;
+ if (params->props.security_flags & SASL_SEC_PASS_CREDENTIALS) {
            req_flags = req_flags | GSS_C_DELEG_FLAG;

And reran ldapsearch with -ZZ (STARTTLS) and whom, it did work. I tried without TLS too. Everything is shiny in Wireshark. TLS encrypted data, fully opaque, unencrypted data, fully browsable.

This code definitively requires polish as long as the SASL RFC is not violated. I am willing to provide a quality patch for that. Unfortunately, I have another patch pending on the Cyrus SASL mailing list w/o any response at the moment. Maybe someone could step up:

Michael Osipov (michael-o) wrote :

I highly fear that the code cannot be changed that easily because Microsoft screwed up the RFC. The RFC ( says:

3.1. Client Side of Authentication Protocol Exchange

   The client calls GSS_Init_sec_context, passing in
   input_context_handle of 0 (initially), mech_type of the Kerberos V5
   GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
   equal to output_name from GSS_Import_Name called with input_name_type
   of GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server. When calling the GSS_Init_sec_context, the
   client MUST pass the integ_req_flag of TRUE (**). If the client will
   be requesting a security layer, it MUST also supply to the
   GSS_Init_sec_context a mutual_req_flag of TRUE, and a
   sequence_req_flag of TRUE. If the client will be requesting a
   security layer providing confidentiality protection, it MUST also
   supply to the GSS_Init_sec_context a conf_req_flag of TRUE. The
   client then responds with the resulting output_token. If
   GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
   should expect the server to issue a token in a subsequent challenge.
   The client must pass the token to another call to
   GSS_Init_sec_context, repeating the actions in this paragraph.

The Cyrus SASL implementation is correct and Microsoft's is not! Any thoughts?

Leif Thuresson (leif-thuresson) wrote :

The workaround proposed by Johnny Westerlund on 2015-05-06
works in cyrus-sasl-2.1.23 but not in the latest version 2.1.26.

Looks like it is this commit that cause the workaround to stop working.

Michael Osipov (michael-o) wrote :

Leif, the commit is perfectly fine because minssf=0 is illegal and violates the RFC. I have described this in my previous comment.

Yes I didn't mean the commit was wrong. The problem is MS-AD, but before the commit it was possible to do LDAP SASL bind over an SSL/TLS connection to AD if you set min and max SSF below or equal to 128 (doesn't need to be zero).
So it would be nice to have some sort of AD compatibility mode. I think it would be okay for this mode to not follow the RFC as long as it is not the default operating mode and it is properly documented.

Michael Osipov (michael-o) wrote :

Leif, I do agree here but this has to be a new SASL property and fixed with Cyrus SASL. At best, one contacts the Cyrus SASL mailing list.

Robie Basak (racb) wrote :

Thank you for figuring this out! I guess we need to see how upstream wants to address the issue before we can address it in Ubuntu? Given the root cause, it seems to me that it would only be appropriate for Ubuntu to do what upstream does here to fix it.

description: updated
Changed in cyrus-sasl2 (Ubuntu):
status: Confirmed → Triaged
summary: sb_sasl_generic_pkt_length: received illegal packet length when using
- ldapsearch and sasl with ssl or tls
+ Active Directory and ldapsearch and sasl with ssl or tls
Andreas Hasenack (ahasenack) wrote :

Just hit the same problem while debugging bug #1576799

Andrey Arapov (andrey-arapov) wrote :

Exact same error here in 2019.
I set Windows Server 2019 up, default AD DS & AD CS (for TLS).

Clients tried:
Ubuntu 18.04: libsasl2-modules-gssapi-mit:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2
Alpine Edge: cyrus-sasl-gssapiv2-2.1.27-r1

Have anyone tried asking in Cyrus SASL mailing list?

Andrey Arapov (andrey-arapov) wrote :

Thank you, Johnny Westerlund!
At least adding "sasl_secprops minssf=0,maxssf=0" to /etc/openldap/ldap.conf works around the error, so things seem to work for me.

Not sure whether it is different now for Michael Osipov.

Andreas Hasenack (ahasenack) wrote :

Given the upstream bug status and version where it was fixed, we believe this is fixed in the upcoming Ubuntu Disco release:

 cyrus-sasl2 | 2.1.27+dfsg-1 | disco | source

It will therefore be marked as "fix released", but I will open a task for bionic and cosmic.

Changed in cyrus-sasl2 (Ubuntu Bionic):
status: New → Triaged
Changed in cyrus-sasl2 (Ubuntu Cosmic):
status: New → Triaged
Changed in cyrus-sasl2 (Ubuntu Bionic):
importance: Undecided → Medium
Changed in cyrus-sasl2 (Ubuntu Cosmic):
importance: Undecided → Medium
Changed in cyrus-sasl2 (Ubuntu):
status: Triaged → Fix Released
Changed in cyrus-sasl2:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.