[6973] in Kerberos
Re: kinit
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sun Mar 31 13:26:37 1996
To: tomryan@camlaw.rutgers.edu (Tom Ryan)
Cc: kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 31 Mar 1996 13:09:35 -0500
In-Reply-To: tomryan@camlaw.rutgers.edu's message of 28 Mar 1996 18:30:44 -0000
tomryan@camlaw.rutgers.edu (Tom Ryan) writes:
>
> I hacked away at kinit and proudly produced what i call kerblogin.
>
> kerblogin basically is a secondary authentication program that can be used
> in tandem with the shadow suite to do secondary checking of user logins.
>
> Once against the local (or nis databases) and second against the kerberos
> server.
I am not sure what you are trying to do, but it sounds like
you are operating under significantly different assumptions than the
Kerberos model. Basically, the point of Kerberos is to avoid storing
passwords in NIS or local password files. What do you hope to
accomplish by checking both? Are you doing some sort of phased
upgrade?
>
> One problem however :(
>
> Since login runs as root, the kinit part runs as root and hence root gets
> $LOGNAME tickets after the person logs on.
So, either chown the ticket file to the user, or run kdestroy.
One thing you should be aware of is that you may be vulnerable to a
substitue Kerberos server attack. Basically, an intruder can pretend
to be a Kerberos server, and then type the password at the keyboard
that the fake Kerberos server expects.
To protect against this attack, most people use the ticket
granting ticket obtained from running kinit to get tickets for the
host service of the machine you are logged into. For example, call
krb5_mk_req and then pass the result through krb5_rd_req to see if the
Kerberos server knows the correct host key. For this to work, your
host must have a srvtab; without a srvtab you cannot verify the
Kerberos server.
--Sam
