[8122] in Release_7.7_team
Re: locked out of my debathena workstation
daemon@ATHENA.MIT.EDU (Alex T Prengel)
Mon Mar 16 13:24:00 2015
Message-ID: <1426526632.3844.1.camel@dit>
From: Alex T Prengel <alexp@mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Jonathan D Reed <jdreed@mit.edu>,
"release-team@mit.edu"
<release-team@mit.edu>, alexp@mit.edu
Date: Mon, 16 Mar 2015 13:23:52 -0400
In-Reply-To: <alpine.GSO.1.10.1503161246040.3953@multics.mit.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
I'm good now- Jon just fixed it. Thanks to everyone who helped!
A.
On Mon, 2015-03-16 at 12:48 -0400, Benjamin Kaduk wrote:
> On Sat, 14 Mar 2015, Jonathan D Reed wrote:
>
> > Oh, good call. That would make sense. Unfortunately, there’s no root
> > password for Alex to trivially log in and fix this. We can reboot into
> > single-user mode in person on Monday, of course. I vaguely wonder if
>
> Did this happen? I don't want Alex to be stuck with an unusable machine
> any longer than we need to.
>
> The 1DES host keytab does seem almost certain to be the issue here.
>
> > bumping the key in kadmin would trigger a different failure in pam_krb5,
> > such that Alex could log in, but I suspect not.
> >
> > If this turns out to be the cause, we’ll definitely need to do some
> > outreach (e.g. what jweiss has been doing with dialup users’ non-null
> > instances) before this goes into production, I guarantee there are other
> > machines out there which are in a similar state. Can a principal always
> > getprinc itself? I assume running kadmin in the maintainer script is a
> > terrible idea…
>
> I'm on the fence about whether adding a check with ktutil in the
> maintainer script is a good idea; we can probably ask for log-scraping of
> 1DES session keys issued for host/ principals. I guess I can take point
> on asking for those.
>
> -Ben
