-Copyright @copyright{} 1990, 1991, 1992, 1993, 1994, 1995, 1996 by the Massachusetts Institute of Technology.
+Copyright @copyright{} 1985-1999 by the Massachusetts Institute of Technology.
@quotation
Export of software employing encryption from the United States of
contemplating export to obtain such a license before exporting.
@end quotation
-WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute
-this software and its documentation for any purpose and without fee is
-hereby granted, provided that the above copyright notice appear in all
-copies and that both that copyright notice and this permission notice
-appear in supporting documentation, and that the name of M.I.T. not be
-used in advertising or publicity pertaining to distribution of the
-software without specific, written prior permission. M.I.T. makes no
-representations about the suitability of this software for any purpose.
-It is provided ``as is'' without express or implied warranty.
+If you make modifications to this software and distribute the modified
+software you MUST LABEL IT AS BEING A MODIFIED VERSION AND NOT ORIGINAL
+MIT KERBEROS CODE.
+
+WITHIN THESE CONSTRAINTS, permission to use, copy, modify, and
+distribute this software and its documentation for any purpose and
+without fee is hereby granted, provided that the above copyright notice
+appear in all copies and that both that copyright notice and this
+permission notice appear in supporting documentation, and that the name
+of M.I.T. not be used in advertising or publicity pertaining to
+distribution of the software without specific, written prior permission.
+M.I.T. makes no representations about the suitability of this software
+for any purpose. It is provided ``as is'' without express or implied
+warranty.
@iftex
@vskip 12pt
V4 KDC(s) will continue to work properly.
@menu
-* Mac OS X Configuration::
+* Mac OS X Configuration::
@end menu
@node Mac OS X Configuration, , Client Machine Configuration Files, Client Machine Configuration Files
@subsection The Keytab File
All Kerberos server machines need a @dfn{keytab} file, called
-@code{/etc/krb5.keytab} (@xref{Upgrading the application servers}), to
-authenticate to the KDC. The keytab file is an encrypted, local,
-on-disk copy of the host's key. The keytab file, like the stash file
-(@ref{Create the Database}) is a potential point-of-entry for a
-break-in, and if compromised, would allow unrestricted access to its
-host. The keytab file should be readable only by root, and should exist
-only on the machine's local disk. The file should not be part of any
-backup of the machine, unless access to the backup data is secured as
-tightly as access to the machine's root password itself.
+@code{/etc/krb5.keytab}, to authenticate to the KDC. The keytab file is
+an encrypted, local, on-disk copy of the host's key. The keytab file,
+like the stash file (@ref{Create the Database}) is a potential
+point-of-entry for a break-in, and if compromised, would allow
+unrestricted access to its host. The keytab file should be readable
+only by root, and should exist only on the machine's local disk. The
+file should not be part of any backup of the machine, unless access to
+the backup data is secured as tightly as access to the machine's root
+password itself.
In order to generate a keytab for a host, the host must have a principal
in the Kerberos database. The procedure for adding hosts to the
@node Upgrading Existing Kerberos V5 Installations, Bug Reports for Kerberos V5, Installing Kerberos V5, Top
@chapter Upgrading Existing @value{PRODUCT} Installations
-@menu
-* Upgrading existing Master and Slave KDCs to the current release::
-* Upgrading the application servers::
-@end menu
-
-@node Upgrading existing Master and Slave KDCs to the current release, Upgrading the application servers, Upgrading Existing Kerberos V5 Installations, Upgrading Existing Kerberos V5 Installations
-@section Upgrading existing Master and Slave KDCs to the current release
-
If you already have an existing Kerberos database that you created with
a prior release of Kerberos 5, you can upgrade it to work with the
-current release with the @code{kdb5_util} command. As of Kerberos 5
-version 1.0, this upgrade process is only necessary if you are using a
-Kerberos database created with Kerberos 5 beta 6 or earlier; newer
-installations can continue to be used without modification. The process
-for upgrading a Master KDC involves the following steps (the lines
-beginning with => indicate a continuation of the previous line):
+current release with the @code{kdb5_util} command. The process for
+upgrading a Master KDC involves the following steps (the lines beginning
+with => indicate a continuation of the previous line):
@enumerate
server processes, if any.
@item Dumping your existing Kerberos database to an ASCII file with
-@code{kdb5_edit}'s ``dump'' command:
+@code{kdb5_util}'s ``dump'' command:
@smallexample
@group
-@b{shell%} kdb5_edit -r @value{PRIMARYREALM} -R 'dump_db' >
+@b{shell%} kdb5_util -r @value{PRIMARYREALM} dump
@result{} @value{ROOTDIR}/var/krb5kdc/old-kdb-dump
@b{shell%}
@end group
@end smallexample
-@item If you were using OpenV*Secure or AXXiON*Authenticate, dumping your
-policy database to an ASCII file with the @code{ovsec_adm_export}
-command:
-
-@smallexample
-@group
-@b{shell%} ovsec_adm_export -r @value{PRIMARYREALM} >
-@result{} @value{ROOTDIR}/var/krb5kdc/old-adb-dump
-@b{shell%}
-@end group
-@end smallexample
-
@item Creating a new Master KDC installation (@xref{Install the Master
KDC}). If you have a stash file for your current database, choose any
new master password but then copy your existing stash file to the
@end group
@end smallexample
-@item If you were using OpenV*Secure or AXXiON*Authenticate, merging
-your policy database with @code{kdb5_util}'s ``load'' command with the
-``-update'' option:
-
-@smallexample
-@group
-@b{shell%} kdb5_util load -update @value{ROOTDIR}/var/krb5kdc/old-adb-dump
-@b{shell%}
-@end group
-@end smallexample
-
@end enumerate
-The process for upgrading a Slave KDC is simpler. All you have to do is
-make sure that the stash file on the Slave KDC is correct, stop the old
-server processes on the Slave KDC, install the new server binaries, and
-re-start the server processes. The Slave KDC database will be upgraded
-automatically when the next propagation is run. Note that if you
-changed your master key when creating your new Master KDC database, you
-will have to run a Slave KDC propagation before you can restart the
-server processes on the Slave KDC itself; otherwise, the new stash file
-that you create on the slave will not match the old database that exists
-until the propagation occurs, and the server processes will not start.
-
-@node Upgrading the application servers, , Upgrading existing Master and Slave KDCs to the current release, Upgrading Existing Kerberos V5 Installations
-@section Upgrading the application servers
-
-The default keytab name has changed from @code{/etc/v5srvtab} to
-@code{/etc/krb5.keytab}. You should rename the old keytab files on all
-of your application servers when you update their server binaries.
-Alternatively, you may add a relation to the library configuration file
-to override the new name, for example:
-
-@smallexample
-@group
-[libdefaults]
- default_keytab_name = /etc/v5srvtab
-@end group
-@end smallexample
-
-The keytab name defaulted to /etc/v5srvtab in prior releases of Kerberos
-V5. It was called a @dfn{srvtab} in Kerberos V4. The @code{v5srvtab}
-file has been renamed to @code{krb5.keytab} to reflect the change in
-terminology.
+To update a Slave KDC, you must stop the old server processes on the
+Slave KDC, install the new server binaries, reload the most recent slave
+dump file, and re-start the server processes.
@node Bug Reports for Kerberos V5, Files, Upgrading Existing Kerberos V5 Installations, Top
@chapter Bug Reports for @value{PRODUCT}