All, This is exactly what our cybersecurity team is reporting on. Log event ID 2289 showing up in the AD domain controller logs for Linux clients (using sssd). Upon further research, Microsoft has just released a patch to fix their mis-reporting:
https://support.microsoft.com/en-us/help/4559003/windows-10-update-kb4559003 July 21, 2020—KB4559003 (OS Build 17763.1369). Fix for Windows 10 and Windows Server Here's the exact bugfix (from the above URL): - 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. Spike On Thu, Sep 3, 2020 at 1:46 AM Sumit Bose <sb...@redhat.com> wrote: > On Wed, Sep 02, 2020 at 05:12:45PM -0500, Spike White wrote: > >James, > > > >Really appreciate this detailed answer. Our on-site MS consultant will be > >back next week, we'll have a big conversation next week. > > > >BTW, you reminded me. Our AD team has a few AD DCs configured for this > >proposed "future state" configuration -- which will break the use case #2 > >above. I tested our Linux sssd clients against it, as well as our older > >(commercial product) clients. Both ran fine. > > > >Lawrence, we *are* using the AD provider. internally, the AD provider is > >doing GSSAPI-based SASL LDAP binding by default. We have a mix of RHEL6,7 > >and 8 boxes. > > Hi, > > James is right on spot. About the logged event when using GSSAPI my > colleague Thorsten also asked Microsoft in the Comments to > > https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536/page/5#comments > > There is also https://access.redhat.com/articles/4661861 which is > updated as soon as we have more information to share on this topic. One > of the latest updates here is about LDAPS and channel binding. Here > work on cyrus-sasl, openldap and MIT Kerberos was needed to make the > initial support all those components had work together as expected. > > HTH > > bye, > Sumit > > > > >Spike > > > >On Wed, Sep 2, 2020 at 3:55 PM James Ralston <rals...@pobox.com> wrote: > > > >> On Wed, Sep 2, 2020 at 3:17 PM Spike White <spikewhit...@gmail.com> > wrote: > >> > >> > What cybersecurity is reporting off of is a particular event number > >> > on its AD controllers. which is showing a connection to a LDAP > >> > port. > >> > > >> > Is there another (better) event that it should be looking for > >> > instead? I.e., it should be flagging a simple binding only to an > >> > LDAP port. > >> > >> Unfortunately, there is not. A DC will log this event: > >> > >> The following client performed a SASL > >> (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting > >> signing (integrity verification), or performed a simple bind over > >> a clear text (non-SSL/TLS-encrypted) LDAP connection. > >> > >> …for both of these use cases: > >> > >> 1. An LDAP client uses GSSAPI (instead of GSS-SPNEGO), over a signed > >> and sealed connection. No passwords are transmitted in clear text. > >> > >> 2. An LDAP client performs a simple bind over clear text (without > >> sealing), which passes the bind password on the wire in clear text. > >> > >> If the DCs are configured as per Microsoft’s recommendations to secure > >> LDAP traffic, use case #2 will break. But use case #1 will not. > >> (Others in the big long thread I referenced in my previous message > >> verified this.) > >> > >> At least to my knowledge, no one has figured out a way to sift through > >> these events in the event log and determine which ones (if any) were > >> generated by LDAP clients performing simple binds over clear text > >> (which is undesirable) versus which ones were generated by LDAP > >> clients using GSSAPI (instead of GSS-SPNEGO) over a sealed connection. > >> > >> Alas, Microsoft really should have used two different event types to > >> distinguish these cases. > >> _______________________________________________ > >> 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 >
_______________________________________________ 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
