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" <[email protected]> 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/[email protected], and you need to
create a new one called afs/[email protected], 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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
