Bug#698534: krb5-user: usage of keytabs gives "Generic preauthentication failure while getting initial credentials"

Benjamin Kaduk

unread,

May 26, 2013, 3:40:03 PM5/26/13

to

On Sun, 26 May 2013, Christoph Anton Mitterer wrote:

>
> $ kinit mitt...@CERN.CH
> Password for mitt...@CERN.CH:
> $ klist -e
> Ticket cache: FILE:/tmp/krb5cc_1000
> Default principal: mitt...@CERN.CH
>
> Valid starting Expires Service principal
> 2013-05-26 12:04:33 2013-05-27 12:04:19 krbtgt/CER...@CERN.CH
> Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
>
>
> but:
>
>
> $ ktutil
> ktutil: addent -password -p mitt...@CERN.CH -k 1 -e
> aes256-cts-hmac-sha1-96
> Password for mitt...@CERN.CH:
> ktutil: wkt kt
> ktutil: quit
> $ kinit -k -t kt mitt...@CERN.CH
> kinit: Preauthentication failed while getting initial credentials

The key needed to decrypt the KDC's response to kinit's request depends
not only on the password, but also on the "salt" string stored in the KDB
and potentially a couple other parameters. There are default values which
are probably being used here, but it is not necessarily so.
kinit-with-a-password can adapt to what the KDC tells it, but ktutil must
make a guess when addent -password is called. Because this mechanism (and
really, a few others) are also possible explanations for your observed
behavior, as well as the linked upstream issue, it is hard to say with any
certainty what is going on. More information about what the kerberos
library is doing is necessary for an accurate diagnosis.

Can you run the two kinit commands with KRB5_TRACE set in the environment
to the path to a log file and capture a trace log? (Use a different
KRB5_TRACE setting for each run to get separate logfiles, please.) That
will include the salt sent by the KDC and more details about what the
library is doing.

-Ben Kaduk

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Benjamin Kaduk

unread,

May 27, 2013, 6:10:02 PM5/27/13

to

fixed 698534 1.11.2+dfsg-1
thanks

On Sun, 26 May 2013, Christoph Anton Mitterer wrote:

> See the attachments (kinit for what happened with plain kinit, kutil for
> what happened with the keytab).

Thanks for these. It looks like the salt that the KDC is sending back
with the AS_REP is "CERN.CHchristoph.anton.mitterer", but the salt that
ktutil would use is just "CERN.CHmitterer". Since these are not the same,
the key generated by ktutil is different than the key on the KDC, and the
encrypted timestamp preauthentication fails.

ktutil is not smart enough to allow the user to specify a non-default
salt; if your KDC is in fact AD, you may need to use a ktpass.exe utility
to generate an AES keytab for your principal.

The arcfour enctypes presumably worked because they do not use the salt
parameter for key generation.

Sam Hartman

unread,

May 28, 2013, 9:10:01 AM5/28/13

to

Well, is there any reason you're not using the full name for the
principal in the keytab?
in AD, i'd expect that to work too.

Sam Hartman

unread,

May 28, 2013, 9:10:02 AM5/28/13

to

i think you need to reclose the bug not simply mark it as fixed again.

Benjamin Kaduk

unread,

May 28, 2013, 11:00:02 AM5/28/13

to

On Tue, 28 May 2013, Christoph Anton Mitterer wrote:

>> ktutil is not smart enough to allow the user to specify a non-default
>> salt

> Given that this seems to be quite widespread then (I mean AD is evil,
> but used in many places)... do you seen any chances upstream, to extend
> ktutil accordingly?

I created ticket 7647 in our bug tracker
(http://krbdev.mit.edu/rt/Ticket/Display.html?id=7647&user=guest&pass=guest)
but I do not expect any action on it in the near future.

-Ben