[OpenAFS] Re: Moving Magic Trio to another domain

[Benjamin Kaduk]

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" <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.

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.:
>
> /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).

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 
by events.

-Ben