[Hmm... I think Ken is still maintaining the FAQ for this list.
If this isn't already in there, it probably should be....]
On Fri, 22 May 1998, Himanshu Juneja wrote:
> We are in the process of migrating over 5000 unix accounts (Solaris shadow file)
> into our existing afs cell and don't want all of these 5000 users to create a
> new password. Is it possible to take a scrambled password from the shadow file
> and create an entry in AFS kaserver database ? Or any other way(s) to make
> the password transition better ? I am sure other sites would have run into
> this problem. Any input/suggestions are greatly appreciated.
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 kaserver 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
kaserver.
Rather than having users type the DES key themselves, AFS uses a hash
function to translate the user's password into a key. 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, klog, or whatever), not by the kaserver - the user never
tells the kaserver 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.
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 kaserver 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
kaserver. 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
kaserver 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).
So, any kind of registration mechanism would require writing a fair bit of
code, or finding someone else who already has. If there's someone on this
list who has such a system working, I'd like to hear about it...
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
