cTime and KrbError

[Luke Hebert]

Hi Greg,

Thanks for the response, this helps either way. I've been poking around
trying to figure out where this 347262666 value is coming from myself. It
might be something in our code base somewhere that I haven't been able to
track down.


*--Luke Hebert* | Customer Operations and Support
cloudera.com <https://www.cloudera.com>

------------------------------


On Tue, May 19, 2020 at 1:39 PM Greg Hudson <ghudson at mit.edu> wrote:

> On 5/19/20 10:56 AM, Luke Hebert wrote:
> > So I've been searching around trying to understand cTime. While dealing
> > with a ticket renewal issue. I know that this is supposed to be the
> > client's current time. The question is what conditions cause cTime to
> print
> > out in Java debug as being from 1981. This isn't the start of epoch.
> >
> > My assumption looking at the RFC for KRBError would suggest to me that
> > something went wrong and the authenticator could not decode the request
> and
> > the fields are omitted in the Error response. Thus resulting in a default
> > value being printed for what would be a time based field.
>
> For a KRB-ERROR resulting from a TGS request, the MIT krb5 KDC would
> normally omit the ctime and cusec fields.  It looks like a Heimdal KDC
> would copy them from the request authenticator.  I don't know what
> Microsoft KDCs do.
>
> 347262666 does not seem like a recognizable default value; I have no
> idea where it could be coming from.
>