>trudell: There are thousands of
>trudell: password entries in our NIS and we would like to load these
>trudell: entries and their passwords into AFS.
>tim: This wouldn't work for your passwords, obviously, but all the other
>tim: admin stuff would at least be done...
>tim: If you are REALLY serious about this (I wouldn't be, I want users to
>tim: start with new AFS passwords that HAVE NOT been sent over the network
>tim: in clear text thousands of times) I can't think of a "clean" solution
>tim: for you.
>trudell: Is there a documented
>trudell: method for doing this?
>tim: I'm not aware of any, but I'm sure some of the really big AFS sites
>tim: will have something for you.
I assume that NIS is using the standard Unix "crypt" call to convert
passwords to "unix" encrypted password strings. Since NIS and
AFS both use "one way" functions to convert passwords, and only
store the converted results, there isn't any good automatic way to
convert NIS password entries into AFS passwords. You could try
using "crack" on your NIS entries -- but that will only give you
the passwords you probably Don't want in your AFS cell.
A "clean" solution basically requires your users to help you, by
typing in their passwords. That's not really quite so bad as it
sounds; with a bit of work, you could make this almost invisible
to most users.
Behind the scenes, somewhere, you need a daemon that has the old
NIS database, The logical place to run this daemon is right on one
of the database servers, but it can run in any trusted location you
choose. Besides the NIS database, it would also need the key for
an admin instance in your ka database. Your users would "somehow"
create a secure session to the server using their password, then
the server, knowing the user's password, could set their AFS password
to be either the same or, if you prefer Tim's solution, you could
force the user to select a new password at this time. For extra
security, you would probably want your daemon to do this only
once per user, and after some period of time, you would likely
want to discontinue running the daemon, and make alternative
arrangements for those users who never managed to invoke
the daemon.
There are a variety of ways your users can get that "secure session".
In all cases, they somehow have to get to a program that you can provide
somewhere. If you think your NIS keys are private (I've no idea how
well protected they are against the bad guy), then you can use that
as the basis for making a secure session, and you can provide a program
that users could run on whatever machine they trust and you support,
be that DOS, or on Mac's, or some random Unix workstation in a
friend's basement. If you don't really trust your NIS keys,
then you need to somehow store a private key that only your program
can get to, and that means running it on trusted workstations. The
key itself doesn't need to be associated with any special privileges,
it's just protecting the "set my afs password' data on the wire.
(You could even use different keys on different workstations, and
change it daily, if you were really worried...)
There are several ways your users could run this program. The
simplest way would be just to have a special login that runs the
program directly. Since about the only thing the program
does is allow people to prove who they are, the special login
doesn't need its own password.
An even more elegant solution would be to bury this program into
"login". If "login" can find out that you haven't set your AFS
key yet (and there are any number of ways to do this), it could
then do the work of the special program, which would result
in the AFS password being set, "login" could then get tokens for the
user, and that would be that. If "login" sets the AFS password
to be the same, and doesn't tell the user, there's no reason why
most users would necessarily even realize or need to know this is happening.
So far as documentation on how to do this:
I assume Transarc documents the basic Ka calls you would
need to do this.
NIS no doubt has equivalent documentation on their calls
and database format.
If you modify login, you'll need to have source to that.
You would need to talk to your vendor, and to Transarc,
about this. Or, you could no doubt find any number of PD
versions of login (say, netbsd) and some modest
effort should produce an adequate substitute
(for most popular platforms.) [NeXT and AIX are "special
cases" -- ummm, but you don't want to know. Trust me.]
If you didn't want to start from scratch, you might be
able to make use of "uniqname" - the uniqname "daemon"
has to set passwords and manage a secure session with
the client end. By deleting the parts that don't
look like your program, you have a skeleton up pretty
fast with all the hard work done. If you would
find that useful, ask me for directions on how to ftp it.
Of course, all this supposes that you have enough users to justify
finding the programming talent & time to implement this. For
a few dozen users, it certainly wouldn't be worth it.
-Marcus Watts
UM ITD RS Umich Systems Group
