DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH
 

(heimdal.info.gz) Converting a version 4 database

Info Catalog (heimdal.info.gz) Principal conversion issues (heimdal.info.gz) Kerberos 4 issues (heimdal.info.gz) kaserver
 
 7.2 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
 `rcmd.foo' and `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.
 
 7.2.1 Conversion example
 ------------------------
 
 Given the following set of hosts and services:
 
      foo.se          rcmd
      mail.foo.se     rcmd, pop
      ftp.bar.se      rcmd, ftp
 
 you have a database that consists of the following principals:
 
 `rcmd.foo', `rcmd.mail', `pop.mail', `rcmd.ftp', and `ftp.ftp'.
 
 lets say you also got these extra principals: `rcmd.gone',
 `rcmd.old-mail', where `gone.foo.se' was a machine that has now passed
 away, and `old-mail.foo.se' was an old mail machine that is now a CNAME
 for `mail.foo.se'.
 
 When you convert this database you want the following conversions to be
 done:
      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        removed
      rcmd.old-mail    removed
 
 A `krb5.conf' that does this looks like:
 
      [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
              }
 
 The `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 `rcmd' should be converted to
 `host'). The `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 `v4_instance_convert' are qualified by appending
 the contents of the `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 `rcmd.gone' to `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 `default_domain' statement,
 but then you will have to add entries for _all_ your hosts in the
 `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 `v4_instance_resolve' in the
 `[libdefaults]' section.
 
 7.2.2 Converting a database
 ---------------------------
 
 The database conversion is done with `hprop'. You can run this command
 to propagate the database to the machine called `slave-server' (which
 should be running a `hpropd').
 
      hprop --source=krb4-db --master-key=/.m slave-server
 
 This command can also be to use for converting the v4 database on the
 server:
 
      hprop -n --source=krb4-db -d /var/kerberos/principal --master-key=/.m | hpropd -n
 
 7.3 Version 4 Kadmin
 ====================
 
 `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).
 
 _And then there are a many more things you can do; more on this in a
 later version of this manual. Until then, UTSL._
 
Info Catalog (heimdal.info.gz) Principal conversion issues (heimdal.info.gz) Kerberos 4 issues (heimdal.info.gz) kaserver
automatically generated byinfo2html