Arch Linux

Description:

This bug occurs in the GSSAPI module of the Cyrus SASL software, which is provided on Arch via the packages cyrus-sasl and cyrus-sasl-gssapi.

When using GSSAPI authentication via SASL, setting maxssf=0 causes GSSAPI authentication to fail with the error "SASL(-1): generic failure: GSSAPI Error: A required input parameter could not be read (Unknown error)".

Additional info:
* This bug seems to have appeared around upstream version 2.1.24 (current version on Arch is 2.1.26-7) and remains unfixed upstream despite being reported in 2011
* Upstream bug report: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3480
* Fedora downstream bug report, which was resolved by a downstream patch: https://bugzilla.redhat.com/show_bug.cgi?id=984079

I know it's generally not Arch's policy to patch upstream sources when building a package, but in this case it might be worthwhile to patch, since this bug does not look like it will be fixed upstream. I do have a vested interest in seeing this bug patched, as it is currently preventing me from performing administrative duties on my organization's Active Directory server from my Arch workstation (as a workaround, I must log in to a host that does not have the buggy version of SASL or else log in to a Windows box in order to perform admin duties).

Steps to reproduce:

Since I ran into this bug while using OpenLDAP to perform queries against an Active Directory server, using GSSAPI for authentication via SASL, I'm going to give an example using an OpenLDAP tool. The part that triggers the bug here is the "-Omaxssf=0" option, which is required when running LDAP commands over an encrypted connection to an Active Directory server running on Windows Server 2008:

[birdsnest ~][I]% ldapsearch -b "<search base>" -H "ldaps://<ldap server>" "<search parameters>" -Omaxssf=0
SASL/GSSAPI authentication started
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 same command running on a box that does not have the buggy version of SASL (RHEL 6.6 w/ cyrus-sasl-2.1.23-15.el6.x86_64 package):

[pitserver ~]% ldapsearch -b "<search base>" -H "ldaps://<ldap server>" "<search parameters>" -Omaxssf=0
SASL/GSSAPI authentication started
SASL username: <username>@<realm>
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <<search base>> with scope subtree
# filter: <search parameters>
# requesting: ALL
#

<confidential data snipped>

# search result
search: 5
result: 0 Success

# numResponses: 3
# numEntries: 1
# numReferences: 1