Thanks a lot for the informative email, i knew that the hash is one way and
the two hashes are different, but was hoping that kerb. designers might have
thought of this problem and there could be a translation mech. But that's too
much to expect...
What we are thinking is on the line of the registration mech. you suggested,
Initial idea is to have the reg. mech run as a login shell and request a
new password and have a cron job process that info and update the password
file with a new login shell. If anybody else has done similar work and is
willing to contribute, that'll be great.
Thanks
Himanshu Juneja
Engg. Computing, CSD
New Jersey Inst. of Tech.
{ MIME-Version: 1.0
{
{ [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
{
{
