On Thu, 19 Oct 2017 12:48:42 -0400, Paul Robert Marino <[log in to unmask]> 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" <[log in to unmask]> wrote:
>
>> On Thu, 19 Oct 2017 09:09:32 -0500, Pat Riehecky <[log in to unmask]>
>> 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 <[log in to unmask]>
>> 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
>>
>
|
