On Fri, Feb 14, 2020 at 02:46:34PM +0000, Mote, Todd wrote: > I saw the same results in the traces I sent Sumit yesterday. What I'm coming > to believe, is that this chart: > > > > [cid:image001.png@01D5E30D.278BEFE0] > > > > From here > https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-update/ba-p/921536 > > > > Seems to show that regardless of how the domain is set, i.e. requiring > signing or not, if you’re employing local encryption, via GSSAPI, or SSL, the > connection will succeed. And is technically encrypted, so satisfies the > security requirements, but Microsoft still logs on the domain that the > connection was made without signing. > > > > Admittedly, that’s not what, I think, everybody expected to happen when you > “Require signing” on the domain and you don’t sign on the client. I would > have expected connections to fail at that point. But given that GSS-SPNEGO > is only available on RHEL 7.2ish + and not on RHEL 6, and likely similarly > aged distros, requiring signing, and not allowing that 5th option would have > basically broken an entire operating system, or more. I also suspect that > Macs are in a similar state. Using the -ssl switch on the dsconfigad utility > sets it to “line 4” in the chart, but requires, just like it would for RHEL > additional certificates be made available to every install. I have seen > similar commands for dsconfigad like, dsconfigad -packetsign require, but > it’s only available in 10.5 and later, which is probably about the time > GSS-SPNEGO was added to RHEL 7, I suspect. > > > > So when I look in splunk and have it count the number of unsigned binds in > the last 24 hours and see a number like 2,518,239. I can’t assume that all > those are insecure. What I can’t tell from that is how many of those are > using GSSAPI or SSL, because they are logged as unsigned whether they use it > or not.
Hi, thank you both for the traces. I did similar tests locally and got the same results. I agree there is something odd with GSSAPI because even if both channel binding and LDAP signing is enforced the GSSAPI requests work as expected but you get the event log message as well. You can force to make GSSAPI fail by lowering the SSF, since LDAP signing (integrity) is already available with SSF 1 you have to set it to 0: # LDAPSASL_SECPROPS=maxssf=1 ldapsearch -H ldap://ad1.win2016.test -Y GSSAPI -b 'DC=win2016,DC=test' samaccountname=Administrator DN -LLL SASL/GSSAPI authentication started SASL username: administra...@win2016.test SASL SSF: 1 SASL data security layer installed. dn: CN=Administrator,CN=Users,DC=win2016,DC=test # refldap://ForestDnsZones.win2016.test/DC=ForestDnsZones,DC=win2016,DC=test # refldap://sub1.win2016.test/DC=sub1,DC=win2016,DC=test # refldap://DomainDnsZones.win2016.test/DC=DomainDnsZones,DC=win2016,DC=test # refldap://win2016.test/CN=Configuration,DC=win2016,DC=test # LDAPSASL_SECPROPS=maxssf=0 ldapsearch -H ldap://ad1.win2016.test -Y GSSAPI -b 'DC=win2016,DC=test' samaccountname=Administrator DN -LLL SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Strong(er) authentication required (8) additional info: 00002028: LdapErr: DSID-0C090200, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v3839 So if there is really no LDAP signing/integrity the request is rejected by AD as expected. I have see you took part in the discussion at https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-update/ba-p/921536/page/4#comments so maybe Microsoft can shed some light on this. I'm inspecting the network packets in the GSSAPI case with a co-worker and he was able to spot a flag in one of the packets send by the AD DC during the SASL/GSSAPI handshake which looked odd. We are trying to investigate further in this direction. bye, Sumit > > > > Awesome. > > > > Todd > > > > > > > > -----Original Message----- > From: James Ralston <rals...@pobox.com> > Sent: Thursday, February 13, 2020 3:50 PM > To: End-user discussions about the System Security Services Daemon > <sssd-users@lists.fedorahosted.org> > Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023. > > > > On Thu, Feb 13, 2020 at 10:24 AM Mote, Todd > <mo...@austin.utexas.edu<mailto:mo...@austin.utexas.edu>> wrote: > > > > > Only using GSSAPI causes the unsigned SASL event. > > > > > > root@anti-test:~ # ldapsearch -H ldap://dc01a.ADTEST.domain.com -Y > > > GSSAPI -b '' -s base SASL/GSSAPI authentication started SASL username: > > > ANTI-TEST$@ADTEST.domain.com<mailto:ANTI-TEST$@ADTEST.domain.com> SASL SSF: > > 256 SASL data security layer > > > installed. > > > # extended LDIF > > > # > > > # LDAPv3 > > > # base <> with scope baseObject > > > # filter: (objectclass=*) > > > # requesting: ALL > > > > > > GSS-SPNEGO looks the same, and does not trigger the unsigned event. > > > > > > root@anti-test:~ # ldapsearch -H ldap://dc01a.ADTEST.domain.com -Y > > > GSS-SPNEGO -b '' -s base SASL/GSS-SPNEGO authentication started SASL > > > username: ANTI-TEST$@ADTEST.domain.com<mailto:ANTI-TEST$@ADTEST.domain.com> > > SASL SSF: 256 SASL data > > > security layer installed. > > > # extended LDIF > > > # > > > # LDAPv3 > > > # base <> with scope baseObject > > > # filter: (objectclass=*) > > > # requesting: ALL > > > > We see the exact same thing on our RHEL7 hosts. > > > > Looking at the packet traces of "-Y GSSAPI" and "-Y GSS-SPNEGO", both > connections issue the query under SASL GSS-API Privacy. But with GSSAPI, it > takes 3 steps to complete the bind request and activate SASL GSS-API Privacy: > > > > bindRequest(1) "<ROOT>" sasl > > bindResponse(1) saslBindInProgress > > bindRequest(2) "<ROOT>" sasl > > bindResponse(2) saslBindInProgress > > bindRequest(3) "<ROOT>" sasl > > bindResponse(3) success > > SASL GSS-API Privacy: payload (148 bytes) > > SASL GSS-API Privacy: payload (160 bytes) > > SASL GSS-API Privacy: payload (7 bytes) > > > > With GSS-SPNEGO, it takes only one step: > > > > bindRequest(1) "<ROOT>" sasl > > bindResponse(1) success > > SASL GSS-API Privacy: payload (148 bytes) > > SASL GSS-API Privacy: payload (160 bytes) > > SASL GSS-API Privacy: payload (7 bytes) > > > > Our Windows admins confirm that the GSSAPI query triggers this warning: > > > > 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. > > > > …but the GSS-SPNEGO query does not. > > > > Sumit, in a moment I'll reply just to you, and include the packet traces. > > _______________________________________________ > > sssd-users mailing list -- > sssd-users@lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org> > To unsubscribe send an email to > sssd-users-le...@lists.fedorahosted.org<mailto:sssd-users-le...@lists.fedorahosted.org> > > Fedora Code of Conduct: > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cb33492d6a04642f0030108d7b0ceeda9%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172275243777155&sdata=brHG9rgWPcHAGkaXTuRuPQ1WCA3rCM2XCm8jcVh1fQs%3D&reserved=0 > > List Guidelines: > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cb33492d6a04642f0030108d7b0ceeda9%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172275243777155&sdata=N8MEXQPwUhVVDSc8WxLZaUeEmz0iafIM5k7YfvkMytc%3D&reserved=0 > > List Archives: > https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedorahosted.org%2Farchives%2Flist%2Fsssd-users%40lists.fedorahosted.org&data=02%7C01%7Cmoter%40austin.utexas.edu%7Cb33492d6a04642f0030108d7b0ceeda9%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C1%7C0%7C637172275243777155&sdata=0QsDay4eL%2FuFX%2BDdX9eQ9SP8ckfI%2B90QQ%2BqcHofrOTY%3D&reserved=0 > > >> This message is from an external sender. Learn more about why this << > > >> matters at https://links.utexas.edu/rtyclf. << > _______________________________________________ > 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
