Use keytab to select etypes in krb5_get_init_creds_keytab()

Stef Walter stefw at
Tue Apr 10 15:51:47 EDT 2012

It seems that when using krb5_get_init_creds_keytab(), if we don't have
a keytab entry with a key using the first etype offered by the server,
then the authentication fails.

For example, using the attached test program i see this:

Selected etype info: etype aes256-cts, salt
"", params ""
FILE:/data/build/etc/krb5.keytab (vno 0, enctype aes256-cts) with
result: -1765328203/No key table entry found for
Preauth module encrypted_timestamp (2) (flags=1) returned:
-1765328203/No key table entry found for STEF-DESKTOP$@AD.THEWALTER.LAN

And my keytab contains:

   3 STEF-DESKTOP$@AD.THEWALTER.LAN (arcfour-hmac)

The server did offer arcfour-hmac as well. For the morbidly curious, the
keytab was generated by samba [1], and the kdc is a Windows 2008 Server.
I was playing with sssd + AD integration when I came across this issue.
The same bug was triggered by sssd.

The attached patch fixes the issue. If the
krb5_get_init_creds_opt_set_etype_list() has not been called on the
option context passed to krb5_get_init_creds_keytab() then the keytab is
enumerated for the enctypes that are available for the given principal.
The patch sorts the enctypes so 'weak' ones come last.

In theory client programs could fix this themselves by calling
krb5_get_init_creds_opt_set_etype_list(). However they're disadvantaged:
AFAICT they don't have access to the functions which tell them which
enctypes are 'weak' and which are not.

Does this seem like a good approach? If so I'll file a PR.



[1] net ads keytab create
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frob-krb5.c
Type: text/x-csrc
Size: 1219 bytes
Desc: not available
Url :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-krb5_get_init_creds_keytab-default-to-enctypes-.patch
Type: text/x-patch
Size: 6535 bytes
Desc: not available
Url :

More information about the krbdev mailing list