On Wed, 2012-07-18 at 15:17 -0400, David Warden wrote:
on Oracle Linux (RHEL clone) 6.3, 64-bit, sssd version 1.8.0 gets us all the way to the
point where we can kinit with /etc/krb5.keytab and successfully run the test ldapsearch
Would you mind please being more specific about the kinit and ldapsearch
that you ran? I'm a bit surprised that ldapsearch would work if you get
the below message on SSSD.
When we start sssd and try getent on a user in AD we get this to
"Jul 18 14:58:44 wardentest3 sssd_be: encoded packet size too big (813957120 >
From a quick Google search, it looks like this happens when Microsoft
issues a PAC in the kerberos ticket that is too large for SASL to
The size of the PAC is proportional to the number of users, groups and
access-control permissions that are specified in the Windows Server. I'm
not sure how complex your environment would have to be to hit that
limit, but I suspect if anyone is going to hit it, a university would.
Unfortunately, I think this issue is outside SSSD's control. It's most
likely occurring in the cyrus-sasl package.
Setting debug_level to 0x7850 (the highest, I believe) doesn't
yield any additional helpful info.
Could you provide it anyway? Sometimes the debug logs are only visibly
helpful to the developers (for example, knowing which phase of
processing triggered a failure might at least provide us guidance on a
I did deviate a bit from the SSSD/AD document in that I did not bind
the host but instead created a keytab for a generic user we use to give our linux hosts
access to LDAP on AD. I didn't think this would be a problem since the
kinit/ldapsearch test worked fine.
Well, that *may* work, depending on the permissions granted to that
user. Not being a "computer" account may introduce odd bugs though.
It seems likely that the reason for the PAC being so large is that if
you have a single user with permissions on all your Linux hosts, all of
that data is going to be encoded in the PAC. So using a computer account
instead of a user account (which generally only has a PAC with data
about a single client machine) would probably avoid this issue.
Here's the safe bits of our keytab (we're using mailuser(a)W2K.GENESEO.EDU as our
Keytab name: WRFILE:/etc/krb5.keytab
25 HOST/mail.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 HOST/mailtest.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 IMAP/mail.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 IMAP/mailtest.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 SMTP/mail.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 SMTP/mailtest.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 HTTP/mail.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 HTTP/mailtest.geneseo.edu(a)W2K.GENESEO.EDU (arcfour-hmac)
25 mailuser(a)W2K.GENESEO.EDU (arcfour-hmac)
Google searches seemed to indicate that this may be some kind of sasl issue and possibly
out of SSSD's control. Has anyone experience a similar problem or have advice on what