SASL 2.1.27 rc8

Carson Gaspar carson at
Thu May 10 21:05:33 EDT 2018

On 5/10/2018 5:28 PM, Ken Murchison wrote:
> The primary reason for this candidate is to revert the GSSAPI flag 
> changes.  I'd like to roll out the final release early next week, so 
> please test this RC as soon as possible.

I can confirm that rc8 behaves as well/badly as the RedHat patched 
version when connecting to an AD LDAP server. i.e. when using TLS and 
GSSAPI, one must set maxssf for it to work. So it at least isn't a step 

I'm not sure that negotiated SSF is working as intended, however, unless 
code changes to the client are required. openldap-2.4.45 linked with rc8 
example without maxssf, showing an enctype of aes256 but SSF of 56:

$ KRB5_TRACE=/dev/stdout /var/tmp/cyrus-sasl/bin/ldapsearch -Y GSSAPI 
-LLL -H ldaps://XXXX:636 -b 'XXX"
SASL/GSSAPI authentication started
[138314] 1526000107.192106: ccselect can't find appropriate cache for 
server principal ldap/XXX@
[138314] 1526000107.192208: Getting credentials gaspar at XXX -> ldap/XXX@ 
using ccache FILE:/tmp/krb5cc_XXX
[138314] 1526000107.192288: Retrieving gaspar at XXX -> ldap/XXX@ from 
FILE:/tmp/krb5cc_XXX with result: 0/Success
[138314] 1526000107.192363: Creating authenticator for gaspar at XXX -> 
ldap/XXX@, seqnum 811872038, subkey aes256-cts/8D75, session key 
[138314] 1526000107.193939: Read AP-REP, time 1526000107.192369, subkey 
aes256-cts/BB06, seqnum 497881342
SASL username: gaspar at XXX
SASL data security layer installed.
ldap_result: Can't contact LDAP server (-1)

If I pass in -O maxssf=[0..256] while using TLS, it works, and I get:


If I pass in no maxssf option or -O maxssf=[0..256] while not using TLS, 
it works, and I get:


More information about the Cyrus-devel mailing list