First off, it's important to understand the issues involved.

The main differences between V4 and V5 (for the purpose of this discussion)
are:

  1. The network protocol used is very different.
  2. The string-to-key algorithm is different.
  3. The format of the encrypted tickets is very different.

The MIT V5 KDC can speak the V4 protocol as well as the V5 protocol, so
difference number 1 isn't a big problem.

The MIT V5 KDC also supports the V4 string-to-key algorithm, and will use
this to encrypt tickets when it gets V4 requests. If you read Question 2.5,
then you already have your KDC set up to support this before you started
adding users :-).

The MIT distribution also included a special daemon called krb524d. This can
be used to convert an encrypted Kerberos 5 ticket into an encrypted Kerberos
4 ticket.

A number of the MIT application servers (telnetd, rlogind, rshd) support V4
clients as well as V5.

So, all of the pieces are there ... now, how do you use them?

If your application needs to get a Kerberos 4 TGT, then you need to
configure your KDC to support Kerberos 4 salted keys. You can tell if your
application needs to get a V4 TGT if you have to give it a Kerberos password
at some point.

If your application needs to get V4 service tickets, then you have the
option of using krb524init to convert your V5 TGT into a V4 TGT, and then
your application can use the V4 TGT to acquire V4 service tickets. Question
2.19 explains more about krb524init and krb524d.

If you can modify your application, then you can change it so it converts a
V5 service ticket into a V4 service ticket internally. This is the approach
used by the aklog program in the AFS-Kerberos 5 migration kit. Question 2.12
explains this in greater detail.

If you want to support a V4 application server, you need to create a V4
format keytab containing the principal used by the application server. You
can do this by using ktutil to convert a V5 format keytab into the
corresponding V4 keytab.

If you simply wish to support incoming Kerberos 4 telnet or rlogin, then all
you need to do is configure the daemons to support V4 connections. This is
done by an additional flag in inetd.conf for the Berkeley r-commands. The V4
compatibility routines can read a Kerberos 5 keytab, so there's no need to
copy it over.

There is a bug in telnetd that prevents it from talking correctly to V4
clients; to work around it, you simply need to create an empty /etc/srvtab.

There is one more important point when dealing with V4 clients. You should
never create V4 format principals in your KDC; you should use the V5 names.
For example, you shouldn't create rcmd.foo; you should instead always use
host/foo.bar.org

The KDC automatically converts back and forth between V4 and V5 principal
names at the appropriate times. This is trivial for user principals, but is
trickier for host-based principals. Since the instance was the "short" name
in V4 and is now fully qualified in V5, rules have to be configured to
convert between V4 and V5 instances. This is done via the default_domain and
the v4_instance_convert lines in krb5.conf.

The default_domain variable is used to indicate the DNS domain name that is
removed or added when converting between V4 and V5 principals. For example,
if you have:

[realms]
        FOO.BAR.ORG = {
                kdc = kdc1.foo.bar.org
                default_domain = foo.bar.org
        }

Then the V5 principal host/sun1.foo.bar.org will be converted to the V4
principal rcmd/sun1.

The v4_instance_convert variable is used to configure exceptions to the
default mapping rule. For example, let's say the above realm has a host
called foo.bar.org. Under V4 the host principal for this machine would be
called rcmd/foo, but the default_domain rule would fail to convert this
principal name correctly. However, if we place the following in in our
krb5.conf:

        v4_instance_convert = {
                foo = foo.bar.org
        }

Then the instance will be converted correctly.

Since all of these name translations take place on the KDC, you generally
only need to make sure the krb5.conf files on the KDC are the ones that are
up-to-date (but it's a good idea to keep the configuration file consistent
across machines).