Using ktadd seems to invalidate the passwd
Phillip Moore
environment, where I am lazy, and simply set the various passwords to match
the usernames (I have no need for "real" security here -- this is just a
dataless test environment).
I do this, so that I can debug problems by acquiring tickets/tokens as any
of the test env users trivially. However, in the server software I'm
developing, I obviously don't make such an assumption. That software uses
keytabs files for each user to acquire tickets and/or tokens.
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....
There's something simple and subtle here I'm missing. I don't see a means
of setting the password and extracting the keytab file in a single kadmin
operation, for example.
What am I doing wrong?
Russ Allbery
> 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 (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Ken Raeburn
> 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.
Yes, that's correct; ktadd changes the key and gives you the new one. That's intentional, the idea being that no one should be able to extract a key from the database while it's already in use by a service, because that would allow the extractor to either impersonate the service, or impersonate anyone *to* the service. By forcing the key change, the latter is prevented; the real service will be visibly broken, hopefully catching an administrator's attention.
If you really want to get the current key out, in the general case, you need to run kadmin.local on the KDC itself and use "ktadd -norandkey" (with a sufficiently recent release -- I'm not sure when the option went in).
Since you're using known passwords, though, you could just update the keytab file directly with ktutil instead.
Ken
Phillip Moore
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@rpcore tmp]# echo ktadd -norandkey -k /var/tmp/foo.keytab efsops |
kadmin.local
Authenticating as principal root/ad...@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@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 <r...@stanford.edu> wrote:
> Phillip Moore <w.phill...@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 (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Marcus Watts
...
> it handles it is disturbing:
>
> [root@rpcore tmp]# echo ktadd -norandkey -k /var/tmp/foo.keytab efsops |
> kadmin.local
> Authenticating as principal root/ad...@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@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.
It should be APPENDING to /etc/krb5.keytab. So it's not
completely disasterous, just annoying.
But yes, I quite agree it should not be doing anything if it's reporting
a syntax error. In this case, I think it's trying to provide "helpful"
default behavior (for somebody else).
There is a "-q query" option that will allow you to avoid the echo pipeline,
/usr/local/mit-k5/sbin/kadmin -p ad...@DOGS.UMICH.EDU -r DOGS.UMICH.EDU -q "xst -k /tmp/efsops.kt efs...@DOGS.UMICH.EDU"
...
But if you're trying to make a keytab that uses a known password,
the mail you go on to quote about 'add_entry' is quite right:
/usr/local/mit-k5/sbin/kadmin -p ad...@DOGS.UMICH.EDU -r DOGS.UMICH.EDU -q "cpw -pw James.8.Ate.Here -e aes256-cts:normal efsops"
/usr/local/mit-k5/sbin/kadmin -p efs...@DOGS.UMICH.EDU -r DOGS.UMICH.EDU -q "getprinc efsops"
(write down vno)
/usr/local/mit-k5/sbin/ktutil
addent -password -p efs...@DOGS.UMICH.EDU -k 3 -e aes256-cts
James.8.Ate.Here
wkt /tmp/efsops3.kt
q
kinit -k -t /tmp/efsops3.kt efs...@DOGS.UMICH.EDU
If you're setting the password, note the salt type now matters
(probably you should always specify "normal" since you apparently
can't vary it in ktutil).
If the "echo" business you have is supposed to wind up buried in some
application, you might instead want to use something like
Authen::Krb5::Admin
(possibly with changes to teach it about non-default encryption types).
-Marcus Watts