Bug 1421663 - support proper SASL GSS-SPNEGO in CyrusSASL
Summary: support proper SASL GSS-SPNEGO in CyrusSASL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cyrus-sasl
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Namita Soman
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: 1181853 1345975
TreeView+ depends on / blocked
 
Reported: 2017-02-13 11:54 UTC by Alexander Bokovoy
Modified: 2017-08-01 20:56 UTC (History)
5 users (show)

Fixed In Version: cyrus-sasl-2.1.26-21
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2017-08-01 20:56:22 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2034 normal SHIPPED_LIVE cyrus-sasl bug fix update 2017-08-01 18:34:43 UTC

Description Alexander 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.

Comment 3 Jakub Jelen 2017-03-06 07:33:02 UTC
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

Comment 12 errata-xmlrpc 2017-08-01 20:56:22 UTC
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


Note You need to log in before you can comment on or make changes to this bug.