On Jul 18, 2012, at 3:38 PM, Stephen Gallagher wrote:

On Wed, 2012-07-18 at 15:17 -0400, David Warden wrote:
Following https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server 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 command.

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 /var/log/messages:

"Jul 18 14:58:44 wardentest3 sssd_be: encoded packet size too big (813957120 > 16777215)"

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@W2K.GENESEO.EDU as our principal):

Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
 25 HOST/mail.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 HOST/mailtest.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 IMAP/mail.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 IMAP/mailtest.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 SMTP/mail.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 SMTP/mailtest.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 HTTP/mail.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 HTTP/mailtest.geneseo.edu@W2K.GENESEO.EDU (arcfour-hmac)
 25 mailuser@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 to try?

sssd-users mailing list

While my 40kb+ post with log messages waits for admin approval, it is with great shame (and some joy) that I report that I was able to resolve my issue by changing to not connect to AD over LDAP+SSL (port 636) and instead connect to normal unencrypted LDAP on port 389. I am not sure why that would have made a difference and I would prefer to do this over SSL so I'm going to keep investigating but it is strange that this fixed the problem.

David Warden
Mail Administrator
State University of New York at Geneseo

"There's only one rule that I know of, babies—God damn it, you've got to be kind."