[SSSD-users] Advantages of signed SASL bindings vs unsigned SASL bindings....

[Spike White]

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.

https://bugzilla.redhat.com/show_bug.cgi?id=1793709


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.

https://ldapwiki.com/wiki/Security%20Strength%20Factor

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.