[28972] in Kerberos
Re: Query about an admin testing a user's creds
daemon@ATHENA.MIT.EDU (Christopher D. Clausen)
Mon Jan 7 00:03:23 2008
Message-ID: <79663E2A269A42EF819A317BD60E0E2F@CDCHOME>
From: "Christopher D. Clausen" <cclausen@acm.org>
To: "Coy Hile" <coy.hile@coyhile.com>, <kerberos@mit.edu>
Date: Sun, 6 Jan 2008 23:01:59 -0600
Cc: chile1@bloomberg.net, jmcvetta@bloomberg.net
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Coy Hile <coy.hile@coyhile.com> wrote:
> If we need to test, for example, that a user is actually getting a
> TGT, we need to inform the user that we're changing their password
> temporarily, change it, authenticate as them directly, and then have
> them change it back. We've all been wondering aloud whether there is
> some way for an admin to get creds as a user directly (Eg, something
> like su - user which actually does a kinit as that user). Has
> something along those lines been implemented? If not, what's the
> reasoning behind it not being so implemented? (I'm perfectly happy to
> accept "Because it's Really Stupid(tm) for the follwing reasons..." as
> an answer too :))
What flavor of Kerberos are you using? I beleive that it is trivial
with a Heimdal setup for a Kerberos admin to extract a keytab for any
principal and NOT actually change the password of the principal. (Use
the ext_keytab command in kadmin.) It is less easy with an MIT setup.
You can revert the krb5 database to the point it was at before a
principal change, however if other principals were changed in the mean
time, you could have a serious syncronization problem. You may be able
to do this manually by just finding the data in the dump for a
particular principal and injecting it into a newer dump of the current
Kerberos database. I am unaware of potential fallout from doing this
though.
Alternately, you could modify your change password procedure to either
store the cleartext of the password (bad idea) or generate a keytab for
the user using the provided password (slightly less bad of an idea)
during the change process.
<<CDC
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
