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/l...
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.
Awesome.
Todd
-----Original Message-----
From: James Ralston <ralston(a)pobox.com
Sent: Thursday, February 13, 2020 3:50 PM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: sssd 1.16.4. ADV190023.
On Thu, Feb 13, 2020 at 10:24 AM Mote, Todd
<moter@austin.utexas.edu<mailto:moter@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-leave@lists.fedorahosted.org<mailto:sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
List Guidelines:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
List Archives:
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
> This message is from an external sender. Learn more about why
this <<