opensubscriber
   Find in this group all groups
 
Unknown more information…

k : kerberos@mit.edu 9 May 2012 • 9:58AM -0400

Re: Streamlining host principal keytab provisioning?
by Russ Allbery

REPLY TO AUTHOR
 
REPLY TO GROUP




Sebastian Galiano <Sebastian.Galiano@spil...> 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@stan....

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@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@stan...)             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           Kerberos@mit....
https://mailman.mit.edu/mailman/listinfo/kerberos

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.