Dear Benjamin, dear Andrew, dear list,
thank you very much for discussing the details of this keytab problem.
The kvno in the kdc is indeed zero. I don't remember how this
happened. Since we have been working without rxkad-k5 since now, my
solution is to rectify the kvno issue by rekeying d
On Mon, 10 Nov 2014, Andrew Deason wrote:
> On Mon, 10 Nov 2014 22:23:51 -0500 (EST)
> Benjamin Kaduk wrote:
>
> > On Mon, 10 Nov 2014, Andrew Deason wrote:
> >
> > > On Mon, 10 Nov 2014 14:24:49 +0100
> > > Volkmar Glauche wrote:
> > >
> > > > I've never used kaserver/kerberos4, but maybe I fol
On Mon, 10 Nov 2014 22:23:51 -0500 (EST)
Benjamin Kaduk wrote:
> On Mon, 10 Nov 2014, Andrew Deason wrote:
>
> > On Mon, 10 Nov 2014 14:24:49 +0100
> > Volkmar Glauche wrote:
> >
> > > I've never used kaserver/kerberos4, but maybe I followed installation
> > > guidelines that still had kaserver
On Mon, 10 Nov 2014, Andrew Deason wrote:
> On Mon, 10 Nov 2014 14:24:49 +0100
> Volkmar Glauche wrote:
>
> > I've never used kaserver/kerberos4, but maybe I followed installation
> > guidelines that still had kaserver in mind and proposed kvno=0. Would
> > bumping the kvno affect existing token
On Mon, 10 Nov 2014 14:24:49 +0100
Volkmar Glauche wrote:
> I've never used kaserver/kerberos4, but maybe I followed installation
> guidelines that still had kaserver in mind and proposed kvno=0. Would
> bumping the kvno affect existing tokens/Keyfiles that are still
> relying on kvno=0? If so,
On 11/7/2014 12:42 PM, Benjamin Kaduk wrote:
> On Fri, 7 Nov 2014, Brandon Allbery wrote:
>
>> On Fri, 2014-11-07 at 11:15 -0600, Andrew Deason wrote:
>>> It seems likely the 0 kvno is the problem. We only copy in a principal
>>> if the kvno in the keytab is greater than 'vno' in
>>> akimpersonate
On Fri, 7 Nov 2014, Brandon Allbery wrote:
> On Fri, 2014-11-07 at 11:15 -0600, Andrew Deason wrote:
> > It seems likely the 0 kvno is the problem. We only copy in a principal
> > if the kvno in the keytab is greater than 'vno' in
> > akimpersonate.c:pick_principal, which starts out at 0. I assume
On Fri, 2014-11-07 at 11:15 -0600, Andrew Deason wrote:
> It seems likely the 0 kvno is the problem. We only copy in a principal
> if the kvno in the keytab is greater than 'vno' in
> akimpersonate.c:pick_principal, which starts out at 0. I assume that's
> valid and we just hadn't encountered this
On Fri, 07 Nov 2014 17:46:19 +0100
Volkmar Glauche wrote:
> mit-krb5# ktutil
> ktutil: rkt /etc/openafs/server/rxkad.keytab
> ktutil: l
> slot KVNO Principal
>
> -
>10 afs/cell@REALM
>20 afs/cell@REALM
On Thu, 06 Nov 2014 13:56:56 +0100
Volkmar Glauche wrote:
> I'm not sure whether it is an issue with OpenAFS, MIT Kerberos or
> build options for either software,
In addition to what Chas asked for, can you tell us what build options
you used? Any additional CFLAGS, etc?
--
Andrew Deason
adea
10 matches
Mail list logo
