[21076] in Athena Bugs
Re: Login puzzle
daemon@ATHENA.MIT.EDU (Tom Cavin)
Thu Nov 14 16:35:15 2002
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15828.5904.15736.489720@lap1-wccf.mit.edu>
Date: Thu, 14 Nov 2002 16:35:12 -0500
From: Tom Cavin <cavin@MIT.EDU>
To: SIPB Linux Help <linux-help@MIT.EDU>
CC: Athena Bugs list <bugs@MIT.EDU>
In-Reply-To: <1037300459.11445.336.camel@error-messages.mit.edu>
Hi All,
Kevin, Derek, and Greg all provided very informative responses and the
system is now up and running. My thanks to each of you.
The original error happened because someone was momentarily confused and
forgot that the "ksrvutil change" command made syncronized changes in the
local file and the KDC. A reinstall of the system followed by a reuse of
the original (and no longer valid) srvtab file caused the version skew.
(Greg: this was the confusion that I mentioned earlier.)
I hadn't realized that the existance of a srvtab or keytab file for remote
access actually changes the local console login process. Nor did I realize
that the kerberos libraries will use either the srvtab or keytab files and
will look for both.
I do have some follow-on questions:
1. If I understand this correctly, the srvtab/keytab file is used to tie
the host to the issuing KDC. A public Athena workstation -- without
a srvtab -- could conceivably be spoofed by a fake KDC and the user
could then login with tickets that were not valid for the real KDC.
How would a user be able to determine whether they had been spoofed?
2. When a user gets a new system, passes their old host down the food
chain, and keeps their old hostname for their new system, the old
host with a srvtab/keytab is renamed by making a change in the
rc.conf file and rebooting. Will this cause problems on the old
system at login? Is the solution to simply get new srvtabs from
accounts for both systems?
3. If a host has a bad srvtab/keytab file for any reason, will removing
both /etc/athena/srvtab and /etc/krb5.keytab temporarily fix things
to allow console login until a new srvtab is received from accounts?
Or will the fact that a srvtab/keytab record exists in the KDC cause
difficulties when there is no matching local record?
4. If a srvtab/keytab for a host changes on the host and the KDC (so
that they both now agree), are there any other copies of the old
srvtab/keytab information or any tickets or other keys that are
derived from the old srvtab/keytab that would remain active and need
to be fixed? (This might be an existing ssh session, a KNFS mount,
or a token for an AFS file server.) And if so, how can these
problems be fixed?
5. If both a srvtab and a keytab file exist on the same system, which
one is checked first? Does this depend on the application? And are
they ever directly compared to verify that they agree?
As I stated earlier, the original problem is now resolved. These questions
now merely relate to my desire for better srvtab hygiene. :-)
Thanks,
--Tom
--
Tom Cavin Phone: (617) 258 - 7806
Computer Operations Manager Email: cavin@mit.edu
MIT - Whitaker College Computer Facility or tec@ai.mit.edu
