Here is a question was it using preauth? In other words is there a key tab file in /etc? The other question is NTP set to sync the time on shutdown to the bios?
There are a couple of reasons why I can think this might happen the first involves how NTP corrects the time and how it may interact with how an option in MIT kerberos client works and that article. There is an incorrect statement in that article about disabling the time sync. It's not that the option disables the time sync it just corrects for it when the ticket is created to mask the issue. The problem with that is NTP usually doesn't sync the time in one shot by default it only corrects it in less than 1 second increments so it doesn't break time dependant things like cron jobs. That flag in combination with the default behavior of NTP can cause an artificial clock skew issue later. Now you can set in /etc/sysconfig an option in the NTP settings to tell it to do an initial full sync on boot before starting ntpd but it is not the default behavior in 6 if I remember correctly. If a ticket had been created and the clock had been more than 5 minutes out of sync you would have gotten a clock skew error after the clock had corrected its self because it would still have still been compensating for the initial skew. In this case kdestroy would clear the skew correction and the new key would be unaffected. The other possibility is that if preauth is being used there could have be something wrong in how the service credential was created in the kerberos server which is quite common if the server is an AD server, and sometimes happens with Heimdal kerberos servers too. Essentially the other possibility is it may have a max ticket renewal set on the principal in which case a kdestroy may force it to redo the preauth and then create a new ticket. Usually you can correct this in the kerberos server if your Kerberos admin really knows it well sadly most AD admins don't :(. I've had to show more than a few of them over the years articles on Microsoft technet, and tell them just do that and stop insisting it can't be done. By the way that article is right about one thing the DNS reverse lookup in MIT kerberos can be problematic because it can't support the use of CNAMEs in the forward lookup, and is not specified any where in any of the ratified RFCs ( in fact it was proposed and rejected by committee on that basis) so it causes more problem especially when it interacts with other kerberos implementation or is implemented in the cloud. It's also the only implementation of Kerberos 5 that does it. It's not the only place where MIT kerberos violates the RFCs and those violations are the reason why you can't use it for Samba version 4 AD server, and why most Linux based appliances that support kerberos use Heimdal kerberos. On Oct 19, 2017 11:48 AM, "Stephen Isard" <7p03xy...@sneakemail.com> wrote: > On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky <riehe...@fnal.gov> > wrote: > > >If memory serves, SL7 has "Less Brittle Kerberos"[1] where as SL6 does > >not. This could account for why one works and the other does not. > > > >Pat > > > >[1] https://fedoraproject.org/wiki/Features/LessBrittleKerberos > > That looks promising as an explanation. > > The problem has been "solved", or at least it has gone away, although I > don't really understand why. Without any clear hypothesis as to why it > might help, I decided to run "kdestroy -A" on the affected machine to clear > expired tickets out of my local cache. That did it. No more clock skew > messages. So it looks as if it was a kerberos issue, rather than an ntp > one, and the error message wasn't really explaining what was wrong. > > Thanks to everyone for their advice. > > Stephen Isard > > > >On 10/18/2017 07:10 PM, Stephen Isard wrote: > >> On Wed, 18 Oct 2017 17:12:46 -0400, R P Herrold <herr...@owlriver.com> > wrote: > >> > >>> On Wed, 18 Oct 2017, Howard, Chris wrote: > >>> > >>>> Is it possible the two boxes are talking to two different servers? > >>> as the initial post mentioned and showed it was using remote > >>> host lists to a pool alias, almost certainly -- > >> Oh, I took the question to be about the kerberos server. Yes, you are > right, > >> ntpd -q returns different results on the two machines. However, as I > said in the original post, the time on the two machines is the same to > within a very small amount., well within the five minute tolerance used by > kerberos. So I don't understand why it should matter that the two machines > have arrived at the same time by syncing with different servers. > >> > >>> as a way around, set up ONE unit to act as the local master, > >>> and then sync against it, to get 'site coherent' time > >> Could you tell me how to do this, or point me at a document that does? > >> > >> Thanks. > >> > >>> [a person with more than one clock is never quite _sure_ what > >>> time is correct ;) ] > >>> > >>> > >>> for extra geek points, spend $25 on AMZN, and get a GPS USB > >>> dongle; run a local top strata server (the first three > >>> lintes of the following) > >>> > >>> [root@router etc]# ntpq -p > >>> remote refid st t when poll reach delay > >>> offset jitter > >>> ============================================================ > ================= > >>> GPS_NMEA(0) .GPS. 0 l - 16 0 0.000 > >>> 0.000 0.000 > >>> SHM(0) .GPS. 0 l - 16 0 0.000 > >>> 0.000 0.000 > >>> SHM(1) .PPS. 0 l - 16 0 0.000 > >>> 0.000 0.000 > >>> +ntp1.versadns.c .PPS. 1 u 665 1024 377 51.817 > >>> -12.510 19.938 > >>> *tock.usshc.com .GPS. 1 u 294 1024 377 34.608 > >>> -8.108 10.644 > >>> +clmbs-ntp1.eng. 130.207.244.240 2 u 429 1024 377 31.520 > >>> -5.674 7.484 > >>> +ntp2.sbcglobal. 151.164.108.15 2 u 272 1024 377 23.117 > >>> -6.825 10.479 > >>> +ntp3.tamu.edu 165.91.23.54 2 u 1063 1024 377 63.723 > >>> -3.319 16.813 > >>> [root@router etc]# > >>> > >>> > >>> configuring ntp.conf is not all that hard > >>> > >>> -- Russ herrold > > > >-- > >Pat Riehecky > > > >Fermi National Accelerator Laboratory > >www.fnal.gov > >www.scientificlinux.org >
