Using ktadd seems to invalidate the passwd
Phillip Moore
w.phillip.moore at gmail.com
Tue Oct 12 15:11:41 EDT 2010
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
>
More information about the Kerberos
mailing list