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 <ghud...@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 b...@columbia.edu ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
