I haven't tested this myself yet, but the code that handles MINSSF is the same for ages:

 281     sasl_mech = dp_opt_get_string(state->opts->basic, SDAP_SASL_MECH);
 282     if (sasl_mech != NULL) {
 283         sasl_minssf = dp_opt_get_int(state->opts->basic, SDAP_SASL_MINSSF);
 284         if (sasl_minssf >= 0) {
 285             ber_sasl_minssf = (ber_len_t)sasl_minssf;
 286             lret = ldap_set_option(state->sh->ldap, LDAP_OPT_X_SASL_SSF_MIN,
 287                                    &ber_sasl_minssf);
 288             if (lret != LDAP_OPT_SUCCESS) {
 289                 DEBUG(SSSDBG_CRIT_FAILURE, "Failed to set LDAP MIN SSF option "
 290                                             "to %d\n", sasl_minssf);
 291                 goto fail;
 292             }
 293         }
 294     }

So negative values should not be taken into account. Do you have a system handy with the negative SSF where the setting causes the lookups to fail?

Also, this message:
[sssd[be[LDAP-KRB5]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-6)[Unknown authentication method]
comes either from openldap-libs or cyrus-sasl, so if anything changed, it's not in SSSD, I presume.

I wouldn't treat this as a regression in SSSD...

(In reply to Jakub Hrozek from comment #3)
> I haven't tested this myself yet, but the code that handles MINSSF is the
> same for ages:
> 
>  281     sasl_mech = dp_opt_get_string(state->opts->basic, SDAP_SASL_MECH);
>  282     if (sasl_mech != NULL) {
>  283         sasl_minssf = dp_opt_get_int(state->opts->basic,
> SDAP_SASL_MINSSF);
>  284         if (sasl_minssf >= 0) {
>  285             ber_sasl_minssf = (ber_len_t)sasl_minssf;
>  286             lret = ldap_set_option(state->sh->ldap,
> LDAP_OPT_X_SASL_SSF_MIN,
>  287                                    &ber_sasl_minssf);
>  288             if (lret != LDAP_OPT_SUCCESS) {
>  289                 DEBUG(SSSDBG_CRIT_FAILURE, "Failed to set LDAP MIN SSF
> option "
>  290                                             "to %d\n", sasl_minssf);
>  291                 goto fail;
>  292             }
>  293         }
>  294     }
> 
> So negative values should not be taken into account. Do you have a system
> handy with the negative SSF where the setting causes the lookups to fail?

User lookup works fine and that is the problem. User lookup is expected to fail when ldap_sasl_minssf is set with -ve values, for example -1 or -999. But in rhel7.5, user lookup works and we don't see any error. Thats why we see failures in test suite as the test was designed to fail with -ve values.

> 
> Also, this message:
> [sssd[be[LDAP-KRB5]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed
> (-6)[Unknown authentication method]
> comes either from openldap-libs or cyrus-sasl, so if anything changed, it's
> not in SSSD, I presume.
> 
> I wouldn't treat this as a regression in SSSD...

I am not sure whether its a regression in SSSD but i am sure something has changed, somehwere.

OK, to summarize, what is the problem here, the tools are accepting negative minssf value, that it did not accept before.

Excuse my basic question, but is there any reason why one would like to set this value? It might not make a lot of sense, but even if the minssf value is negative, any positive one that will be negotiated  will be accepted, which might not be necessarily wrong, isn't it? These values behave basically the same as 0, isn't it?

Even though, it might be unwanted or uncomfortable for you as a QE, I don't see this as a regression or anything that would need to be handled ASAP so I would be for removing the Regression tag and moving it to RHEL7.6 release.

The error from LDAP is LDAP_AUTH_UNKNOWN, which is converted from GSSAPI error using map_gsserr2ldap(), most probably in ldap_int_gss_spnego_bind_s(). You are running your tests against RHEL7.4 (last time you were running the RHEL7.3??), which already have the SPNEGO fixed (bug #1421663 in RHEL7.4) and therefore the code might be going through this mechanism, which is handling the ssf in different way.

Can you run the tests once more and generate ldap debug trace logs so we could compare where did the LDAP failed and when it did not?


There is still many unknowns in this topic and I do not consider it as a big issue so I propose to postpone this to the next release, if you agree.

Created attachment 1394603 [details]
SSSD_BE strace files

Created attachment 1394605 [details]
Another SSSD_BE backend trace file.

Tested this case on SSSD Version sssd-1.16.0-16.el7.x86_64

I have attached two trace files with this bug.
1. sssd_be_strace.9448
2. sssd_be_strace.9542

This bug was discussed in the SSSD-QE weekly meeting and we agree on postponing this to the next release. 

Response to why -ve values were tested with minssf:
 - When minssf is kept default, ie no values are assigned to it in sssd.conf and ldap.conf, then the SSSD log always show "[sssd[be[LDAP-KRB5]]] [dp_get_options] (0x0400): Option ldap_sasl_minssf has value -1". 
Ideally default value should be Zero. So whoever from QE wrote the test cases for "minssf" must have presumed that "-1" is the default value and have tested minssf with negative values as well which is not wrong. Negative testing is as important as the positive one's.

The automated tests were working fine till 7.4, but in 7.5 couple of cases failed. So obviously something changed which caused the regression. I also agree that this is not something that need to be fixed ASAP.