Hide Forgot
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.
For the record, the pull request was submitted upstream by Simo and is now merged into the master: https://github.com/cyrusimap/cyrus-sasl/pull/424
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2034