[6176] in Kerberos
Re: Kerberos as alternative to NIS/Yellow Pages
daemon@ATHENA.MIT.EDU (Brian Kantor)
Wed Nov 8 11:16:25 1995
Date: Wed, 8 Nov 1995 08:02:52 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
To: kerberos@MIT.EDU, pmiles@tdc.dircon.co.uk
>Is anyone out there using Kerberos as an alternative to NIS/Yellow Pages
>(i.e. for centralised password management).
We are.
>One of my main concerns is that I understand that Kerberos uses it's own
>way on encypting passwords on the server. This may be a problem for us,
>as we have 10,000+ users with UNIX crypt()-based passwords, and we are
>not able to reissue them with new passwords. Can Kerberos be set to use
>standard UNIX password encryption (even at the cost of slightly lower
>security)?
No, it can't, as I understand it. That is because Kerberos, in its
current form, must use a type of encryption which is symmetrical - the
encrypted data can be decrypted. Unix password crypt can't be decrypted
in this way.
What we did was to simply Trojan-Horse our login routines for a while -
if the person's password was valid according to the old scheme, it
invoked a hacked-up version of kdb-edit to insert that same password
into the Kerberos database. Ditto the password-change routine. After
we'd run that way for a while, we had most everybody's password in the
Kerberos database and the exceptions are few enough that we handle them
manually.
>Also, do all applications which check the password file have to be modified,
Yes. We made a subroutine which simply does the same as a 'kinit' but
doesn't bother to write the ticket file to disk. That's how we validate
the password. It's used inside of 'login' and other places where the
password file used to be checked for the password.
NB: We still retain the password file entries to control login - if
you're not in the password file, you can't log in, etc. We just don't
check the contents of the password field in that entry any more, so the
only code that changes in the various programs is the single place where
the strcmp was done to check the encrypted password field - it's now a
call to the Kerberized subroutine.
- Brian
