From: Jeffrey Hutzelman <jhutz@cmu.edu>

     It does you no good to know the contents of the password field in
     /etc/passwd or /etc/shadow; to do this you would have to know the
     user's actual password. Note that the entry you see in /etc/shadow
     is not merely scrambled; it is the result of passing the user's
     password through a one-way hash function. That is, it's easy to
     compute the scrambled value from the plaintext, but very, very
     hard to go the other way. If this weren't so, then any user could
     look at the password field in /etc/passwd (on systems without
     shadow passwords), compute the password of anyone they liked, and
     then log in as that person.

     The values that are actually stored in the Kerberos database are
     the result of applying a different one-way hash function to the
     user's password. Now, you might ask why they don't use the same
     function, to make the conversion process easy. There are two
     reasons for this, but they both stem from the fact that in AFS (or
     Kerberos, for that matter), the output of the hash function is
     used as a DES encryption key, which is used to encrypt sensitive
     data passed between the user and the Kerberos server.

     Rather than having users type the DES key themselves, Kerberos
     uses a hash function to translate the user's password into a key
     (note: See Question 1.23 for more information). This means the
     user gets to remember an easy-remember word, phrase, or whatever,
     and you still get a good distribution of keys. However, this
     operation is done by the client (login, kinit, or whatever), not
     by the Kerberos server - the user never tells the Kerberos server
     his password; he merely proves that he knows it. An attacker who
     knows the key but not the password used to produce it can still
     authenticate just as if he were the user.

     (Ed note: This isn't technically true in V5 - you do tell the
     admin server your password when you change it, but that's so it
     can perform password strength checking on it. But it doesn't get
     stored; The Kerberos database stores keys, not passwords).

     Since anyone who knows a user's key could become the user, it
     would be a Bad Thing(tm) to use a predictable value for the user's
     key, like the contents of the password field in /etc/passwd from
     just before the conversion. Since anyone could see that file,
     every user's key would essentially be publicly-known!

     So, now that we know that there is no easy way to "convert" the
     existing Unix passwords to something the Kerberos server can use,
     you still have a problem. The usual solution is to set up a
     registration mechanism, where users run some program, give it
     their UNIX password, and the program verifies the password against
     /etc/passwd and then registers it with the Kerberos server.
     Ideally, this would be done automatically in login, so that any
     user who logged in (except root!) would be converted
     automatically.

     The problem here is that in order to register the user's password,
     your registration program (or login) must be able to authenticate
     to the Kerberos server as an administrator. Or, it must be able to
     authenticate to a separate registration service, which itself is
     an administrator and enforces certain restrictions (i.e. a user
     can only be registered once).

I have heard of sites modifying login to use the host key stored on machines
for this purpose, and giving the host principal the ability to add accounts
via the admin server (obviously, this is for Kerberos 5 only). However, no
one has made such code publically available.