@node Kerberos 4 issues, Acknowledgments, Setting up a realm, Top
@comment  node-name,  next,  previous,  up
@chapter Kerberos 4 issues

If compiled with version 4 support, the KDC can serve requests from a
Kerberos 4 client. There are a few things you must do for this to work.

@menu
* Principal conversion issues::  
* Converting a version 4 database::  
@end menu

@node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues
@section Principal conversion issues

First, Kerberos 4 and Kerberos 5 principals are different. A version 4
principal consists of a name, an instance, and a realm. A version 5
principal has one or more components, and a realm @footnote{for the
common case of one and two component principals, we will refer to the
first component as the ``name'' and the second as the ``instance''}.
Also, in some cases the name of a version 4 principal differs from the
first component of the corresponding version 5 principal. One notable
example is the ``host'' type principals, where the version 4 name is
@samp{rcmd} (for ``remote command''), and the version 5 name is
@samp{host}. For the class of principals that has a hostname as
instance, there is an other major difference, Kerberos 4 uses only the
first component of the hostname, whereas Kerberos 5 uses the fully
qualified hostname.

Because of this it can in the general case can be hard or impossible to
correctly convert a version 4 principal to a version 5 principal
@footnote{the other way is not always trivial either, but usually
easier}. The biggest problem is to know if the conversion resulted in a
valid principal. To give an example, suppose you want to convert the
principal @samp{rcmd.foo}. 

The @samp{rcmd} name suggests that the instance is a hostname (even if
there are exceptions to this rule). To correctly convert the instance
@samp{foo} to a hostname, you have to know which host it referred to. You
can to this by either guessing (from the realm) which domain name to
append, or you have to have a list of possible hostnames. In the
simplest cases you can cover most principals with the first rule. If you
have several domains sharing a single realm this will not usually
work. If the exceptions are few you can probably come by with a lookup
table for the exceptions.

In a complex scenario you will need some kind of host lookup mechanism.
Using DNS for this is tempting, but DNS is error prone, slow and unsafe
@footnote{at least until secure DNS is commonly available}.

Fortunately, the KDC has a trump on hand: it can easily tell if a
principal exists in the database. The KDC will use
@code{krb5_425_conv_principal_ext} to convert principals.

@node Converting a version 4 database,  , Principal conversion issues, Kerberos 4 issues
@section Converting a version 4 database

If you want to convert an existing version 4 database, the principal
conversion issue arises too.

If you simply convert a database, this conversion will only take place
once. It is also possible to run a version 5 KDC as a slave. In this
case this conversion will happen every time the database is propagated.
When doing this conversion, there are a few things to look out for. If
you have stale entries in the database, these entries will not be
converted. This might be because these principals are not used anymore,
or it might be just because the principal couldn't be converted. 

You might also see problems with a many-to-one mapping of
principals. For instance, if you are using DNS lookups and you have two
principals @samp{rcmd.foo} and @samp{rcmd.bar}, where `foo' is a CNAME
for `bar', the resulting principals will be the same. Since the
conversion function can't tell which is correct, these conflicts will
have to be resolved manually.