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
handle[1].
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
workaround).
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?
[1]
http://blog.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/month=20091101_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-users