Streamlining host principal keytab provisioning?

[Sebastian Galiano]

That make things more clear I believe. So now I created a principal that is admin in the kerberos just for the wallet service: 
service/wallet at REALM

I exported the keytab in a separate file : /etc/wallet.keytab

I modified the /etc/wallet.conf in the wallet server (the wallet server and kdc server are the same machine) 


$DB_DRIVER = 'mysql';
$DB_NAME = 'wallet';
$DB_HOST = 'localhost';
$DB_USER = 'wallet';
$DB_PASSWORD = 'wallet';
$KEYTAB_FILE = '/etc/wallet.keytab';
$KEYTAB_KRBTYPE = 'MIT';
$KEYTAB_REALM= 'REALM';
$KEYTAB_TMP  = '/home/admins/sebastianadm/';
$KEYTAB_PRINCIPAL = 'service/wallet at REALM' ;


I also applied : 

wallet owner keytab nfs/host.domain.org ADMIN

And then I tried to get that keytab from the clien (host.domain.org): 

$wallet -f file  get keytab nfs/host.domain.org -s server.domain.org
wallet: error creating keytab for nfs/host.domain.org at REALM: Operation requires ``change-password'' privilege while changing nfs/host.domain.org at REALM's key

change-password privileges, it refers to the wallet service, the database service or the kerberos service? I tried to get that keytab from kadmin using the principal service/walllet and I managed locally. Therefore, I believe is not a kerberos probem.





________________________________________
From: Russ Allbery [rra at stanford.edu]
Sent: 09 May 2012 03:58
To: Sebastian Galiano
Cc: Jeff Blaine; kerberos at mit.edu
Subject: Re: Streamlining host principal keytab provisioning?

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/>