[38568] in Kerberos
Re: kvno X not found in keytab; ticket is likely out of date
daemon@ATHENA.MIT.EDU (Charles Hedrick)
Mon Jul 22 09:34:15 2019
From: Charles Hedrick <hedrick@rutgers.edu>
To: Laura Smith <n5d9xq3ti233xiyif2vp@protonmail.ch>
Date: Mon, 22 Jul 2019 13:33:49 +0000
Message-ID: <88D8D4FC-A366-4038-AB43-D01396AF1246@rutgers.edu>
In-Reply-To: <qC66Xji8caLcwS8MBJDDiaDE8vSvEmic3paP5N-MIep9omLn-AlRaCXtrbgypcSzGA5UzmjMcARI0saVeLOCd3JvPk3pb2Q2GsPOwOUDDUI=@protonmail.ch>
Content-Language: en-US
Content-ID: <797B5E3D76A95249959E7F34F946F03D@namprd14.prod.outlook.com>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Probably. If I interpret your email, you recreated the key table for the server. I assume you either rebooted the server or restarted everything relevant (most critical would be rpc.svcgssd).
I agree that rebooting clients would probably do it on the client side, except that not all systems are set up to clear /tmp on reboot. I don’t think that’s critical, but I can’t guarantee it.
> On Jul 22, 2019, at 9:26 AM, Laura Smith <n5d9xq3ti233xiyif2vp@protonmail.ch> wrote:
>
> Hi Charles,
>
> Surely the action of rebooting the client would do all of that ?
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, July 22, 2019 2:13 PM, Charles Hedrick <hedrick@rutgers.edu> wrote:
>
>> Unfortunately it’s likely to take some experimentation. My starting point would be on each client, unmount the file system, maybe delete /tmp/krb5ccmachine*, restart rpc.gssd, and remount.
>>
>>> On Jul 22, 2019, at 6:22 AM, Laura Smith n5d9xq3ti233xiyif2vp@protonmail.ch wrote:
>>> Ok, I hold my hand up, I messed up. So the question is, how do I get myself out of this mess ?
>>> A summary of how I got here:
>>> • I have an NFS server and a bunch of clients connecting and auth using krb5.
>>> • This was all working beautifully.... until today.
>>> • Through an act of pure fat-fingered stupidity, I ran "addprinc -randkey nfs/name.of.nfs.server" when setting up a new NFS client (i.e used server name instead of client name).
>>> • Now everything is broken (none of the NFS clients can connect to the server and I am seeing the error messages below on the NFS server).
>>> • keytab on NFS server only had credentials for NFS server, so I deleted the keytab and created a new one through ktadd
>>> • that didnt' work. a reboot of the NFS server didn't work.
>>> Summary ? I'm up a smelly creek without a paddle !
>>> Messages on NFS server:
>>> 2019-07-22T11:01:35.075247+01:00 foo rpc.svcgssd[847]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Request ticket server nfs/foo.example.com@EXAMPLE.CORP kvno 3 not found in keytab; ticket is likely out of date
>>> 2019-07-22T11:01:39.460944+01:00 foo rpc.svcgssd[847]: message repeated 41 times: [ ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Request ticket server nfs/foo.example.com@EXAMPLE.CORP kvno 3 not found in keytab; ticket is likely out of date]
>>>
>>> Kerberos mailing list Kerberos@mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
