On Thu, 19 Oct 2017 12:48:42 -0400, Paul Robert Marino <prmari...@gmail.com> wrote:
>Here is a question was it using preauth? >In other words is there a key tab file in /etc? No. >The other question is NTP set to sync the time on shutdown to the bios? I don't think so. Certainly no setting in /etc/ntp.conf or /etc/sysconfig/ntp. In any case there was no shutdown between the last successful kinit and the first skew error message. >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 >> >