michael@stroeder.com wrote:

Full_Name: Version: 2.4.46 OS: openSUSE Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.240.182.29)

SASL bind with SCRAM-SHA-1 does not return invalidCredentials (49) in case of a wrong password being used while DIGEST-MD5 and other password mechs works as expected.

This might lead to different error handling in client applications if the user input a wrong password.

This proves SCRAM-SHA-1 is enabled and working:

$ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w test123 SASL/SCRAM-SHA-1 authentication started SASL username: test42 SASL SSF: 0 dn:uid=test42,ou=testing,dc=stroeder,dc=de

But wrong password returns other(80) as result code:

$ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w wrong SASL/SCRAM-SHA-1 authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-5): bad protocol / cancel: StoredKey mismatch

Now testing DIGEST-MD5:

$ ldapwhoami -Y DIGEST-MD5 -U test42 -w test123 SASL/DIGEST-MD5 authentication started SASL username: test42 SASL SSF: 128 SASL data security layer installed. dn:uid=test42,ou=testing,dc=stroeder,dc=de

Wrong password returns invalidCredentials(49) as expected:

$ ldapwhoami -Y DIGEST-MD5 -U test42 -w wrong SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated (tried bogus)

Sounds like this is an issue for the Cyrus SASL project. Their plugin is returning a SASL_BADPROT error code on all failures, instead of a more meaningful code like SASL_BADAUTH.

Closing this ITS.