Streamlining host principal keytab provisioning?
Russ Allbery
rra at stanford.edu
Tue May 8 21:58:21 EDT 2012
Sebastian Galiano <Sebastian.Galiano at spilgames.com> writes:
> Ok, from the same wallet server I executed the following command:
> wallet create keytab nfs/host.domain.org -s server.domain.org
> My wallet.conf is:
> $DB_DRIVER = 'mysql';
> $DB_NAME = 'wallet';
> $DB_HOST = 'localhost';
> $DB_USER = 'wallet';
> $DB_PASSWORD = 'PASSWORD';
> $KEYTAB_FILE = '/etc/krb5.keytab';
> $KEYTAB_KRBTYPE = 'MIT';
> $KEYTAB_REALM= 'REALM';
> $KEYTAB_TMP = '/home/tmp';
> $KEYTAB_PRINCIPAL = 'nfs/host.domain.org' ;
This still doesn't look right. Let me take a step back.
There are three components involved here:
* The KDC, which stores all your Kerberos principals and their keys.
* The wallet server, which manages keytab creation. The wallet server is
*itself* a Kerberos service, which talks to the Kerberos KDC using
Kerberos. It obviously cannot manage its own principal; that has to be
set up separately with kadmin.
* The client, that wants to create and download a keytab.
$KEYTAB_FILE and $KEYTAB_PRINCIPAL in the wallet configuration are for the
princpial of the wallet server itself. It uses that principal to talk to
kadmin on the KDC. That keytab has to be created by a Kerberos
administrator using kadmin directly, and has to have ACLs in the
kadmind.acl file. That setting should never change once you have wallet
working.
For example, at Stanford, that principal is service/wallet at stanford.edu.
So it doesn't really make any sense for that principal to be
nfs/host.domain.org. That's the principal for the NFS server on
host.domain.org, and you probably don't want to give the NFS server a
bunch of privileges in kadmin that you're giving to the wallet server.
> I also tried from my host.domain.org. I've changed the KEYTAB_PRINCIPAL
> to host/host.domain.org, and it also created a principal inside the
> wallet database.
So, per the above, changing KEYTAB_PRINCIPAL doesn't make any sense here,
and I don't see why changing it would have created anything in the wallet
database.
> My next step has been to try to get they keytab for nfs/host.domain.org
> from host.domain.org using the command:
> $wallet -f file get keytab nfs/host.domain.org
> wallet: user at REALM not authorized to get keytab:nfs/host.domain.org
Did you set an owner for that keytab after you created it? Newly created
objects by default can't be downloaded, since they have no owner. See the
wallet man page:
create <type> <name>
Create a new object of type <type> with name <name>. With some
backends, this will trigger creation of an entry in an external
system as well. The new object will have no ACLs and no owner set,
so usually the administrator will want to then set an owner with
"owner" so that the object will be usable.
One simple way to get started would be:
wallet owner keytab nfs/host.domain.org ADMIN
Of course, once you start using it more broadly, you'd want to set up a
variety of ACLs representing various groups that need to download keytabs
for their systems.
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the Kerberos
mailing list