[28051] in Kerberos
Re: Passwordless access to kadmin?
daemon@ATHENA.MIT.EDU (Marcus Watts)
Tue Jul 17 17:11:58 2007
To: kerberos@mit.edu
In-reply-to: <87ir8jvszg.fsf@windlord.stanford.edu>
Date: Tue, 17 Jul 2007 15:45:24 -0400
From: Marcus Watts <mdw@spam.ifs.umich.edu>
Message-Id: <E1IAsz6-0001Ly-DA@spam.ifs.umich.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> Date: Tue, 17 Jul 2007 10:29:39 PDT
> To: kerberos@mit.edu
> From: Russ Allbery <rra@stanford.edu>
> Subject: Re: Passwordless access to kadmin?
>
> "Bryan K. Wright" <bryan@ayesha.phys.virginia.edu> writes:
>
> > But as a side-effect of this, I can then no longer
> > get into kadmin by typing "kadmin -p root/admin" and supplying
> > a password. If I try, kadmin tells me the password is bad.
>
> Yes, when you create a keytab for a principal, it randomizes the
> password.
>
> > What do I need to do to make both of these work?
>
> Don't use the same account for interactive use and for scripted use.
> Instead, create a new principal for scripted use and add it to kadm5.acl.
What Russ says is best practice, and you should go do that.
Sharing passwords between users is bad enough. Sharing passwords
with machine principals really sucks.
Just so that you don't think this is the fault of the software,
it *is* possible to set up a principal that can authenticate to kadmind
either via a keytab or via a password. Here's how:
/1/ create the principal:
spam% /usr/sbin/kadmin -p admin@DOGS.UMICH.EDU -r DOGS.UMICH.EDU
Authenticating as principal admin@DOGS.UMICH.EDU with password.
Password for admin@DOGS.UMICH.EDU:
kadmin: ank -e aes256-cts:normal -pw this.is.a.password demopwkt
WARNING: no policy specified for demopwkt@DOGS.UMICH.EDU; defaulting to no policy
Principal "demopwkt@DOGS.UMICH.EDU" created.
kadmin: quit
/2/ make a keytab
spam% /usr/sbin/ktutil
ktutil: addent -password -p demopwkt@DOGS.UMICH.EDU -k 1 -e aes256-cts
Password for demopwkt@DOGS.UMICH.EDU: this.is.a.password
ktutil: wkt /tmp/demopwkt.ktab
ktutil: q
spam%
/3/ test the keytab (optional, but recommended)
spam% kinit -k -t /tmp/demopwkt.ktab demopwkt@DOGS.UMICH.EDU
spam% kdestroy
/4/ run kadmin with the keytab:
spam% /usr/sbin/kadmin -p demopwkt@DOGS.UMICH.EDU -r DOGS.UMICH.EDU -k -t /tmp/demopwkt.ktab
Authenticating as principal demopwkt@DOGS.UMICH.EDU with keytab /tmp/demopwkt.ktab.
kadmin: getprinc admin
get_principal: Operation requires ``get'' privilege while retrieving "admin@DOGS.UMICH.EDU".
kadmin: getprinc demopwkt
Principal: demopwkt@DOGS.UMICH.EDU
Expiration date: [never]
Last password change: Tue Jul 17 15:25:39 EDT 2007
Password expiration date: [none]
Maximum ticket life: 4 days 04:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Jul 17 15:25:39 EDT 2007 (admin@DOGS.UMICH.EDU)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin: quit
spam%
It is also possible, although not especially useful, to authenticate
using a credentials cache:
spam% kinit -k -t /tmp/demopwkt.ktab -S kadmin/admin@DOGS.UMICH.EDU demopwkt@DOGS.UMICH.EDU
spam% /usr/sbin/kadmin -r DOGS.UMICH.EDU -c FILE:/tmp/krb5cc_25131_czrBQ2
Authenticating as principal demopwkt@DOGS.UMICH.EDU with existing credentials.
kadmin: quit
Administration credentials NOT DESTROYED.
spam% klist -5
Ticket cache: FILE:/tmp/krb5cc_25131_czrBQ2
Default principal: demopwkt@DOGS.UMICH.EDU
Valid starting Expires Service principal
07/17/07 15:33:26 07/17/07 18:33:26 kadmin/admin@DOGS.UMICH.EDU
renew until 07/18/07 15:33:26
spam%
A kadmin/admin ticket isn't good for getting more service tickets, and you
can't get a kadmin/admin ticket using a krbtgt (since DISALLOW_TGT_BASED is set.)
Note that I forced the key type to be one value. In a typical realm,
users will default to having multiple key types. This will complicate things.
Also, of course, demopwkt isn't a kerberos administrator (not in kadm5.acl)
so has very limited rights. And, of course, you don't need to do this.
-Marcus Watts
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
