It seems that when using krb5_get_init_creds_keytab(), if we don't have
a keytab entry with a key using the first valid etype offered by the
server, then the authentication fails.
For example the keytab created by samba using 'net ads keytab create'
3 STEF-DESKTOP$(a)AD.THEWALTER.LAN (des-cbc-crc)
3 STEF-DESKTOP$(a)AD.THEWALTER.LAN (des-cbc-md5)
3 STEF-DESKTOP$(a)AD.THEWALTER.LAN (arcfour-hmac)
With the above file, the following appears in the KRB5_TRACE logs:
 1334089314.82847: Selected etype info: etype aes256-cts, salt
"AD.THEWALTER.LANhoststef-desktop.ad.thewalter.lan", params ""
 1334089314.100867: Retrieving STEF-DESKTOP$(a)AD.THEWALTER.LAN from
FILE:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result:
As you'll note kerberos selected the aes256-cts enctype as that was the
first one offered by the server. However our keytab didn't contain that
MIT krb5 1.11 will fix also fix this issue. A patch I submitted is now
in krb5 git master. Stephen suggested that sssd also fix this issue in
sssd. Attached is a patch which fixes the problem in sssd as well.
It doesn't fix the problem as elegantly krb5 can. For example the krb5
patch doesn't result in reordering of etypes. Additionally I'm not sure
there's an easy way to detect (besides the krb5 version number) which
krb5 libraries contain the fix.
I've fixed several issues during preliminary review  of the patch,
with these exceptions:
* You're returning type krb5_error_code, but you also return
ENOMEM in one
place. Please replace this with an appropriate krb5_error_code value.
krb5_error_code values can contain errno values. It is routine
throughout the krb5 code base to return ENOMEM as a krb5_error_code.
Just one example of many:
* Please open an RFE against Kerberos to export the internal function
identify which enctypes are stronger.
If the point is to fix this in sssd for use with prior versions of krb5
libraries, then this doesn't make sense. A krb5 library with this newly
exported function would also contains the correct fix for the keytab
etypes issue, making the attached patch irrelevant.
BTW, for reasons which I don't yet understand, sssd fails when doing an
ldap_sasl_initialize_s using GSSAPI on krb5 1.10.2, connecting to an AD
server, with a samba keytab. It works against krb5 from git master (ie:
1.11). I guess I can debug this further when I have time.
Anyway for all of the above reasons, I'm not particularly attached to
this patch. But posting it here for what it's worth.