Yes, correct. So that MS hotfix:
- 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. 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 <sb...@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-le...@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-le...@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-le...@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
