Yes, correct.  So that MS hotfix:

is for W2019.  

But with the equiv hotfix for W2016 and W2012, event 2889 triggers (in the AD DC logs) for GSSAPI-based SASL bindings.  (It does not trigger for GSS-SPNEGO-based SASL bindings).

However, GSSAPI bindings are accepted when MS' ssf >= 2 recommendation is enforced.  So yes, the true behavior and the reporting do not agree with each other.

Spike

On Tue, Oct 13, 2020 at 2:16 AM Sumit Bose <sbose@redhat.com> wrote:
On Mon, Oct 12, 2020 at 10:25:30AM -0500, Spike White wrote:
>All,
>
>Still working with our AD team, trying to implement Microsoft's AD edict to
>only allow LDAP SASL bindings with a security strength factor of 2 or
>greater.
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1793709
>
>
>So I realize (now) that sssd's default GSSAPI SASL binding does not do
>signing.  Whereas, the GSS-SPNEGO authentication mechanism does.  Both
>authentication mechanisms claim a SSF of 256.  So both are accepted by AD
>DCs enforcing MS' stricter policy.  (We have verified this by hard-coding
>sssd clients to AD DCs thus configured).
>
>Even with the new hotfix that Microsoft released in July, the AD DCs still
>report event 2889 (insecure LDAP binding or unsigned LDAP binding) for
>GSSAPI SASL bindings.  They do not report event 2889 for GSS-SPNEGO SASL
>bindings.

Hi,

thanks for letting us know that there are still 2889 messages even with
the latest hotfix. Just to be on the safe side, you are talking about
https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003
where it is said "Addresses an issue that incorrectly reports
Lightweight Directory Access Protocol (LDAP) sessions as unsecure
sessions in Event ID 2889. This occurs when the LDAP session is
authenticated and sealed with a Simple Authentication and Security Layer
(SASL) method."

I still think this is a false-positive message and should be fix on the
Microsoft side. My reasoning is that if you enforce/require signing on
the server side by setting 'LDAPServerIntegrity' to '2' the server must
reject unsigned connections. Since it does not reject a GSSAPI
connecting it must be valid and in agreement with the server-side
security settings.

Since the 2889 message and the acceptance of the connection contradicts
each other this means that either the message is a false-positive (which
I believe) or an unsigned connection is accepted although the server is
configured not to do so (which would be really bad since the client can
claim anything and it is up to the server to properly check if all
requirements are met).

bye,
Sumit

>
>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.
>
>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?
>
>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?
>
>Just trying to gauge if it's worth the work effort to convert all our
>new'ish sssd client to gss-spnego, or leave them at (default) gssapi.
>
>Spike
>
>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.

>_______________________________________________
>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
_______________________________________________
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