Migrating a Kerberos Realm

[Ken Raeburn]

On Nov 1, 2006, at 17:38, Edward Murrell wrote:
> I'd like to know if anyone has any practical experience in migrating a
> Kerberos realm.
>
> Back in the day, when I was learning about Kerberos, I set up the  
> local
> realm with the name 'OFFICE'. Since we had a local domain of the same
> name, this was fine, and I propergated information via DNS and
> everything was happy.
>
> Since then, we've expanded somewhat, and we now have a bunch of off- 
> site
> servers. Currently, I've got a bunch of servers in the US, and some in
> NZ, as well as our local office servers, and workstations. It turns  
> out
> that it is possible to make this work, but it requires bigger config
> file than, and updating the files every time something changes.
>
> [libdefaults]
>         default_realm = OFFICE
>
>
> The plan is to move the whole shebang to a COMANY.COM realm. However,
> I'd like to do this while causing as little downtime and disruption as
> possible. I had originally planned to run two realms in parallel and
> tell them to trust each other. Unfortunately,  MIT Kerberos doesn't
> appear to allow you to run two KDC's on the same server.

You can, but you have to write the config files to specify different  
port numbers for them.  (The code doesn't currently support using  
only some of a machine's IP addresses, if you wanted to put one on  
one address and one on another.)  The code theoretically supports  
serving multiple realms out of one KDC process, too, but we don't  
test that functionality often.  I'd be interested in any observations  
if you try it.

You may also be able to convert entries from one realm into entries  
in the other realm.  It'll take a bit of programming work, because  
our tools don't directly support it, but basically, you'd start with  
copying database records over.  That would include the raw keys  
(encrypted in the database master key, which would have to be kept  
the same while this is done), but not the passwords.  In programs  
like kinit, the keys are constructed from the password and a "salt"  
string, which by default is in turn constructed from the principal  
name, including the realm name.  But the database can store a special  
salt string for a principal's key, so you'd modify some (most?)  
entries for users to have the salt string computed based on the old  
realm name.

You'd still have to distribute new keytabs, update config files,  
etc., for the transition, but it may keep you from needing to reset  
everyone's passwords, rekey machines, etc.

Ken