svn rev #21545: trunk/doc/
ghudson@MIT.EDU
ghudson at MIT.EDU
Thu Dec 18 14:28:25 EST 2008
http://src.mit.edu/fisheye/changelog/krb5/?cs=21545
Commit By: ghudson
Log Message:
ticket: 6303
Remove documentation references to krb4 functionality we no longer
have. Remove the krb425 transition guide since we no longer have
compatibility code to assist with a transition.
Changed Files:
U trunk/doc/Makefile
U trunk/doc/admin.texinfo
U trunk/doc/definitions.texinfo
U trunk/doc/dnssrv.texinfo
U trunk/doc/install.texinfo
D trunk/doc/krb4-xrealm.txt
D trunk/doc/krb425.texinfo
D trunk/doc/old-V4-docs/
Modified: trunk/doc/Makefile
===================================================================
--- trunk/doc/Makefile 2008-12-18 18:31:16 UTC (rev 21544)
+++ trunk/doc/Makefile 2008-12-18 19:28:23 UTC (rev 21545)
@@ -26,11 +26,8 @@
USER_GUIDE_INCLUDES=definitions.texinfo copyright.texinfo glossary.texinfo
USER_GUIDE_DEPS=user-guide.texinfo $(USER_GUIDE_INCLUDES)
-KRB425_INCLUDES=definitions.texinfo copyright.texinfo
-KRB425_DEPS=krb425.texinfo $(KRB425_INCLUDES)
-
.PHONY: all
-all:: admin-guide-full install-guide-full user-guide-full krb425-guide-full clean-temp-ps clean-tex
+all:: admin-guide-full install-guide-full user-guide-full clean-temp-ps clean-tex
.PHONY: admin-guide-full
admin-guide-full:: admin-guide admin-guide-info admin-guide-html
@@ -118,28 +115,6 @@
$(MANTXT) $(SRCDIR)/kadmin/passwd/kpasswd.M | $(MANHTML) > kpasswd.html
$(HTML) user-guide.texinfo
-.PHONY: krb425-guide-full
-krb425-guide-full:: krb425-guide krb425-guide-info krb425-guide-html
-
-.PHONY: krb425-guide
-krb425-guide:: krb425-guide.ps
-
-krb425-guide.ps: $(KRB425_DEPS)
- $(DVI) krb425.texinfo
- $(DVIPS) krb425
-
-.PHONY: krb425-guide-html
-krb425-guide-html:: krb425.html
-
-krb425.html:: $(KRB425_DEPS)
- $(HTML) krb425.texinfo
-
-.PHONY: krb425-guide-info
-krb425-guide-info:: krb425.info
-
-krb425.info: $(KRB425_DEPS)
- $(INFO) krb425.texinfo
-
.PHONY: implementor.ps implementor.pdf implementor.info
implementor.pdf: implementor.ps
$(PSPDF) implementor.ps
Modified: trunk/doc/admin.texinfo
===================================================================
--- trunk/doc/admin.texinfo 2008-12-18 18:31:16 UTC (rev 21544)
+++ trunk/doc/admin.texinfo 2008-12-18 19:28:23 UTC (rev 21545)
@@ -502,18 +502,6 @@
code.
@end ignore
- at itemx krb4_srvtab
-Specifies the location of the Kerberos V4 srvtab file. Default is
- at value{DefaultKrb4Srvtab}.
-
- at itemx krb4_config
-Specifies the location of hte Kerberos V4 configuration file. Default
-is @value{DefaultKrb4Config}.
-
- at itemx krb4_realms
-Specifies the location of the Kerberos V4 domain/realm translation
-file. Default is @value{DefaultKrb4Realms}.
-
@itemx dns_lookup_kdc
Indicate whether DNS SRV records should be used to locate the KDCs and
other servers for a realm, if they are not listed in the information for
@@ -637,33 +625,7 @@
that application's man pages. The application defaults specified here
are overridden by those specified in the [realms] section.
-A special application name (afs_krb5) is used by the krb524 service to
-know whether new format AFS tokens based on Kerberos 5 can be used
-rather than the older format which used a converted Kerberos 4 ticket.
-The new format allows for cross-realm authentication without
-introducing a security hole. It is used by default. Older AFS
-servers (before OpenAFS 1.2.8) will not support the new format. If
-servers in your cell do not support the new format, you will need to
-add an @code{afs_krb5} relation to the @code{appdefaults} section.
-The following config file shows how to disable new format AFS tickets
-for the @code{afs.example.com} cell in the @code{EXAMPLE.COM} realm.
- at smallexample
- at group
-[appdefaults]
- afs_krb5 = @{
- EXAMPLE.COM = @{
- afs/afs.example.com = false
- @}
- @}
-
- at end group
- at end smallexample
-
-
-
-
-
@node login, realms (krb5.conf), appdefaults, krb5.conf
@subsection [login]
@@ -675,20 +637,6 @@
Indicate whether or not to use a user's password to get V5 tickets.
The default value is @value{DefaultKrb5GetTickets}.
- at itemx krb4_get_tickets
-Indicate whether or not to user a user's password to get V4 tickets.
-The default value is @value{DefaultKrb4GetTickets}.
-
- at itemx krb4_convert
-Indicate whether or not to use the Kerberos conversion daemon to get V4
-tickets. The default value is @value{DefaultKrb4Convert}. If this is
-set to false and krb4_get_tickets is true, then login will get the V5
-tickets directly using the Kerberos V4 protocol directly. This does
-not currently work with non-MIT-V4 salt types (such as the AFS3 salt
-type). Note that if this is set to true and krb524d is not running,
-login will hang for approximately a minute under Solaris, due to a
-Solaris socket emulation bug.
-
@itemx krb_run_aklog
Indicate whether or not to run aklog. The default value is
@value{DefaultKrbRunAklog}.
@@ -1493,14 +1441,8 @@
current implementation has little protection against denial-of-service
attacks), the standard port number assigned for Kerberos TCP traffic
is port 88.
+- at end table
- at itemx v4_mode
-This string specifies how the KDC should respond to Kerberos 4
-packets. The possible values are none, disable, full, and nopreauth.
-The default value is @value{DefaultV4Mode}.
- at comment these values found in krb5/src/kdc/kerberos_v4.c in v4mode_table
- at end table
-
@node realms (kdc.conf), pkinit kdc options, kdcdefaults, kdc.conf
@subsection [realms]
@@ -4353,7 +4295,6 @@
krb5_prop @value{DefaultKrbPropPort}/tcp # Kerberos slave propagation
@c kpop 1109/tcp # Pop with Kerberos
eklogin @value{DefaultEkloginPort}/tcp # Kerberos auth. & encrypted rlogin
-krb524 @value{DefaultKrb524Port}/tcp # Kerberos 5 to 4 ticket translator
@end group
@end smallexample
Modified: trunk/doc/definitions.texinfo
===================================================================
--- trunk/doc/definitions.texinfo 2008-12-18 18:31:16 UTC (rev 21544)
+++ trunk/doc/definitions.texinfo 2008-12-18 19:28:23 UTC (rev 21545)
@@ -131,10 +131,6 @@
@end ignore
@set DefaultKrb5GetTickets true
@comment login_krb5_get_tickets
- at set DefaultKrb4GetTickets false
- at comment login_krb4_get_tickets
- at set DefaultKrb4Convert false
- at comment login_krb4_convert
@set DefaultKrbRunAklog false
@comment login_krb_run_aklog
@set DefaultAklogPath $(prefix)/bin/aklog
@@ -143,13 +139,6 @@
@comment login_accept_password
@ignore
-the following defaults should be consistent with the values set in
-krb5/src/kdc/kerberos_v4
- at end ignore
- at set DefaultV4Mode none
- at comment KDC_V4_DEFAULT_MODE
-
- at ignore
these defaults are based on code in krb5/src/aclocal.m4
@end ignore
@set DefaultDNSLookupKDC true
@@ -175,14 +164,6 @@
@set DefaultFTPPort 21
@set DefaultKrb524Port 4444
- at comment src/include/kerberosIV/krb.h
- at set DefaultKrb4Srvtab /etc/srvtab
- at comment line 131
- at set DefaultKrb4Config /etc/krb.conf
- at comment KRB_CONF
- at set DefaultKrb4Realms /etc/krb.realms
- at comment KRB_RLM_TRANS
-
@comment krb5/src/lib/krb5/krb/get_in_tkt.c
@set DefaultRenewLifetime 0
@set DefaultNoaddresses set
Modified: trunk/doc/dnssrv.texinfo
===================================================================
--- trunk/doc/dnssrv.texinfo 2008-12-18 18:31:16 UTC (rev 21544)
+++ trunk/doc/dnssrv.texinfo 2008-12-18 19:28:23 UTC (rev 21545)
@@ -59,10 +59,6 @@
This should list port @value{DefaultKpasswdPort} on your master KDC.
It is used when a user changes her password.
- at item _kerberos-iv._udp
-This should refer to your KDCs that serve Kerberos version 4 requests,
-if you have Kerberos v4 enabled.
-
@end table
Be aware, however, that the DNS SRV specification requires that the
Modified: trunk/doc/install.texinfo
===================================================================
--- trunk/doc/install.texinfo 2008-12-18 18:31:16 UTC (rev 21544)
+++ trunk/doc/install.texinfo 2008-12-18 19:28:23 UTC (rev 21545)
@@ -206,9 +206,6 @@
@item
How frequently you will propagate the database from the master KDC to
the slave KDCs.
-
- at item
-Whether you need backward compatibility with Kerberos V4.
@end itemize
@menu
@@ -1184,17 +1181,6 @@
@smallexample
@group
-#
-# Note --- if you are using Kerberos V4 and you either:
-#
-# (a) haven't converted all your master or slave KDCs to V5, or
-#
-# (b) are worried about inter-realm interoperability with other KDC's
-# that are still using V4
-#
-# you will need to switch the "kerberos" service to port 750 and create a
-# "kerberos-sec" service on port 88.
-#
kerberos @value{DefaultPort}/udp kdc # Kerberos V5 KDC
kerberos @value{DefaultPort}/tcp kdc # Kerberos V5 KDC
klogin @value{DefaultKloginPort}/tcp # Kerberos authenticated rlogin
@@ -1208,13 +1194,6 @@
@end group
@end smallexample
- at noindent As described in the comments in the above code, if your master
-KDC or any of your slave KDCs is running Kerberos V4, (or if you will be
-authenticating to any Kerberos V4 KDCs in another realm) you will need
-to switch the port number for @code{kerberos} to 750 and create a
- at code{kerberos-sec} service (tcp and udp) on port 88, so the Kerberos
-V4 KDC(s) will continue to work properly.
-
@menu
* Mac OS X Configuration::
@end menu
Deleted: trunk/doc/krb4-xrealm.txt
===================================================================
--- trunk/doc/krb4-xrealm.txt 2008-12-18 18:31:16 UTC (rev 21544)
+++ trunk/doc/krb4-xrealm.txt 2008-12-18 19:28:23 UTC (rev 21545)
@@ -1,143 +0,0 @@
-The following text was taken from the patchkit disabling cross-realm
-authentication and triple-DES in krb4.
-
-PATCH KIT DESCRIPTION
-=====================
-
-** FLAG DAY REQUIRED **
-
-One of the things we decided to do (and must do for security reasons)
-was drop support for the 3DES krb4 TGTs. Unfortunately the current
-code will only accept 3DES TGTs if it issues 3DES TGTs. Since the new
-code issues only DES TGTs, the old code will not understand its v4
-TGTs if the site has a 3DES key available for the krbtgt principal.
-The new code will understand and accept both DES and 3DES v4 TGTs.
-
-So, the easiest upgrade option is to deploy the code on all KDCs at
-once, being sure to deploy it on the master KDC last. Under this
-scenario, a brief window exists where slaves may be able to issue
-tickets that the master will not understand. However, the slaves will
-understand tickets issued by the master throughout the upgrade.
-
-An alternate and more annoying upgrade strategy exists. At least one
-max TGT life time before the upgrade, the TGT key can be changed to be
-a single-des key. Since we support adding a new TGT key while
-preserving the old one, this does not create an interruption in
-service. Since no 3DES key is available then both the old and new
-code will issue and accept DES v4 TGTs. After the upgrade, the TGT
-key can again be rekeyed to add 3DES keys. This does require two TGT
-key changes and creates a window where DES is used for the v5 TGT, but
-creates no window in which slaves will issue TGTs the master cannot
-accept.
-
-* What the patch does
-=====================
-
-1) Kerberos 4 cross-realm authentication is disabled by default. A
- "-X" switch is added to both krb524d and krb5kdc to enable v4
- cross-realm. This switch logs a note that a security hole has been
- opened in the KDC log. We said while designing the patch, that we
- were going to try to allow per-realm configuration; because of a
- design problem in the kadm5 library, we could not do this without
- bumping the ABI version of that library. We are unwilling to bump
- an ABI version in a security patch release to get that feature, so
- the configuration of v4 cross-realm is a global switch.
-
-2) Code responsible for v5 TGTs has been changed to require that the
- enctype of the ticket service key be the same as the enctype that
- would currently be issued for that kvno. This means that even if a
- service has multiple keys, you cannot use a weak key to fake the
- KDC into accepting tickets for that service. If you have a non-DES
- TGT key, this separates keys used for v4 and v5. We actually relax
- this requirement for cross-realm TGT keys (which in the new code
- are only used for v5) because we cannot guarantee other Kerberos
- implementations will choose keys the same way.
-
-3) We no longer issue 3DES v4 tickets either in the KDC or krb524d.
- We add code to accept either DES or 3DES tickets for v4. None of
- the attacks discovered so far can be implemented given a KDC that
- accepts but does not issue 3DES tickets, so we believe that leaving
- this functionality in as compatibility for a version or two is
- reasonable. Note however that the attacks described do allow
- successful attackers to print future tickets, so sites probably
- want to rekey important keys after installing this update. Note
- also that even if issuance of 3DES v4 tickets has been disabled,
- outstanding tickets may be used to perform the 3DES cut-and-paste
- attack.
-
-* Test Cases
-============
-
-This code is difficult to test for two reasons. First, you need a
-cross-realm relationship between two KDCs. Secondly, you need a KDC
-that will issue 3DES v4 tickets even though the code with the patch
-applied can no longer do this.
-
-I propose to meet these requirements by setting up a cross-realm 3DES
-key between a realm I control and the test environment. In order to
-provide concrete examples of what I plan to test with the automated
-tests, I assume a shared key between a realm PREPATCH.KRBTEST.COM and the
-test realm PATCH.
-
-In all of the following tests I assume the following configuration.
-A principal v4test at PREPATCH.KRBTEST.COM exists with known password and
-without requiring preauthentication. The PREPATCH.KRBTEST.COM KDC will
-issue v4 tickets for this principal. A principal test at PATCH exists
-with known password and without requiring preauthentication. A
-principal service at PATCH exists. The TGT for the PATCH realm has a
-3des and des key. The shared TGT keys between PATCH and
-PREPATCH.KRBTEST.COM are identical in both directions (required for v4) and
-support both 3DES and DES keys.
-
-1) Run krb524d and krb5kdc for PATCH with no special options using a
- krb5.conf without permitted_enctypes (fully permissive).
-
-
-A) Get v4 tickets as v4test at PREPATCH.KRBTEST.COM. Confirm that kvno -4
-service at PATCH fails with an unknown principal error and logs an error
-about cross-realm being denied to the PATCH KDC log. This confirms
-that v4 cross-realm is not accepted.
-
-B) Get v5 tickets as v4test at PREPATCH.KRBTEST.COM. Confirm that krb524init
--p service at PATCH fails with a prohibited by policy error, but that
-klist -5 includes a ticket for service at PATCH. This confirms that v5
-cross-realm works but the krb524d denies converting such a ticket into
-a cross-realm ticket. Note that the krb524init currently in the
-mainline source tree will not be useful for this test because the
-client denies cross-realm for the simple reason that the v4 ticket
-file format is not flexible enough to support it. The krb524init in
-the 1.2.x release is useful for this test.
-
-
-2) Restart the krb5kdc and krb524d for PATCH with the -X option
- enabling v4 cross-realm.
-
-A) Confirm that the security warning is written to kdc.log.
-
-B) Get v4 tickets as v4test at PREPATCH.KRBTEST.COM. Confirm that kvno -4
-service at PATCH works and leaves a service at PATCH ticket in the cache.
-This confirms that v4 cross-realm works in the KDC. It also confirms
-that the KDC can accept 3DES v4 TGTs. The code path for decrypting a
-TGT is the same for the local realm and for foreign realms, so I don't
-see a need to test local 3DES TGTs in an automated manner although I
-did test it manually.
-
-C) Get v5 tickets as v4test at PREPATCH.KRBTEST.COM. Confirm that krb524init
--p service at PATCH works. This confirms that krb524d will issue
-cross-realm tickets. They're completely useless because the v4 ticket
-file can't represent them, but that's not our problem today.
-
-3) Start the kdc and krb524d with a krb5.conf that includes
- permitted_enctypes only listing des-cbc-crc. Get tickets as
- test at PATCH. Restart the KDC and confirm that kvno service fails
- logging an error about permitted enctypes. This confirms that if
- you manage to obtain a ticket of the wrong enctype it will not be
- accepted later.
-
-These tests do not check to make sure that 3DES tickets are not
-issued by the v4 code. I'm fairly certain that is true as I've
-physically remove the calls to the routine that generates 3DES tickets
-from the code in both the KDC and krb524d. These tests also do not
-check to make sure that cross-realm TGTs are not required to follow
-the strict enctype policy. I've tested that manually but don't know
-how to test that without significantly complicating the test setup.
Deleted: trunk/doc/krb425.texinfo
===================================================================
--- trunk/doc/krb425.texinfo 2008-12-18 18:31:16 UTC (rev 21544)
+++ trunk/doc/krb425.texinfo 2008-12-18 19:28:23 UTC (rev 21545)
@@ -1,322 +0,0 @@
-\input texinfo @c -*-texinfo-*-
- at c Note: the above texinfo file must include the "doubleleftarrow"
- at c definitions added by jcb.
- at c %**start of header
- at c guide
- at setfilename krb425.info
- at settitle Upgrading to Kerberos V5 from Kerberos V4
- at c @setchapternewpage odd @c chapter begins on next odd page
- at c @setchapternewpage on @c chapter begins on next page
- at c @smallbook @c Format for 7" X 9.25" paper
- at c %**end of header
-
- at paragraphindent 0
- at iftex
- at parskip 6pt plus 6pt
- at end iftex
-
- at dircategory Kerberos
- at direntry
-* krb425: (krb425). Upgrading to Kerberos V5 from V4
- at end direntry
-
- at include definitions.texinfo
- at set EDITION 1.0
- at set UPDATED May 22, 2003
-
- at finalout @c don't print black warning boxes
-
- at titlepage
- at title Upgrading to @value{PRODUCT} from Kerberos V4
- at subtitle Release: @value{RELEASE}
- at subtitle Document Edition: @value{EDITION}
- at subtitle Last updated: @value{UPDATED}
- at author @value{COMPANY}
-
- at page
- at vskip 0pt plus 1filll
-
- at end titlepage
-
- at node Top, Copyright, (dir), (dir)
-
- at ifinfo
-This document describes how to convert to @value{PRODUCT} from Kerberos V4.
- at end ifinfo
-
- at menu
-* Copyright::
-* Introduction::
-* Configuration Files::
-* Upgrading KDCs::
-* Upgrading Application Servers::
-* Upgrading Client machines::
-* Firewall Considerations::
- at end menu
-
- at node Copyright, Introduction, Top, Top
- at unnumbered Copyright
- at include copyright.texinfo
-
- at node Introduction, Configuration Files, Copyright, Top
- at chapter Introduction
-
-As with most software upgrades, @value{PRODUCT} is generally backward
-compatible but not necessarily forward compatible. The @value{PRODUCT}
-daemons can interoperate with Kerberos V4 clients, but most of the
-Kerberos V4 daemons can not interoperate with Kerberos V5 clients. This
-suggests the following strategy for performing the upgrade:
-
- at enumerate
- at item
- at strong{Upgrade your KDCs.} This must be done first, so that
-interactions with the Kerberos database, whether by Kerberos V5 clients
-or by Kerberos V4 clients, will succeed.
-
- at item
- at strong{Upgrade your servers.} This must be done before upgrading
-client machines, so that the servers are able to respond to both
-Kerberos V5 and Kerberos V4 queries.
-
- at item
- at strong{Upgrade your client machines.} Do this only after your KDCs and
-application servers are upgraded, so that all of your Kerberos V5
-clients will be talking to Kerberos V5 daemons.
- at end enumerate
-
- at node Configuration Files, Upgrading KDCs, Introduction, Top
- at chapter Configuration Files
-
-The Kerberos @code{krb5.conf} and KDC @code{kdc.conf} configuration
-files allow additional tags for Kerberos V4 compatibility.
-
- at menu
-* krb5.conf::
-* kdc.conf::
- at end menu
-
- at node krb5.conf, kdc.conf, Configuration Files, Configuration Files
- at section krb5.conf
-
-If you used the defaults, both when you installed Kerberos V4 and when
-you installed @value{PRODUCT}, you should not need to include any of
-these tags. However, some or all of them may be necessary for
-nonstandard installations.
-
- at menu
-* libdefaults::
-* realms (krb5.conf)::
-* AFS and the Appdefaults Section::
- at end menu
-
- at node libdefaults, realms (krb5.conf), krb5.conf, krb5.conf
- at subsection [libdefaults]
-
-In the [libdefaults] section, the following additional tags may be used:
-
- at table @b
- at item krb4_srvtab
-Specifies the location of the Kerberos V4 srvtab file. Default is
- at value{DefaultKrb4Srvtab}.
-
- at item krb4_config
-Specifies the location of the Kerberos V4 configuration file. Default
-is @value{DefaultKrb4Config}.
-
- at item krb4_realms
-Specifies the location of the Kerberos V4 domain/realm translation
-file. Default is @value{DefaultKrb4Realms}.
- at end table
-
- at node realms (krb5.conf), AFS and the Appdefaults Section, libdefaults, krb5.conf
- at subsection [realms]
-
-In the [realms] section, the following Kerberos V4 tags may be used:
- at table @b
- at itemx default_domain
-Identifies the default domain for hosts in this realm. This is needed
-for translating V4 principal names (which do not contain a domain name)
-to V5 principal names. The default is your Kerberos realm name,
-converted to lower case.
-
- at itemx v4_instance_convert
-This subsection allows the administrator to configure exceptions to the
-default_domain mapping rule. It contains V4 instances (tag name) which
-should be translated to some specific hostname (tag value) as the second
-component in a Kerberos V5 principal name.
-
- at itemx v4_realm
-This relation allows the administrator to configure a different
-realm name to be used when converting V5 principals to V4
-ones. This should only be used when running separate V4 and V5
-realms, with some external means of password sychronization
-between the realms.
-
- at end table
-
- at node AFS and the Appdefaults Section, , realms (krb5.conf), krb5.conf
- at subsection AFS and the Appdefaults Section
-
-Many Kerberos 4 sites also run the Andrew File System (AFS).
-
-Modern AFS servers (OpenAFS > 1.2.8) support the AFS 2b token format.
-This allows AFS to use Kerberos 5 tickets rather than version 4
-tickets, enabling cross-realm authentication. By default, the
- at file{krb524d} service will issue the new AFS 2b tokens. If you are
-using old AFS servers, you will need to disable these new tokens.
-Please see the documentation of the @code{appdefaults} section of
- at file{krb5.conf} in the Kerberos Administration guide.
-
-
-
- at node kdc.conf, , krb5.conf, Configuration Files
- at section kdc.conf
-
-Because Kerberos V4 requires a different type of salt for the encryption
-type, you will need to change the @code{supported_enctypes} line in the
-[realms] section to:
-
- at smallexample
-supported_enctypes = des-cbc-crc:normal des-cbc-crc:v4
- at end smallexample
-
-This is the only change needed to the @code{kdc.conf} file.
-
- at node Upgrading KDCs, Upgrading Application Servers, Configuration Files, Top
- at chapter Upgrading KDCs
-
-To convert your KDCs from Kerberos V4 to @value{PRODUCT}, do the
-following:
-
- at enumerate
- at item
-Install @value{PRODUCT} on each KDC, according to the instructions in
-the @value{PRODUCT} Installation Guide, up to the point where it tells
-you to create the database.
-
- at item
-Find the @code{kadmind} (V4) daemon process on the master KDC and kill
-it. This will prevent changes to the Kerberos database while you
-convert the database to the new Kerberos V5 format.
-
- at item
-Create a dump of the V4 database in the directory where your V5 database
-will reside by issuing the command:
-
- at smallexample
-% kdb_util dump @value{ROOTDIR}/var/krb5kdc/v4-dump
- at end smallexample
-
- at item
-Load the V4 dump into a Kerberos V5 database, by issuing the command:
-
- at smallexample
-% kdb5_util load_v4 v4-dump
- at end smallexample
-
- at item
-Create a Kerberos V5 stash file, if desired, by issuing the command:
-
- at smallexample
-% kdb5_util stash
- at end smallexample
-
- at item
-Proceed with the rest of the @value{PRODUCT} installation as described
-in the @value{PRODUCT} Installation Guide. When you get to the section
-that tells you to start the @code{krb5kdc} and @code{kadmind} daemons,
-first find and kill the Kerberos V4 @code{kerberos} daemon on each of
-the KDCs. Then start the @code{krb5kdc} and @code{kadmind} daemons as
-You will need to specify an argument to the @code{-4} command line option to enable Kerberos 4 compatibility.
-See the @code{krb5kdc} man page for details.
-directed. Finally, start the Kerberos V5 to V4 ticket translator
-daemon, @code{krb524d}, by issuing the command:
-
- at smallexample
-% @value{ROOTDIR}/sbin/krb524d -m > /dev/null &
- at end smallexample
-
-If you have a stash file and you start the @code{krb5kdc} and
- at code{kadmind} daemons at boot time, you should add the above line to
-your @code{/etc/rc} (or @code{/etc/rc.local}) file on each KDC.
- at end enumerate
-
- at node Upgrading Application Servers, Upgrading Client machines, Upgrading KDCs, Top
- at chapter Upgrading Application Servers
-
-Install @value{PRODUCT} on each application server, according to the
-instructions in the @value{PRODUCT} Installation Guide, with the
-following exceptions:
-
- at itemize @bullet
- at item
-In the file @code{/etc/services}, add or edit the lines described in the
- at value{PRODUCT} Installation Guide, with the following exception:
-
-in place of:
-
- at smallexample
- at group
-kerberos @value{DefaultPort}/udp kdc # Kerberos V5 KDC
-kerberos @value{DefaultPort}/tcp kdc # Kerberos V5 KDC
- at end group
- at end smallexample
-
- at noindent
-add instead:
-
- at smallexample
- at group
-kerberos-sec @value{DefaultPort}/udp kdc # Kerberos V5 KDC
-kerberos-sec @value{DefaultPort}/tcp kdc # Kerberos V5 KDC
- at end group
- at end smallexample
-
- at item
-Convert your Kerberos V4 srvtab file to Kerberos V5 keytab file as
-follows:
-
- at smallexample
- at group
- at b{#} @value{ROOTDIR}/sbin/ktutil
- at b{ktutil:} rst /etc/krb-srvtab
- at b{ktutil:} wkt /etc/krb5.keytab
- at b{ktutil:} q
- at b{#}
- at end group
- at end smallexample
- at end itemize
-
- at node Upgrading Client machines, Firewall Considerations, Upgrading Application Servers, Top
- at chapter Upgrading Client machines
-
-Install @value{PRODUCT} on each client machine, according to the
-instructions in the @value{PRODUCT} Installation Guide.
-
-Tell your users to add the appropriate directory to their paths. On
-UNIX machines, this will probably be @code{@value{BINDIR}}.
-
-Note that if you upgrade your client machines before all of your
-application servers are upgraded, your users will need to use the
-Kerberos V4 programs to connect to application servers that are still
-running Kerberos V4. (The one exception is the UNIX version of
- at value{PRODUCT} telnet, which can connect to a Kerberos V4 and Kerberos
-V5 application servers.) Users can use either the Kerberos V4 or
- at value{PRODUCT} programs to connect to Kerberos V5 servers.
-
- at node Firewall Considerations, , Upgrading Client machines, Top
- at chapter Firewall Considerations
-
- at value{PRODUCT} uses port @value{DefaultPort}, which is the port
-assigned by the IETF, for KDC requests. Kerberos V4 used port
- at value{DefaultSecondPort}. If your users will need to get to any KDCs
-outside your firewall, you will need to allow TCP and UDP requests on
-port @value{DefaultPort} for your users to get to off-site Kerberos V5
-KDCs, and on port @value{DefaultSecondPort} for your users to get to
-off-site Kerberos V4 KDCs.
-
- at contents
- at c second page break makes sure right-left page alignment works right
- at c with a one-page toc, even though we don't have setchapternewpage odd.
- at c end of texinfo file
- at bye
More information about the cvs-krb5
mailing list