diff options
Diffstat (limited to 'doc/install.texinfo')
-rw-r--r-- | doc/install.texinfo | 98 |
1 files changed, 18 insertions, 80 deletions
diff --git a/doc/install.texinfo b/doc/install.texinfo index a3216ba..8744b0f 100644 --- a/doc/install.texinfo +++ b/doc/install.texinfo @@ -1096,7 +1096,7 @@ to switch the port number for @code{kerberos} to 750 and create a 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 @@ -1274,15 +1274,15 @@ telnet stream tcp nowait root @value{ROOTDIR}/sbin/telnetd @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 @@ -1355,22 +1355,11 @@ should be readable only by root. @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 @@ -1378,28 +1367,16 @@ beginning with => indicate a continuation of the previous line): 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 @@ -1416,50 +1393,11 @@ your current database, you must choose the same master password. @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} |