On Mon, Oct 12, 2020 at 11:25 AM Spike White <spikewhitetx@gmail.com> wrote:

> I believe our older sssd clients (RHEL 6) cannot do gss-spnego auth
> mech.  Only our newer RHEL7 and RHEL8 clients can do gss-spnego.

Correct.

sssd relies on the Cyrus SASL library to perform the authentication,
and the RHEL6 version of Cyrus SASL only supports GSSAPI, not
GSS-SPNEGO.  So supporting GSS-SPNEGO on RHEL6 requires backporting
code to Cyrus SASL.

Since RHEL6 has been in maintenance phase 2 support (security fixes
and critical bugfixes only) for years, and since RHEL6 exits
maintenance phase 2 support on 2020-11-30 (effectively making RHEL6
EOL for anyone without an ELS license), there is essentially zero
chance Red Hat will backport GSS-SPNEGO support to the RHEL6 Cyrus
SASL.

> So while we can satisfy MS' stricter requirement of SASL bindings
> with SSF >= 2, the AD admins will still see events 2889 in their DC
> logs.  Certainly for our older clients.
>
> I don't fully understand this claim of SSF == 256 for GSSAPI.
>
> SSF == 0 is supposed to be no protection, SSF = 1 is supposed to be
> basic integrity checking only, >1 – Supports authentication,
> integrity and confidentiality.
>
> https://ldapwiki.com/wiki/Security%20Strength%20Factor
>
> I thought signing was what gave you integrity checking.  To prevent
> man-in-the middle attacks.  If so, how can GSSAPI claim SSF == 256,
> since it's not doing signing?

I think the issue is that encrypting the communication (providing
confidentiality, or “sealing” in GSSAPI parlance) is not the same
thing as performing LDAP signing:

    https://ldapwiki.com/wiki/LDAP%20Signing

I suspect only GSS-SPNEGO performs LDAP signing, even though GSSAPI
provides both integrity checking and confidentiality.

> Otherwise, if you can get integrity checking without signing and our
> GSSAPI bindings are strongly encrypted (they are), how could a man
> in the middle insert their own code into the packet?  I..e, how
> important is signing really, if we're strongly encrypted?

Perhaps there is a concern that replay attacks (using the encrypted
payload) might be possible without LDAP signing, even if you cannot
decrypt the encrypted payload?

> PS Best would be if MS had broken out insecure LDAP binding and
> unsigned SASL bindings into 2 different events.  What the AD team
> *really* wants to eradicate is simple LDAP bindings (i.e., user
> name/password supplied in clear text).  However, it's hard to
> distinguish between that and our (sssd-initiated) GSSAPI SASL
> bindings -- AD team is just looking for event 2889 in their logs.

Absolutely, yes.  Even if there is some risk to using GSSAPI instead
of GSS-SPNEGO (e.g., if GSSAPI is potentially vulnerable to replay
attacks), that is negligible compared to the risk of clients
performing LDAP binds using passwords that are sent in clear text on
the wire (i.e., using LDAP instead of LDAPS).

By reporting both types of events using the same event ID, Microsoft
has made it all but impossible to detect the latter types of events,
based on all of the noise that the former types of events generate.
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org