moving kerberos master to new server

Steve Devine sd at msu.edu
Fri Oct 23 13:31:45 EDT 2009


Quoting "peter sands" <peter_sands at techemail.com>:

> Hello,
> Currently using kerberos 5.
> Soon I plan to migrate this server onto another hardware that will
> have a new hostname and IP, but same O/S level (aix).
>
> My first thoughts in doing this was to:
> Stop  the master server, all clients will then goto to the slave for
> authentication.
> Install the krb5 binaries, without configuring the new master.
> Tar up the /var/krb5 and /etc/krb5 directories, then untar it onto the
> new host.
> Change the kdc and krb5 conf files with the new hostname. Start the
> new master up
>
> Would that work, or is there another sequence I should follow.
>
> Thanks
> Pete.
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

I have done this three times and this how I do it.
Build the new server and kerberos software. Harden it.
Grab a tar file of the principal db off of a slave server get the  
krb5.conf file and requisite ketabs and put it in place.

Start it up - you should be able to kinit locally to it and do some  
kadmin functions. This will not have any effect on your production  
Realm (as long as you are not propagating to slaves from it)- make  
certain you are kinit ing to the new machine by inspecting logs.

Once you are satisfied with the tests - schedule your down time bring  
the main server down and move the princs over. Make sure you local  
files (krb5.conf) are pointing to the right host and you should be ok.
I usually don't start kadmin right away so no one can reset their  
passwords until I am sure that I am going to leave it up.
Actual down time is usually 30 minutes or less.
/sd



Steve Devine
Email & Storage
Academic Technology Services
Michigan State University

313 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327

Everything that can be counted does not necessarily count;
everything that counts cannot necessarily be counted.
Albert Einstein





More information about the Kerberos mailing list