Using ktadd seems to invalidate the passwd

[Phillip Moore]

Man, I'm glad I'm doing this in a dataless environment that I can toss out
and rebuild.

I hope the following is a known and fixed problem.  The kadmin and
kadmin.local behavior in this case is incredibly bad.

Here's how I *was* doing this:

echo ktadd -k /home/root/keytabs/$user.keytab $user | kadmin -k

So, I tried this:

echo ktadd -norandkey -k /home/root/keytabs/$user.keytab $user |
kadmin.local

Well, not only does MIT Kerberos 1.6.1 not support the -norandkey, the way
it handles it is disturbing:

[root at rpcore tmp]# echo ktadd -norandkey -k /var/tmp/foo.keytab efsops |
kadmin.local
Authenticating as principal root/admin at TEST.EFS with password.
kadmin.local:  kadmin.local: Principal -norandkey does not exist.
kadmin.local: Principal -k does not exist.
kadmin.local: Principal /var/tmp/foo.keytab does not exist.
Entry for principal efsops with kvno 8, encryption type Triple DES cbc mode
with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal efsops with kvno 8, encryption type ArcFour with
HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal efsops with kvno 8, encryption type DES with HMAC/sha1
added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal efsops with kvno 8, encryption type DES cbc mode with
RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.

[root at rpcore tmp]# echo $?
0

First of all, it succeed, when I gave it a bogus argument, and then it
misinterpreted everything else on the line.

That can not be considered good behavior, especially since it turned around
and OVERWROTE /etc/krb5.keytab.   If a human user simply types some other
valid option incorrectly, the result should be an error.


On Tue, Oct 12, 2010 at 12:25 PM, Russ Allbery <rra at stanford.edu> wrote:

> Phillip Moore <w.phillip.moore at gmail.com> writes:
>
> > When setting up the environment, I create the principals using:
>
> >    add_principal -pw $principal $principal@$realm
>
> > Then I extract the keytab file for use in the test suite using:
>
> >    ktadd -k /path/to/$principal.keytab $principal
>
> > I've discovered that as soon as I run ktadd, then I can no longer
> > manually authenticate as that principal anymore.
>
> > kinit(v5): Password incorrect while getting initial credentials
>
> > I create 8 different users, and extract keytab files for only 3 of them.
> > They are all created with the same add_principal command, and I can only
> > manually authenticate as the 5 that have NOT had a keytab extracted.
>
> > Now, I'm assuming that the act of extracting the keytab has a side
> > effect, but it's not clear how to workaround it.  If I reset the
> > password using kadmin, that increments the kvno, which will mean I have
> > to re-extract the keytab files, which will make the password invalid,
> > which means....
>
> With MIT Kerberos, ktadd over the network always randomizes the keys.  You
> have to use kadmin.local with the -norandkey flag (which is only available
> in kadmin.local) to extract a keytab without randomizing the keys.
>
> Alternately, you can create a keytab directly from the password rather
> than using ktadd, using ktutil add_entry.
>
> Heimdal behaves the way that you desire above; extracting a keytab in
> Heimdal doesn't change the keys.
>
> --
> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>