[15737] in Kerberos_V5_Development
Re: preauth (I'm a Roomba in a 2'x2' room)
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Apr 30 12:02:12 2010
From: Greg Hudson <ghudson@mit.edu>
To: Jeff Blaine <jblaine@kickflop.net>
In-Reply-To: <4BDAF226.9030801@kickflop.net>
Date: Fri, 30 Apr 2010 12:02:01 -0400
Message-ID: <1272643321.2498.24.camel@ray>
Mime-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Encrypted challenge replaces encrypted timestamp when FAST is used. It
has all the nice properties of encrypted timestamp, plus it doesn't
expose the user's password to an offline attack (unless the attacker has
access to the armor key). Since FAST was not in use in your test,
fast_kdc_get_armor_key() returned a null armor key and the plugin
returned ENOENT.
Getting FAST to happen is actually relatively easy. It's enabled in the
KDC by default. The client will use it whenever it has access to an
"armor ticket". The armor ticket is ideally obtained with a
high-quality key such as a host keytab, but any valid ticket will work,
so you can just get credentials the normal way and use them:
kinit username
kinit -T /path/to/my/ccache username
If username has the preauth_required bit set, then the second kinit
should use encrypted challenge (assuming it doesn't have the
configuration necessary to use PKINIT).
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
