Passwordless access to kadmin?

[Marcus Watts]

> Date:    Tue, 17 Jul 2007 10:29:39 PDT
> To:      kerberos at mit.edu
> From:    Russ Allbery <rra at stanford.edu>
> Subject: Re: Passwordless access to kadmin?
> 
> "Bryan K. Wright" <bryan at 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 at DOGS.UMICH.EDU -r DOGS.UMICH.EDU
	Authenticating as principal admin at DOGS.UMICH.EDU with password.
	Password for admin at DOGS.UMICH.EDU: 
	kadmin:  ank -e aes256-cts:normal -pw this.is.a.password demopwkt
	WARNING: no policy specified for demopwkt at DOGS.UMICH.EDU; defaulting to no policy
	Principal "demopwkt at DOGS.UMICH.EDU" created.
	kadmin:  quit

/2/ make a keytab

	spam% /usr/sbin/ktutil
	ktutil:  addent -password -p demopwkt at DOGS.UMICH.EDU -k 1 -e aes256-cts
	Password for demopwkt at 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 at DOGS.UMICH.EDU
	spam% kdestroy

/4/ run kadmin with the keytab:
	spam% /usr/sbin/kadmin -p demopwkt at DOGS.UMICH.EDU -r DOGS.UMICH.EDU -k -t /tmp/demopwkt.ktab
	Authenticating as principal demopwkt at DOGS.UMICH.EDU with keytab /tmp/demopwkt.ktab.
	kadmin:  getprinc admin
	get_principal: Operation requires ``get'' privilege while retrieving "admin at DOGS.UMICH.EDU".
	kadmin:  getprinc demopwkt
	Principal: demopwkt at 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 at 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 at DOGS.UMICH.EDU demopwkt at DOGS.UMICH.EDU
	spam% /usr/sbin/kadmin -r DOGS.UMICH.EDU -c FILE:/tmp/krb5cc_25131_czrBQ2
	Authenticating as principal demopwkt at 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 at DOGS.UMICH.EDU

	Valid starting     Expires            Service principal
	07/17/07 15:33:26  07/17/07 18:33:26  kadmin/admin at 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