# FreeBSD-SA-22:14.heimdal (breaks my site)



## PMc (Nov 16, 2022)

After upgrading I get this
`kinit: krb5_get_init_creds: Clock skew too great`
and this
`kdc[6798]: Too large time skew, client time 1970-01-01T01:00:00 is out by 1668625860 > 300 seconds`

Which translates to: no tickets, no database, no ssh, no automation.


----------



## Alain De Vos (Nov 16, 2022)

From wikipedia,
Kerberos has strict time requirements, which means that the clocks of the involved hosts must be synchronized within configured limits.


----------



## PMc (Nov 16, 2022)

Yes, that's the case. The limit is 300 seconds.

But I don't think any of my clocks shows 1970-01-01T01:00:00 and *DOES NOT MOVE*.


----------



## cy@ (Nov 16, 2022)

What are client, server, and KDC time? (Yes, there are 3 machines involved.)


----------



## PMc (Nov 16, 2022)

Hi cy,

time is within <10ms on concerned systems.

I can isolate the problem to the KDC system. Behaviour from patched and unpatched clients is identical, and when reverting the SA-22:14 on the KDC system, things do work again.

I tried to isolate a specific patch from the SA-22:14 patchset, but was unsuccessful so far: subsets of the patches did not trigger the problematic behaviour.


----------



## cy@ (Nov 16, 2022)

Can you open a PR for this? I'd like to bring philip@ into this discussion. He got the patch from the heimdal folks over a week ago and tested the patch on the FreeBSD cluster for a week before it was committed. I tested it here too but my KDC is MIT. (The MIT KDC suffered a similar problem, though it was an integer overflow.)

Looking at the patch I doubt the KDC PAC portion of the patch would have had anything to do with this. That code was moved to execute earlier in the path.

I'll refrain from asking more questions here. Just open a PR and assign to me.


----------



## PMc (Nov 17, 2022)

Yeah, I'm working on it. I'll open a PR when I have robust data. I have split that patchset into halves, and each of them worked without error. So something is strange here. That might have to do with my treatment of META_MODE and git timestamps, or whatever, anyway I want to find out first.


----------



## Jose (Nov 17, 2022)

PMc said:


> `kdc[6798]: Too large time skew, client time 1970-01-01T01:00:00 is out by 1668625860 > 300 seconds`


That is The Beginning of Time in the UTC+1 time zone. Well as far as POSIX is concerned, anyway.

Looks like some integer representing time is getting set to 0 somewhere.


----------



## PMc (Nov 17, 2022)

bug is *267827*

*Jose: *very much so, yes.


----------



## cy@ (Nov 17, 2022)

It's resolved. The patch caused ASN1 to replace the timestamp with zeros when UTC was set in the request. Thanks to the sleuthing of PMc@ by the time I woke this morning.

Poking around with a heimdal-devel port for those who want to track upstream development. The final build looks like it might be a quick win.


----------

