diff options
Diffstat (limited to 'crypto/heimdal/doc/kerberos4.texi')
| -rw-r--r-- | crypto/heimdal/doc/kerberos4.texi | 226 |
1 files changed, 0 insertions, 226 deletions
diff --git a/crypto/heimdal/doc/kerberos4.texi b/crypto/heimdal/doc/kerberos4.texi deleted file mode 100644 index 42a5f898f17ec..0000000000000 --- a/crypto/heimdal/doc/kerberos4.texi +++ /dev/null @@ -1,226 +0,0 @@ -@c $Id: kerberos4.texi,v 1.16 2001/07/19 17:17:46 assar Exp $ - -@node Kerberos 4 issues, Windows 2000 compatability, Things in search for a better place, 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. - -The KDC will also have kaserver emulation and be able to handle -AFS-clients that use @code{klog}. - -@menu -* Principal conversion issues:: -* Converting a version 4 database:: -* kaserver:: -@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 (the terms ``name'' -and ``instance'' are still used, for the first and second component, -respectively). 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 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 is referring -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 when handling -to version 4 requests. - -@node Converting a version 4 database, kaserver , 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 decide to convert your database once and for all, you will only -have to do this conversion once. It is also possible to run a version 5 -KDC as a slave to a version 4 KDC. 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. - -@subsection Conversion example - -Given the following set of hosts and services: - -@example -foo.se rcmd -mail.foo.se rcmd, pop -ftp.bar.se rcmd, ftp -@end example - -you have a database that consists of the following principals: - -@samp{rcmd.foo}, @samp{rcmd.mail}, @samp{pop.mail}, @samp{rcmd.ftp}, and -@samp{ftp.ftp}. - -lets say you also got these extra principals: @samp{rcmd.gone}, -@samp{rcmd.old-mail}, where @samp{gone.foo.se} was a machine that has -now passed away, and @samp{old-mail.foo.se} was an old mail machine that -is now a CNAME for @samp{mail.foo.se}. - -When you convert this database you want the following conversions to be -done: -@example -rcmd.foo host/foo.se -rcmd.mail host/mail.foo.se -pop.mail pop/mail.foo.se -rcmd.ftp host/ftp.bar.se -ftp.ftp ftp/ftp.bar.se -rcmd.gone @i{removed} -rcmd.old-mail @i{removed} -@end example - -A @file{krb5.conf} that does this looks like: - -@example -[realms] - FOO.SE = @{ - v4_name_convert = @{ - host = @{ - ftp = ftp - pop = pop - rcmd = host - @} - @} - v4_instance_convert = @{ - foo = foo.se - ftp = ftp.bar.se - @} - default_domain = foo.se - @} -@end example - -The @samp{v4_name_convert} section says which names should be considered -having an instance consisting of a hostname, and it also says how the -names should be converted (for instance @samp{rcmd} should be converted -to @samp{host}). The @samp{v4_instance_convert} section says how a -hostname should be qualified (this is just a hosts-file in -disguise). Host-instances that aren't covered by -@samp{v4_instance_convert} are qualified by appending the contents of -the @samp{default_domain}. - -Actually, this example doesn't work. Or rather, it works to well. Since -it has no way of knowing which hostnames are valid and which are not, it -will happily convert @samp{rcmd.gone} to @samp{host/gone.foo.se}. This -isn't a big problem, but if you have run your kerberos realm for a few -years, chances are big that you have quite a few `junk' principals. - -If you don't want this you can remove the @samp{default_domain} -statement, but then you will have to add entries for @emph{all} your hosts -in the @samp{v4_instance_convert} section. - -Instead of doing this you can use DNS to convert instances. This is not -a solution without problems, but it is probably easier than adding lots -of static host entries. - -To enable DNS lookup you should turn on @samp{v4_instance_resolve} in -the @samp{[libdefaults]} section. - -@subsection Converting a database - -The database conversion is done with @samp{hprop}. You can run this -command to propagate the database to the machine called -@samp{slave-server} (which should be running a @samp{hpropd}). - -@example -hprop --source=krb4-db --master-key=/.m slave-server -@end example - -This command can also be to use for converting the v4 database on the -server: - -@example -hprop -n --source=krb4-db -d /var/kerberos/principal --master-key=/.m | hpropd -n -@end example - -@section Version 4 Kadmin - -@samp{kadmind} can act as a version 4 kadmind, and you can do most -operations, but with some restrictions (since the version 4 kadmin -protocol is, lets say, very ad hoc.) One example is that it only passes -des keys when creating principals and changing passwords (modern kpasswd -clients do send the password, so it's possible to to password quality -checks). Because of this you can only create principals with des keys, -and you can't set any flags or do any other fancy stuff. - -To get this to work, you have to add another entry to inetd (since -version 4 uses port 751, not 749). - -@emph{And then there are a many more things you can do; more on this in -a later version of this manual. Until then, UTSL.} - -@node kaserver, , Converting a version 4 database, Kerberos 4 issues -@section kaserver - -@subsection kaserver emulation - -The Heimdal kdc can emulate a kaserver. The kaserver is a Kerberos 4 -server with pre-authentication using Rx as the on-wire protocol. The kdc -contains a minimalistic Rx implementation. - -There are three parts of the kaserver; KAA (Authentication), KAT (Ticket -Granting), and KAM (Maintenance). The KAA interface and KAT interface -both passes over DES encrypted data-blobs (just like the -Kerberos-protocol) and thus do not need any other protection. The KAM -interface uses @code{rxkad} (Kerberos authentication layer for Rx) for -security and data protection, and is used for example for changing -passwords. This part is not implemented in the kdc. - -Another difference between the ka-protocol and the Kerberos 4 protocol -is that the pass-phrase is salted with the cellname in the @code{string to -key} function in the ka-protocol, while in the Kerberos 4 protocol there -is no salting of the password at all. To make sure AFS-compatible keys -are added to each principals when they are created or their password are -changed, @samp{afs3-salt} should be added to -@samp{[kadmin]default_keys}. - -@subsection Transarc AFS Windows client - -The Transarc Windows client uses Kerberos 4 to obtain tokens, and thus -does not need a kaserver. The Windows client assumes that the Kerberos -server is on the same machine as the AFS-database server. If you do not -like to do that you can add a small program that runs on the database -servers that forward all kerberos requests to the real kerberos -server. A program that does this is @code{krb-forward} -(@url{ftp://ftp.stacken.kth.se/pub/projekts/krb-forward}). |