[OpenAFS] Re: Moving Magic Trio to another domain
Tue, 24 Sep 2013 15:31:54 -0400 (EDT)
I was out sick yesterday, sorry I missed all the excitement.
On Mon, 23 Sep 2013, Andrew Deason wrote:
> On Mon, 23 Sep 2013 09:08:35 +0300 (EEST)
> "Jukka Tuominen" <firstname.lastname@example.org> 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.
MIT Kerberos does have a way to express a per-principal salt in the
database, but there are not particularly good tools to do so en masse. In
general, people doing this sort of thing either edit a plaintext dump of
the database or write a custom application that links against
libkadm5srv_mit. It is particularly awkward for the case of the salt,
since the default salt is not ususally explicitly written out, there is a
sentinel value that means "construct the default salt for this principal".
To make salts consistent with existing keys after a realm rename would
thus require constructing an explicit salt for all principals, where one
did not previously exist.
> 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.
A single KDC process can serve multiple realms, though I believe that it
is limited to serving the kadmin protocol to a single realm.
>>> 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.:
> instead of:
> 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).
I think with rxkad.keytab they actually can have the same kvno, but it's
still a bad idea.
Anyway, it seems that this part of the thread has (sadly) been overtaken