I've been experiencing similar behavior for months now and can confirm this
is indeed a problem with SASL library. I've been doing unencrypted LDAP
binds as a workaround.
My ldap_uri, in both ldap.conf and sssd.conf, looks like this:
ldap_uri = ldaps://<Server 2008 DC>:636/
The ldapsearch I'm using looks like this:
ldapsearch -H ldaps://server.domain.local:636/ -Y GSSAPI -N -b
"dc=domain,dc=local"
"(&(objectClass=user)(sAMAccountName=Administrator))"
In my experience, playing around the minsff and maxsff arguments of the
SASL_SECPROPS option in ldap.conf does solve the problem, but only if the
maxsff argument is defined. In otherwords, when using ldapsearch, this will
produce the "encoded packet size too big" error:
SASL_SECPROPS minssf=128
but this won't:
SASL_SECPROPS maxsff=128
likewise, this won't either:
SASL_SECPROPS minsff=128,maxsff=128
I'm assuming that 128 is the highest level that is available, so I haven't
tested an integer above that.
I've also discovered that, despite the settings in ldap.conf, SSSD doesn't
seem to respect the maxsff=128 setting and thus, ldaps binds fail. I
imagine a workaround would be to add a ldap_sasl_maxsff option to SSSD, but
that's something more for the sssd-devel mailing list.
Hope this helps.
-Chris
On Tue, Sep 4, 2012 at 2:03 PM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
On Tue, Sep 04, 2012 at 05:50:08PM +0000, Wojtak, Greg (Superfly)
wrote:
> I am not specifying a schema but verified that sssd is using ldaps:// -
> tcpdump and netstat show connections to my DC's on port 636 and none on
> 389.
>
Interesting, what is the exact format of ldap_uri you are using in the
sssd.conf config file?
Are you using GSSAPI? (ldap_sasl_mech = GSSAPI in the config file)
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users