Pre-auth encrypted timestamp clock skew

[Benjamin N Hall]

Hi Greg,

I haven't run a debugger in quite some time, so I'm not sure I'd uncover
much.  To your hunch though, I deleted my existing ccache files and voila,
kinit success.

So my issue is "resolved" or at least has a known work-around.  The new
question (I think) becomes, "How does one generate a ccache file with a 20
minute offset on one host without changing the system time?"

I'm guessing that however that happened, i's not really a problem with
Kerberos.

Thanks,
ben


On Wed, Aug 23, 2017 at 5:36 PM, Greg Hudson <ghudson at mit.edu> wrote:

> On 08/23/2017 05:23 AM, Benjamin N Hall wrote:
> > We recently started testing pre-authentication for certain principals,
> and
> > I'm seeing an odd issue whereby kinit fails with "Clock skew too great
> > while getting initial credentials", despite all three KDCs and the client
> > systems' time being within one second of each other.
> [...]
> > The part that seems interesting to me is that the pre-auth encrypted
> > timestamp appears to be off by way more than 5 minutes from the other
> > timestamps.
>
> The encrypted timestamp is unexpectedly for 1234 seconds in the future.
> The only explanation I can think of is that you had a pre-existing
> ccache with a recorded time offset of roughly 20 minutes.  For various
> reasons I'm not sure that's the right explanation.  If you can
> investigate with a debugger, I would be very interested in knowing the
> actual cause.
>
> The client code in 1.12 and later will use the timestamp sent by the KDC
> in its PREAUTH_REQUIRED error (assuming kdc_timesync is set to true,
> which it is by default), which would likely suppress this problem.
>



-- 
Benjamin Hall
Lead Systems Engineer, CUIT
Columbia University
bnh1 at columbia.edu