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: [r...@rpcore tmp]# echo ktadd -norandkey -k /var/tmp/foo.keytab efsops | kadmin.local Authenticating as principal root/[email protected] 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. [r...@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 <[email protected]> wrote: > Phillip Moore <[email protected]> writes: > > > When setting up the environment, I create the principals using: > > > add_principal -pw $principal $princi...@$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 ([email protected]) <http://www.eyrie.org/~eagle/> > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
