11 a.m.
Every once in a while with SSSD, we run into a problem where we aren't able to get
user information or authenticate users. We are using ldap/kerberos against an Active
Directory set up over SSL (LDAPS) and we see the following message in the logs:
encoded packet size too big (813957100 > 16777215)
From what I've been able to gather, this is something to do with
the cyrus-sasl package. I've also seen this error pop up when doing operations with
the openldap-clients (ldapsearch, ldapmodify). I've found that by specifying the
minssf and maxssf values in the ldap* operations that the operations would then succeed.
I'm wondering if the same type of fix would work for SSSD? Is there a way to specify
the SSF of the SASL operations that SSSD uses? Is there another workaround for this?
Greg Wojtak
Sr. Unix Systems Engineer
Office: (313) 373-4306
Cell: (734) 718-8472
11:17 a.m.
On Tue, Sep 04, 2012 at 04:00:57PM +0000, Wojtak, Greg (Superfly) wrote:
Every once in a while with SSSD, we run into a problem where we
aren't able to get user information or authenticate users. We are using ldap/kerberos
against an Active Directory set up over SSL (LDAPS) and we see the following message in
the logs:
encoded packet size too big (813957100 > 16777215)
Hi Greg,
are you using ldap:// or ldaps:// schema to connect to the AD server?
If you are getting the same error with ldapsearch & friends, then the
issue is not inside SSSD. This error happens when the AD issues a PAC
that is too big for the SASL library to handle -- the PAC contains
information about users and groups as well and might grow in a very
large organization.
From what I've been able to gather, this is something to do with
the cyrus-sasl package. I've also seen this error pop up when doing operations with
the openldap-clients (ldapsearch, ldapmodify). I've found that by specifying the
minssf and maxssf values in the ldap* operations that the operations would then succeed.
I'm wondering if the same type of fix would work for SSSD? Is there a way to specify
the SSF of the SASL operations that SSSD uses? Is there another workaround for this?
You can use the ldap_sasl_minssf option to fine-tune the SSF. The code
path that uses the option value is the same as openldap-clients
utilities use, so if you were able to find a value that works for you
with ldapsearch, then the same should work with the SSSD, too.
12:50 p.m.
On 2012-09-04 12:17 PM, "Jakub Hrozek" <jhrozek(a)redhat.com> wrote:
On Tue, Sep 04, 2012 at 04:00:57PM +0000, Wojtak, Greg (Superfly)
wrote:
> Every once in a while with SSSD, we run into a problem where we aren't
>able to get user information or authenticate users. We are using
>ldap/kerberos against an Active Directory set up over SSL (LDAPS) and we
>see the following message in the logs:
>
> encoded packet size too big (813957100 > 16777215)
>
Hi Greg,
are you using ldap:// or ldaps:// schema to connect to the AD server?
If you are getting the same error with ldapsearch & friends, then the
issue is not inside SSSD. This error happens when the AD issues a PAC
that is too big for the SASL library to handle -- the PAC contains
information about users and groups as well and might grow in a very
large organization.
> From what I've been able to gather, this is something to do with the
>cyrus-sasl package. I've also seen this error pop up when doing
>operations with the openldap-clients (ldapsearch, ldapmodify). I've
>found that by specifying the minssf and maxssf values in the ldap*
>operations that the operations would then succeed.
>
> I'm wondering if the same type of fix would work for SSSD? Is there a
>way to specify the SSF of the SASL operations that SSSD uses? Is there
>another workaround for this?
>
You can use the ldap_sasl_minssf option to fine-tune the SSF. The code
path that uses the option value is the same as openldap-clients
utilities use, so if you were able to find a value that works for you
with ldapsearch, then the same should work with the SSSD, too.
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
I'll play around with the ldap_sasl_minssf and see if that causes the
errors to disappear (similar to how ldap* commands did) and report back.
Hate to sound thick, but what exactly is a PAC? I've seen it in related
threads and searches but have been unable to find a decent definition...
Thanks!
Greg Wojtak
Sr. Unix Systems Engineer
Office: (313) 373-4306
Cell: (734) 718-8472
12:54 p.m.
On Tue, 2012-09-04 at 17:50 +0000, Wojtak, Greg (Superfly) wrote:
On 2012-09-04 12:17 PM, "Jakub Hrozek"
<jhrozek(a)redhat.com> wrote:
>On Tue, Sep 04, 2012 at 04:00:57PM +0000, Wojtak, Greg (Superfly) wrote:
>> Every once in a while with SSSD, we run into a problem where we aren't
>>able to get user information or authenticate users. We are using
>>ldap/kerberos against an Active Directory set up over SSL (LDAPS) and we
>>see the following message in the logs:
>>
>> encoded packet size too big (813957100 > 16777215)
>>
>
>Hi Greg,
>
>are you using ldap:// or ldaps:// schema to connect to the AD server?
>
>If you are getting the same error with ldapsearch & friends, then the
>issue is not inside SSSD. This error happens when the AD issues a PAC
>that is too big for the SASL library to handle -- the PAC contains
>information about users and groups as well and might grow in a very
>large organization.
>
>> From what I've been able to gather, this is something to do with the
>>cyrus-sasl package. I've also seen this error pop up when doing
>>operations with the openldap-clients (ldapsearch, ldapmodify). I've
>>found that by specifying the minssf and maxssf values in the ldap*
>>operations that the operations would then succeed.
>>
>> I'm wondering if the same type of fix would work for SSSD? Is there a
>>way to specify the SSF of the SASL operations that SSSD uses? Is there
>>another workaround for this?
>>
>
>You can use the ldap_sasl_minssf option to fine-tune the SSF. The code
>path that uses the option value is the same as openldap-clients
>utilities use, so if you were able to find a value that works for you
>with ldapsearch, then the same should work with the SSSD, too.
>_______________________________________________
>sssd-users mailing list
>sssd-users(a)lists.fedorahosted.org
>https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
I'll play around with the ldap_sasl_minssf and see if that causes the
errors to disappear (similar to how ldap* commands did) and report back.
Hate to sound thick, but what exactly is a PAC? I've seen it in related
threads and searches but have been unable to find a decent definition...
http://msdn.microsoft.com/en-us/library/cc237917%28v=prot.13%29.aspx
However it comes into play only when using GSSAPI for LDAP binds.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:03 p.m.
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)
1:57 p.m.
On 2012-09-04 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)
I should have been more clear - I should have said I'm not specifying
ldap_uri at all (service discovery?) and yes, I have ldap_sasl_mech =
GSSAPI set.
Greg Wojtak
Sr. Unix Systems Engineer
Office: (313) 373-4306
Cell: (734) 718-8472
2:03 p.m.
On Tue, Sep 04, 2012 at 06:57:48PM +0000, Wojtak, Greg (Superfly) wrote:
On 2012-09-04 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)
I should have been more clear - I should have said I'm not specifying
ldap_uri at all (service discovery?) and yes, I have ldap_sasl_mech =
GSSAPI set.
Can you try if using ldap:// instead of ldaps:// perhaps using the
ldapsearch command line tool works for you?
2:07 p.m.
On 2012-09-04 3:03 PM, "Jakub Hrozek" <jhrozek(a)redhat.com> wrote:
On Tue, Sep 04, 2012 at 06:57:48PM +0000, Wojtak, Greg (Superfly)
wrote:
> On 2012-09-04 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)
>
>
> I should have been more clear - I should have said I'm not specifying
> ldap_uri at all (service discovery?) and yes, I have ldap_sasl_mech =
> GSSAPI set.
>
Can you try if using ldap:// instead of ldaps:// perhaps using the
ldapsearch command line tool works for you?
I've tested this heavily in the past - specifying ldap:// always works,
unless I am issuing a STARTTLS request. At that point I see the same
errors as using ldaps://
Greg Wojtak
Sr. Unix Systems Engineer
Office: (313) 373-4306
Cell: (734) 718-8472
3:16 p.m.
On Tue, 2012-09-04 at 19:07 +0000, Wojtak, Greg (Superfly) wrote:
On 2012-09-04 3:03 PM, "Jakub Hrozek"
<jhrozek(a)redhat.com> wrote:
>On Tue, Sep 04, 2012 at 06:57:48PM +0000, Wojtak, Greg (Superfly) wrote:
>> On 2012-09-04 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)
>>
>>
>> I should have been more clear - I should have said I'm not specifying
>> ldap_uri at all (service discovery?) and yes, I have ldap_sasl_mech =
>> GSSAPI set.
>>
>
>Can you try if using ldap:// instead of ldaps:// perhaps using the
>ldapsearch command line tool works for you?
I've tested this heavily in the past - specifying ldap:// always works,
unless I am issuing a STARTTLS request. At that point I see the same
errors as using ldaps://
You can't use gssapi auth and ssl at the same time with Windows DCs.
When using GSSAPI for auth the connection is already encrypted and you
don't need to use ldaps.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:59 p.m.
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
4251
days inactive
4251
days old
sssd-users@lists.fedorahosted.org
9 comments
4 participants
participants (4)
-
Chris Hartman -
Jakub Hrozek -
Simo Sorce -
Wojtak, Greg (Superfly)