SPNEGO in Cyrus SASL is now compatible with Microsoft Windows
Prior to this update, the Red Hat Enterprise Linux implementation of Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) in Cyrus Simple Authentication and Security Layer (SASL) was not compatible with the Microsoft Windows counterpart. As a consequence, the Red Hat Enterprise Linux tools using the _cyrus-sasl_ packages were not able to use SPNEGO when attempting to connect to Windows services. These tools were also not able to accept connections from Windows clients. The _cyrus-sasl_ packages have been fixed, and SPNEGO in the Red Hat Enterprise Linux Cyrus SASL version is now compatible with the Microsoft Windows counterpart.
DescriptionAlexander Bokovoy
2017-02-13 11:54:36 UTC
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.
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
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.