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

PMc

PMc

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.
 
From wikipedia,
Kerberos has strict time requirements, which means that the clocks of the involved hosts must be synchronized within configured limits.
 
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.
 
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.
 
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.
 
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.
 
PMc said:
kdc[6798]: Too large time skew, client time 1970-01-01T01:00:00 is out by 1668625860 > 300 seconds
Click to expand...
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.
 
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.
 
Sorry to Necro this thread, but I kept landing here trying to troubleshoot a new Kerberos install on RELEASE-13.1 and RELEASE-13.2. Leaving this tidbit for others who may run into this issue.

tl;dr .. not mentioned in the Manual but is most likely required:


sysrc kdc_enable="YES"
sysrc kdc_program="/usr/local/libexec/kdc"
sysrc kdc_flags=""

sysrc kadmind_enable="YES"
sysrc kadmind_program="/usr/local/libexec/kadmind"


So the long of it is... heimdal services are packaged in base and are currently a much older version (1.5.2) versus the install in pkg (7.8). The libraries in base seem to operate perfectly fine for client side Kerberos functionality. However, they don't seem to work well as a KDC any longer.

So we want to make sure that the pkg version of the kdc and kadmin daemon are the ones ran by the rc system at startup. This doesn't appear to be noted in the handbook currently, just that we should install the latest version of heimdal on the KDC. The kdc and kadmind rc scripts already handle this by allowing you to specify the kdc_program and kadmind_program variables in the rc.conf file. I believe this was originally intended to allow choosing between MIT versus Heimdal versions. In this instance we're simply using this mechanism to select the pkg installed version.

In situations where you are getting time skew related errors, this is most likely the fix post the patch noted earlier in this thread.

Hope this was helpful.
 
xk2600 said:
So the long of it is... heimdal services are packaged in base and are currently a much older version (1.5.2) versus the install in pkg (7.8). The libraries in base seem to operate perfectly fine for client side Kerberos functionality. However, they don't seem to work well as a KDC any longer.
Click to expand...
Hm, can You elaborate? In what regard?

I found that I need newest MIT version on some client in order to work with the python library - but even that seems to work with the KDC from base. Maybe it has some flaw which I failed to recognize?

xk2600 said:
So we want to make sure that the pkg version of the kdc and kadmin daemon are the ones ran by the rc system at startup. This doesn't appear to be noted in the handbook currently, just that we should install the latest version of heimdal on the KDC.
Click to expand...
I happened to write my own rc scripts, anyway, because the ones provided are not able to operate multiple instances of the KDC. (Neither is the binary code, unless it gets tweaked a bit).
 
PMc said:
Hm, can You elaborate? In what regard?

I found that I need newest MIT version on some client in order to work with the python library - but even that seems to work with the KDC from base. Maybe it has some flaw which I failed to recognize?
Click to expand...

I am running the pkg version (7.8) on the KDC. On the KDC, without setting the bin *_program rcvars as mentioned above, the RC script does not automatically differentiate between the builtin and pkg daemon. I was getting odd errors during token retrieval and admin sessions, which didn't necessarily point to this being the issue. Effectively this happens because I ended up creating the database with the 7.8 tools but unintentionally launching the KDC using the 1.5.2 daemon/libs. The fix for this was making sure the *_program rcvars are set to the pkg bin paths appropriately.

I had no issue using builtin heimdal 1.5.2 retrieve client and service tickets for SSH and NFS on other server/client machines which connect to the 7.8 KDC.

Since that posting, I have however converted the other servers and clients to utilize the latest heimdal version in pkg (7.8) as well, mainly to align the security of all the machines participating in kerberos.
 
You must log in or register to reply here.
Back
Top