[32805] in Kerberos
Re: Using ktadd seems to invalidate the passwd
daemon@ATHENA.MIT.EDU (Marcus Watts)
Tue Oct 12 16:26:04 2010
To: Phillip Moore <w.phillip.moore@gmail.com>
In-reply-to: <AANLkTim9U-T5K=d-YjrqWnZ8YhCu=6Tu_O-bRPdAb1Os@mail.gmail.com>
Date: Tue, 12 Oct 2010 16:25:55 -0400
From: Marcus Watts <mdw@umich.edu>
Message-Id: <E1P5lQ3-0007fq-3z@bruson.ifs.umich.edu>
Cc: kerberos@mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Phillip Moore <w.phillip.moore@gmail.com> says:
...
> it handles it is disturbing:
>
> [root@rpcore tmp]# echo ktadd -norandkey -k /var/tmp/foo.keytab efsops |
> kadmin.local
> Authenticating as principal root/admin@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 admin@DOGS.UMICH.EDU -r DOGS.UMICH.EDU -q "xst -k /tmp/efsops.kt efsops@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 admin@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 efsops@DOGS.UMICH.EDU -r DOGS.UMICH.EDU -q "getprinc efsops"
(write down vno)
/usr/local/mit-k5/sbin/ktutil
addent -password -p efsops@DOGS.UMICH.EDU -k 3 -e aes256-cts
James.8.Ate.Here
wkt /tmp/efsops3.kt
q
kinit -k -t /tmp/efsops3.kt efsops@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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
