Streamlining host principal keytab provisioning?

[Sebastian Galiano]

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' ;
1;

This made the trick and I managed to create the principal in the wallet database. 

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.  I also tried to create more principals that are not defined in the KEYTAB_PRINCIPAL and it worked. So I still dont understand why is the KEYTAB_PRINCIPAL parameter needed since I can create any principal inside the /etc/krb5.keytab.


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


remctld output:
remctld: child 4532 for xxxx
remctld: received context token (size=649)
remctld: sending context token (size=156)
remctld: accepted connection from user at REALM (protocol 2)
remctld: argc is 4
remctld: arg 1 has length 6
remctld: arg 2 has length 5
remctld: arg 3 has length 6
remctld: arg 4 has length 29
remctld: COMMAND from user at REALM: wallet check keytab nfs/host.domain.org
remctld: argc is 4
remctld: arg 1 has length 6
remctld: arg 2 has length 3
remctld: arg 3 has length 6
remctld: arg 4 has length 29
remctld: COMMAND from user at REALM: wallet get keytab nfs/host.domain.org
remctld: quit received, closing connection
remctld: child 4532 done







________________________________________
From: Russ Allbery [rra at stanford.edu]
Sent: 08 May 2012 09:16
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, I missunderstood with the KEYTAB_PRINCIPAL parameter, now I've
> changed for user at REALM which is the principal I gave permissions to.

It needs to be the principal for which you created a keytab that's stored
wherever $KEYTAB_FILE is pointing to.

> Just in case i renewed the ticket of user at realm and then:

> $wallet create keytab nfs/host.domain.org
> wallet: keytab object implementation not configured

Okay, you're back to remctl working again.

    if (not $Wallet::Config::KEYTAB_KRBTYPE) {
        die "keytab object implementation not configured\n";

    unless (defined ($Wallet::Config::KEYTAB_PRINCIPAL)
            and defined ($Wallet::Config::KEYTAB_FILE)
            and defined ($Wallet::Config::KEYTAB_REALM)) {
        die "keytab object implementation not configured\n";

One of those variables isn't actually set or isn't being loaded or
something.

--
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>