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.
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.
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.
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.