MicrosoftMicrosoftWhat I'm coming to believe, is that the "LDAP Signing Summary" chart 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 think we would have expected connections to fail at that point, which is why there's been such fervor around this. 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, which could be prohibitive to make available at scale. I also suspect that the domain would log an unsigned bind in that case as well.
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 across all my domain controllers 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're actually using it or not.
Awesome.
