foo

git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@3150 ec53bebd-3082-4978-b11e-865c3cabbd6b

doc/kerberos4.texi

@@ -0,0 +1,74 @@
+@node Kerberos 4 issues, , 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 hostame, 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 comonly available}.
+
+Fortunately, the KDC has a trump on hand: it can easily tell if a
+principal exists in the databse. 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 inctance, 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.