[14699] in Kerberos
Re: Uninstalling Kerberos
daemon@ATHENA.MIT.EDU (Marcus Watts)
Sun Jul 22 02:03:45 2001
Message-Id: <200107220559.BAA18568@quince.ifs.umich.edu>
To: kerberos@MIT.EDU
In-reply-to: Your message of "21 Jul 2001 23:45:34 EDT."
<w4o4rs5lj8h.fsf@eco-wks5.cinci.irtnog.org>
Date: Sun, 22 Jul 2001 01:59:03 -0400
From: Marcus Watts <mdw@umich.edu>
xenophon@irtnog.org (Matthew X. Economou) writes:
...
> >>>>> "Bill" == Bill Smith <apobull@alum.drexel.edu> writes:
>
> Bill> We would very much like to just remove kerberos on these
> Bill> systems and go back to the standard login.
>
> You may need to fiddle with the PAM configuration; basically, comment
> out the lines referring to pam_krb4.so. Otherwise, there isn't much
> to do. You'll already have usernames in /etc/passwd or NIS, simply
> put regular passwords on the accounts by hand with passwd or yppasswd.
>
> I know of no way to convert the Kerberos databases into a Unix-style
> password database.
...
There are certainly ways to do this, if you're willing to do some
coding. The simplest solution would probably be to write a pam module
that authenticates against K4, retains the cleartext password, and if
the authentication succeeds, changes the local password to match. The
local password could be changed either using the native APIs (for
"file"--lckpwdf, fgetpwent, putpwent, rename; for "nis", perhaps
clnt_create, authunix_create_default, clnt_call passing in
YPPASSWDPROC_UPDATE), or with some work (dlopen, dlsym, dlclose) it
should be possible to make another pam handle, load pam_unix.so, and
invoke pam_sm_chauthtok (or, with the right service in pam.conf, yhou
could let pam do the shared library stuff and just call pam_start &
pam_chauthtok.) This approach should work fine if you expect most or
all of your users to access your service in a fairly short time-frame
-- shorter than the period in which you're willing to run the KDC in
parallel.
If you were in a hurry to get rid of the kdc, then a solution that
would work would be to write a tool that extracts all the keys out of
the kdc and stores them in some *well protected* file on the local
machine. Then write a pam module that uses string to key to encrypt
the user's password into the same key, and compare that key against the
file extracted from the kdc. You might want to run the keys through an
additional one-way hash with additional "salt" (either the loginid or a
random number), if you were really worried - I don't think the default
kerberos string to key functions are all that well hardened against
something like "crack". This is more work than just running the kdc a
bit longer in parallel, but should work. If you have a lot of users
who don't access the system often enough to be caught by the first
approach, you might find this preferable.
Yet another approach would be to replace 'crypt' in libc.a/libc.so with
something that implements the MIT string to key function, if given a
special salt (say, a salt that starts with "$k4".), and falls back on
the stock Unix crypt algorithm, otherwise. You can get ahold of source
for the stock algorithm in any of the various free bsd/linux
derivatives. Convert the result from the kerberos string to key
function into a 13 character string starting with "$k4" (using base-85,
you can encode 64 bits into 10 characters. Don't use \;:,! in your
hash.) You could probably get away with more than 13 characters, but
13 is playing it safe. All of the various Unix tools that hash
passwords have logic that looks something like this:
strcmp(pw->pw_passwd, crypt(cleartext_password, pw->pw_passwd)
so, so long as your hash works the same way, you should be all set.
You'll need to use the library:
/usr/lib/pics/libc_pic.a
in order to build a replacement libc.so. Be very very careful - most tools
*require* a working libc.so, so if you botch things, especially
in the critical step where you switch from the old to the new
libc, you may end wind up in no-mans land, where nothing works. In that
case, may have to boot off CD-rom to put things back. You might
want to check to make sure you have a bootable CD-rom, and that
the machines don't have anything awkward like a rom boot password (which
is generally a bad idea anyways.)
-Marcus Watts
UM ITCS Umich Systems Group
