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

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?

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.

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

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.

Thanks,
Con.

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

/J

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: https://msdn.microsoft.com/en-us/library/cc223500.aspx

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: https://github.com/michael-o/cyrus-sasl/blob/master/plugins/gssapi.c#L1586-L1596

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

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 */
- req_flags |= GSS_C_MUTUAL_FLAG | GSS_C_SEQUENCE_FLAG;
- /* 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: http://asg.andrew.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=10230

I highly fear that the code cannot be changed that easily because Microsoft screwed up the RFC. The RFC (https://tools.ietf.org/html/rfc4752#section-3.1) 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?

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.
https://cgit.cyrus.foundation/cyrus-sasl/commit/plugins/gssapi.c?id=080e51c7fa0421eb2f0210d34cf0ac48a228b1e9

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.

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.

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.

Just hit the same problem while debugging bug #1576799

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?

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.

Upstream bug: https://github.com/cyrusimap/cyrus-sasl/issues/419

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.

I need to add an important note here:
Even this bug is marked as fixed, the change in Cyrus SASL now breaks RFC 4752. See my comment: https://github.com/cyrusimap/cyrus-sasl/issues/419#issuecomment-566981689

Technically, one would now need to create an issue in Launchpad that Cyrus SASL GSSAPI mech is broken.