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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
