[OpenAFS] Re: Moving Magic Trio to another domain

Andrew Deason adeason@sinenomine.net
Mon, 23 Sep 2013 10:26:56 -0500


On Mon, 23 Sep 2013 09:08:35 +0300 (EEST)
"Jukka Tuominen" <jukka.tuominen@finndesign.fi> wrote:

> > For Kerberos, if you're using about MIT or Heimdal, this may be
> > difficult, since usually the keys for user principals are all salted
> > with the realm name. In the past I believe doing this was considered
> > impossible to do with existing code, but maybe things have improved.
> > This is more appropriate for the relevant Kerberos list, but someone
> > may respond here further anyway.
> >
> > AD I assume has an easier time with this, since it stores passwords
> > and not keys.
> 
> So, MIT kerberos is used, but generating new passwords is certainly
> doable if the homedirs on afs can still be saved.

If you can regenerate all of the keys/passwords, then it sounds like you
can just create a new realm from scratch. Just destroy the data from the
old realm and set up a new realm, as if you were setting it up for the
first time, and create all of the principals that existed in the
original realm.

If you want a migration period where the old and new realm are both
available, I _think_ you can run multiple realms from the same kdc, but
it takes some additional configuration.

> > OpenAFS servers and such usually don't care much about the name of
> > the cell. You can generally just treat this as adding a new realm
> > for the cell (and later removing the old realm/cell, if you want
> > to). This means you generate a new kerberos principal for
> > afs/newcell@NEWREALM, add it to the KeyFile/rxkad.keytab, and add
> > the new realm to openafs's krb.conf. If you ever use the '-cell'
> > option in any scripts or anything, of course that would need to
> > change. You may want to just take down all of the servers, update
> > ThisCell and CellServDB, and restart, but doing that I don't think
> > is strictly necessary.
> 
> So, IIUC the homedirs aren't actually moved, they only get new
> reference points (or something)?

Well yes, they aren't moving; you said the server isn't changing, right?
There's nowhere to be moving to :)

You just add the new.example.com cell to CellServDB (or AFSDB/SRV DNS,
or whatever), and then you access someone's home directory via e.g.:

/afs/new.example.com/user/foo

instead of:

/afs/old.example.com/user/foo

If you do not restart the client, you'll need to add the new cell
information with 'fs newcell'. If you are not using dynroot, you'll also
need to add the new.example.com mountpoint to root.afs, like you did for
the original cell setup.

So, more generally, just treat it as a new cell, which happens to
contain the data you want in it.

> I duplicated a client and updated all its server pointers, including
> ldap.  I suppose the new kerberos key needs to be added to the keytab,
> as well?

To the OpenAFS rxkad.keytab/KeyFile? Yes, you need to generate a new key
for a new principal with the new cell name in it. The old principal was
presumably called afs/old.example.com@OLD.EXAMPLE.COM, and you need to
create a new one called afs/new.example.com@NEW.EXAMPLE.COM, and add it
to rxkad.keytab or KeyFile, according to the normal instructions. Just
make sure that the kvnos for the 'old' and 'new' principals are
different, if you want to use both of them at the same time (for a
migration period).

-- 
Andrew Deason
adeason@sinenomine.net