we need to support GSS-SPNEGO in CyrusSASL in order to even start
testing Global Catalog service for FreeIPA. Windows clients always use
SASL GSS-SPNEGO when talking to LDAP and Global Catalog so without
CyrusSASL supporting it there is no way to test in real environment.

For references, here is Simo's quote from GSS-NTLMSSP site:
----------
Cyrus-sasl's GSS-SPNEGO support is equally broken with GSS-NTLMSSP, the
actual authentication works fine, but then it fails to correctly
negotiate the SASL SSF properties due again to the incorrect assumption
that the authentication negotiation always terminates with the last
message being sent from the server to the client. In NTLMSSP usually the
last message is from the client back to the server.
----------

Micheal Brown hacked up a build last year at devconf.cz'16 which
improved CyrusSASL GSS-SPNEGO for Kerberos-based creds:
-----------------
I've been hacking with FreeIPA trying to get Windows to connect and perform
LDAP queries.  I've finally managed to hack cyrus-sasl to accept the
GSS-SPNEGO (with Kerberos credentials) that Windows provides.  This is
currently a hideously ugly hack.  In the "/* Switch to ssf negotation */" in
gssapi_server_mech_authneg(), I added;

  if ( is_spnego ) {
        text->state = SASL_GSSAPI_STATE_AUTHENTICATED;
        ret = SASL_OK;
        oparams->encode = &gssapi_privacy_encode;
        oparams->decode = &gssapi_decode;
        oparams->mech_ssf = K5_MAX_SSF;
        _plug_decode_init(&text->decode_context,
                      text->utils,
                      (params->props.maxbufsize > 0xFFFFFF) ? 0xFFFFFF :
                      params->props.maxbufsize);
  }

i.e. taking the code to finish setting up the SASL encoding/decoding from
gssapi_server_mech_ssfreq() and dumping it into gssapi_server_mech_authreq()
if this is using SPNEGO.

This enables Windows' ldp.exe to bind and query the LDAP server.

I'd like to turn this into a proper fix for cyrus-sasl, but I don't know
enough about the architecture of SASL/GSSAPI/SPNEGO.  Could you give me any
hints on how a proper fix ought to be structured?
-----------------

To test potential fix on the server side, stand up FreeIPA with trust to AD and try to access FreeIPA LDAP server from Windows machine using ldp.exe. I can provide a test environment.