# Samba domain: clock skew too great for kerberos krb5-116



## Avery Freeman (May 23, 2018)

So what's up? 

I thought I had fixed an issue that was preventing me from joining my domain controller -- i.e. I had fixed my time issues I was having with a particular FreeBSD VM:

https://forums.freebsd.org/threads/one-freebsd-server-having-ntp-issues.65976/

But when I run kinit I still can't get a key:

```
[root@fabby111 /home/local]# kinit
administrator@HAPPY.HUT's Password:
kinit: krb5_get_init_creds: Clock skew too great
```

Time looks fine -- on problematic VM:

```
[root@fabby111 /home/local]# date
Wed May 23 11:10:00 PDT 2018
```

On domain controller:





Looks like it's within 300 seconds to me...  Any ideas, anyone?

Edit: Gah!  So I have tried setting clockskew  all the way up to 2400 in krb5.conf, I have removed krb5-116 and tried downgrading to krb5-115.  I have stopped and re-started ntpd and samba_server both several times.  Nothing seems to work.

This was working fine yesterday.  I need my file server.


----------



## SirDice (May 24, 2018)

I suspect the clock skew that's mentioned is the difference in time between the host and the KDC. Both clocks must be within a certain margin for Kerberos to work (this is to prevent replays for example).


----------



## Avery Freeman (May 25, 2018)

SirDice said:


> I suspect the clock skew that's mentioned is the difference in time between the host and the KDC. Both clocks must be within a certain margin for Kerberos to work (this is to prevent replays for example).


No, exactly, I know that - that last thread I quoted at the top was me going through and adjusting all my time settings for HW clock, ESXi host clock, tzsetup, date, ntp.conf, and the domain controllers - but now the clocks are within seconds of one another

This is one out of 3 VMs that is configured the exact same way that is having this issue, too.  It's so weird.  It must be some kind of bug.

I realized I made a grievous error adding the latest (as opposed to default quarterly) repository to pkg and updated using it before making snapshots in ESXi - it was dumb, because now I'm having all sorts of Samba errors - ldb version mismatch was another one, 1.3.2 database existed vs 1.3.3 which it had updated to.  I might have been able to use samba-tool to update the database, but instead I could see there would be all sorts of trouble going forward so I deleted the latest repo file, cleaned my pkg cache, removed krb5-116, ldb13 and samba48 and re-installed them using quarterly repo and that resolved my ldb issues - which I had been having on all 3 VMs

But this clock skew one - that's not reproducible on any other VM, just this one.  Either there's something that I'm missing (and I've covered absolutely everything I can think of) or it's a bug.

Any recommendations for filing a bug with the dev team?


----------



## SirDice (May 25, 2018)

Avery Freeman said:


> I realized I made a grievous error adding the latest (as opposed to default quarterly) repository to pkg and updated using it before making snapshots in ESXi - it was dumb, because now I'm having all sorts of Samba errors - ldb version mismatch was another one, 1.3.2 database existed vs 1.3.3 which it had updated to.


It's fine to leave it at latest. But you now may have a combination of things from quarterly and latest which could lead to dependencies not being aligned properly. The easiest way to make sure everything is from the same repository is to check `pkg -vv` and make sure only one repository is enabled, then run `pkg upgrade -f`. That command will force a reinstall of everything. That should resolve any dependency issues as everything will come from the same build.


----------



## Avery Freeman (May 25, 2018)

SirDice said:


> It's fine to leave it at latest. But you now may have a combination of things from quarterly and latest which could lead to dependencies not being aligned properly. The easiest way to make sure everything is from the same repository is to check `pkg -vv` and make sure only one repository is enabled, then run `pkg upgrade -f`. That command will force a reinstall of everything. That should resolve any dependency issues as everything will come from the same build.



Ok, I'll try it!  after snapshotting first like I should have in the first place (grumblling self-loathing profanities under breath).  What else do I have to lose?

---

On the other hand, if I do that it might cause even more problems.  I think the rub is in the fact that the samba48 package can't upgrade itself, let alone from another version of samba.

Oh well, I'll give it a shot and report back.

Edit:  Right off the bat,  I noticed a few relevant upgrades,

```
Installed packages to be UPGRADED:
..
        ldb13: 1.3.2 -> 1.3.3
        krb5-116: 1.16_1 -> 1.16.1
```

However, I think these are related to me trying to go back to the quarterly-repo version of Samba in my scramble to try and make things work again. 

PS:  I also ran `# pkg clean` first after switching to the latest repo (I just appended `.backup` to the FreeBSD.conf in `/etc/pkg` and removed a `.removed` I had appended to the latest.conf I had created previously in `/etc/pkg`)


----------



## SirDice (May 25, 2018)

You shouldn't edit /etc/pkg/FreeBSD.conf, your changes are likely to be reverted when you update the OS. Instead create a /usr/local/etc/pkg/repos/FreeBSD.conf and put the change there:

```
FreeBSD: { 
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
}
```

This won't fix anything for your issue but changing the settings this way will ensure they stay changed even after you update the system


----------



## Avery Freeman (May 25, 2018)

Oh, okay -- good to know

So, it didn't work for the samba48 issue.  Rather than piddle around with it, I just created a new VM and migrated my settings, this time being careful to install samba47 and krb5-115. From now on, with those two packages I'm sticking to a version behind the latest. 
At least you can do that on FreeBSD, which graciously includes earlier versions in the pkg repo by default!  That is awfully nice...


----------

