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
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.
On 2012-09-04 12:17 PM, "Jakub Hrozek" jhrozek@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@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
On Tue, 2012-09-04 at 17:50 +0000, Wojtak, Greg (Superfly) wrote:
On 2012-09-04 12:17 PM, "Jakub Hrozek" jhrozek@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@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.
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)
On 2012-09-04 2:03 PM, "Jakub Hrozek" jhrozek@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
On Tue, Sep 04, 2012 at 06:57:48PM +0000, Wojtak, Greg (Superfly) wrote:
On 2012-09-04 2:03 PM, "Jakub Hrozek" jhrozek@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?
On 2012-09-04 3:03 PM, "Jakub Hrozek" jhrozek@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@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
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
On Tue, 2012-09-04 at 19:07 +0000, Wojtak, Greg (Superfly) wrote:
On 2012-09-04 3:03 PM, "Jakub Hrozek" jhrozek@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@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
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.
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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Chris Hartman -
Jakub Hrozek -
Simo Sorce -
Wojtak, Greg (Superfly)